On Wed, Nov 18, 2009 at 08:42:10AM -0600, Anthony Liguori wrote:
> Kevin O'Connor wrote:
>> The order of hard drives is determined by the BCV list. There is only
>> one entry in the IPL table for booting from a hard drive - selecting
>> "-boot c" prioritizes this IPL - hard drive booting always bo
Kevin O'Connor wrote:
The order of hard drives is determined by the BCV list. There is only
one entry in the IPL table for booting from a hard drive - selecting
"-boot c" prioritizes this IPL - hard drive booting always boots from
the "C" drive. It's possible to tell SeaBIOS to map the C drive
On Mon, Nov 16, 2009 at 03:14:33PM -0600, Anthony Liguori wrote:
> Gerd Hoffmann wrote:
>> Huh? Do you want export *all* block devices via extboot? Will IDE
>> drives show up twice then?
>
> No, because SeaBIOS already has an ATA driver so we wouldn't want to
> expose IDE on the extboot bus.
Alexander Graf wrote:
Because that's not what you'd use it for. That's what -kernel and
-initrd are there for.
IMHO having a BIOS backdoor is a good thing in general. If anyone wants
to destroy their user experience by writing a driver for that in their
OS, I'm good with that, but let's not exp
Paul Brook wrote:
> On Tuesday 17 November 2009, Gerd Hoffmann wrote:
>
>> On 11/17/09 13:36, Paul Brook wrote:
>>
> In fact I'd much prefer to see extboot rewritten to just virtio-block.
>
Hmm, I'd prefer something which is *not* used by the guest OS, so it is
On Tuesday 17 November 2009, Gerd Hoffmann wrote:
> On 11/17/09 13:36, Paul Brook wrote:
> >>> In fact I'd much prefer to see extboot rewritten to just virtio-block.
> >>
> >> Hmm, I'd prefer something which is *not* used by the guest OS, so it is
> >> a pure bootloader thing. When using it to boo
On 11/17/09 13:36, Paul Brook wrote:
In fact I'd much prefer to see extboot rewritten to just virtio-block.
Hmm, I'd prefer something which is *not* used by the guest OS, so it is
a pure bootloader thing. When using it to boot from scsi you don't want
to have the disk show up twice (as virtio
> > In fact I'd much prefer to see extboot rewritten to just virtio-block.
>
> Hmm, I'd prefer something which is *not* used by the guest OS, so it is
> a pure bootloader thing. When using it to boot from scsi you don't want
> to have the disk show up twice (as virtio and scsi) in the guest.
You
On 11/17/09 12:36, Paul Brook wrote:
It would require a mechanism to do enumeration and identification
though.
Huh? Do you want export *all* block devices via extboot? Will IDE
drives show up twice then?
No, because SeaBIOS already has an ATA driver so we wouldn't want to
expose IDE on the
> >> It would require a mechanism to do enumeration and identification
> >> though.
> >
> > Huh? Do you want export *all* block devices via extboot? Will IDE
> > drives show up twice then?
>
> No, because SeaBIOS already has an ATA driver so we wouldn't want to
> expose IDE on the extboot bus.
Jamie Lokier wrote:
Gerd Hoffmann wrote:
On 11/16/09 20:24, Anthony Liguori wrote:
If we were going to introduce a light weight block protocol like this,
I'd rather it be implemented in SeaBIOS as a block driver.
Ok. That would mean to replace the option rom with a seabios patch
Gerd Hoffmann wrote:
> On 11/16/09 20:24, Anthony Liguori wrote:
> >If we were going to introduce a light weight block protocol like this,
> >I'd rather it be implemented in SeaBIOS as a block driver.
>
> Ok. That would mean to replace the option rom with a seabios patch.
> The qemu code will be
Gerd Hoffmann wrote:
On 11/16/09 20:24, Anthony Liguori wrote:
If we were going to introduce a light weight block protocol like this,
I'd rather it be implemented in SeaBIOS as a block driver.
Ok. That would mean to replace the option rom with a seabios patch.
The qemu code will be unmodifie
On 11/16/09 20:24, Anthony Liguori wrote:
If we were going to introduce a light weight block protocol like this,
I'd rather it be implemented in SeaBIOS as a block driver.
Ok. That would mean to replace the option rom with a seabios patch.
The qemu code will be unmodified though (except for t
Gerd Hoffmann wrote:
Hi,
How about this one? extboot rom and interface are unmodified.
The windup in qemu is very different though. It is now implemented as
isa bus device (which is what extboot actually is). It is properly
integrated into qdev. It is much less invasive than the previous
Hi,
How about this one? extboot rom and interface are unmodified.
The windup in qemu is very different though. It is now implemented as
isa bus device (which is what extboot actually is). It is properly
integrated into qdev. It is much less invasive than the previous
version. The patch jus
16 matches
Mail list logo
