9:40 a.m.
Gerd Hoffmann wrote:
On 09/08/09 15:47, Jan Kiszka wrote:
> Before setting this definitely useful feature in stone, I have two
> questions though:
>
> - -drive ...,boot=on is logically in conflict with -boot. Yes, -boot
> for x86 currently cannot differentiate between multiple disks, only
> between boot media types. Still, this two-stage configuration is
> rather unintuitive and looks like a patchwork. Given that we have
> full control over all components, is it really the preferred
> approach? I already thought about, e.g., -boot c2 to select the
> second disk. Not that nice, but I would rather vote for a consistent
> configuration than a scattered one.
Disk numbers are bad. Define "second hard disk". Especially for a
system with different kinds of disks (say one scsi and one virtio).
One could use the specification order, but I agree it's not very handy.
Drives have names though which can be used to reference the disks, so we
could use that instead. -boot cmd line syntax becomes a bit tricky then
though, we somehow have to figure whenever the user gave us names or
old-style letters. Something like this ...
-drive if=virtio,id=sys,file=/path/to/disk.img
-cdrom /path/to/install.iso
-boot order=[sys],once=d,menu=off
Yes, this looks powerful and clean. One could even still define probe
orders like "-boot order=[sys][backup]d".
... might work out nicely. I suspect the libvirt folks will hate us for
that though.
Does anyone from libvirt want to comment on this?
> - This is just an implementation detail: Do we really need to implement
> booting from virtio and scsi via an extension rom? Isn't it possible
> to merge the corresponding support into the main bios?
Well. There are quite a few. bochs pcbios, seabios, coreboot ...
Ok, but that's only an argument to have extboot as a workaround for
bioses not yet supporting scsi and virtio natively, isn't it? I'm
thinking long-term here, not arguing against a extboot-based short-term
solution.
Jan
--
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
9:52 a.m.
> -drive if=virtio,id=sys,file=/path/to/disk.img
> -cdrom /path/to/install.iso
> -boot order=[sys],once=d,menu=off
Yes, this looks powerful and clean. One could even still define probe
orders like "-boot order=[sys][backup]d".
Well, except that boot orders with two hard drives in there don't work
in the PC world ...
>> - This is just an implementation detail: Do we really need
to implement
>> booting from virtio and scsi via an extension rom? Isn't it possible
>> to merge the corresponding support into the main bios?
>
> Well. There are quite a few. bochs pcbios, seabios, coreboot ...
Ok, but that's only an argument to have extboot as a workaround for
bioses not yet supporting scsi and virtio natively, isn't it? I'm
thinking long-term here, not arguing against a extboot-based short-term
solution.
I think it would be useful. Adding a fw_cfg knob to signal 'please boot
via extboot protocol instead of ide disk' should be enougth to allow
bioses supporting extboot directly. Additional plus is we can probably
code it in C not asm then.
cheers,
Gerd
11:15 a.m.
Gerd Hoffmann wrote:
>> -drive if=virtio,id=sys,file=/path/to/disk.img
>> -cdrom /path/to/install.iso
>> -boot order=[sys],once=d,menu=off
> Yes, this looks powerful and clean. One could even still define probe
> orders like "-boot order=[sys][backup]d".
Well, except that boot orders with two hard drives in there don't work
in the PC world ...
That depends on your bios. I've seen many that allow disk boot ordering,
though they may not support "[sys]d[backup]".
However, I see no technical reason for artificially restricting qemu
bios capabilities.
>>> - This is just an implementation detail: Do we really need to implement
>>> booting from virtio and scsi via an extension rom? Isn't it
possible
>>> to merge the corresponding support into the main bios?
>> Well. There are quite a few. bochs pcbios, seabios, coreboot ...
> Ok, but that's only an argument to have extboot as a workaround for
> bioses not yet supporting scsi and virtio natively, isn't it? I'm
> thinking long-term here, not arguing against a extboot-based short-term
> solution.
I think it would be useful. Adding a fw_cfg knob to signal 'please boot
via extboot protocol instead of ide disk' should be enougth to allow
bioses supporting extboot directly. Additional plus is we can probably
code it in C not asm then.
I'm still not convinced we need extboot for all bioses on the long term.
And I think we should define new interfaces in a way that finally makes
it obsolete, at least for our "home bios" (whatever it will be).
Jan
--
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
12:12 p.m.
New subject: [libvirt] Re: [Qemu-devel] Re: [PATCH 0/2] port over extboot from kvm
Jan Kiszka wrote:
>>>> - This is just an implementation detail: Do we
really need to implement
>>>> booting from virtio and scsi via an extension rom? Isn't it
possible
>>>> to merge the corresponding support into the main bios?
>>>>
>>> Well. There are quite a few. bochs pcbios, seabios, coreboot ...
>>>
>> Ok, but that's only an argument to have extboot as a workaround for
>> bioses not yet supporting scsi and virtio natively, isn't it? I'm
>> thinking long-term here, not arguing against a extboot-based short-term
>> solution.
>>
> I think it would be useful. Adding a fw_cfg knob to signal 'please boot
> via extboot protocol instead of ide disk' should be enougth to allow
> bioses supporting extboot directly. Additional plus is we can probably
> code it in C not asm then.
>
I'm still not convinced we need extboot for all bioses on the long term.
And I think we should define new interfaces in a way that finally makes
it obsolete, at least for our "home bios" (whatever it will be).
What we won't need long term is the extboot interface (hw/extboot.c).
Ideally, we would rewrite the extboot option rom to have a proper
virtio-blk driver in it. Better yet, to finish up Laurent's work of
adding virtio-blk support to gpxe since it gives us bcv for free. We
woudl then support booting from multiple disks by specifying the bcv
entry index in cmos.
Then we would need a new syntax for boot (like -boot c3 to chose the 3rd
disk device).
Regards,
Anthony Liguori
Jan
2:03 p.m.
New subject: [libvirt] Re: [Qemu-devel] Re: [PATCH 0/2] port over extboot from kvm
On 09/08/09 19:12, Anthony Liguori wrote:
> I'm still not convinced we need extboot for all bioses on the
long term.
> And I think we should define new interfaces in a way that finally makes
> it obsolete, at least for our "home bios" (whatever it will be).
What we won't need long term is the extboot interface (hw/extboot.c).
Ideally, we would rewrite the extboot option rom to have a proper
virtio-blk driver in it. Better yet, to finish up Laurent's work of
adding virtio-blk support to gpxe since it gives us bcv for free.
That doesn't cover booting from scsi.
It also doesn't cover booting from usb.
cheers,
Gerd
2:39 p.m.
New subject: [libvirt] Re: [Qemu-devel] Re: [PATCH 0/2] port over extboot from kvm
Gerd Hoffmann wrote:
On 09/08/09 19:12, Anthony Liguori wrote:
>> I'm still not convinced we need extboot for all bioses on the long
>> term.
>> And I think we should define new interfaces in a way that finally makes
>> it obsolete, at least for our "home bios" (whatever it will be).
>
> What we won't need long term is the extboot interface (hw/extboot.c).
> Ideally, we would rewrite the extboot option rom to have a proper
> virtio-blk driver in it. Better yet, to finish up Laurent's work of
> adding virtio-blk support to gpxe since it gives us bcv for free.
That doesn't cover booting from scsi.
It also doesn't cover booting from usb.
It assumes support for both in option roms. The big advantage to gpxe
is that it already has generic scsi support.
Regards,
Anthony Liguori
cheers,
Gerd
10:43 a.m.
New subject: [libvirt] Re: [Qemu-devel] Re: [PATCH 0/2] port over extboot from kvm
On Tue, Sep 08, 2009 at 04:40:15PM +0200, Jan Kiszka wrote:
Gerd Hoffmann wrote:
> On 09/08/09 15:47, Jan Kiszka wrote:
>> - This is just an implementation detail: Do we really need to implement
>> booting from virtio and scsi via an extension rom? Isn't it possible
>> to merge the corresponding support into the main bios?
>
> Well. There are quite a few. bochs pcbios, seabios, coreboot ...
Ok, but that's only an argument to have extboot as a workaround for
bioses not yet supporting scsi and virtio natively, isn't it? I'm
thinking long-term here, not arguing against a extboot-based short-term
solution.
I doubt we'll see native scsi support as I believe each scsi
controller needs its own initialization. However, usb booting will
bring along with it mass storage class support.
I'm not familiar with virtio, however, I don't think it would be
difficult to add support to SeaBIOS. The disk access code in SeaBIOS
has an intermediate layer which makes it easier to add new backends.
For an example of this, see the ramdisk.c code:
http://git.linuxtogo.org/?p=kevin/seabios.git;a=blob;f=src/ramdisk.c;h=7a...
The above code adds support for a virtual floppy drive that is
populated with a floppy image stored in flash (useful with coreboot).
Basically, its possible to add driver support by adding a new drive
type (eg, DTYPE_RAMDISK) and implementing a new drive handler (eg,
process_ramdisk_op). The handler just has to implement read and write
capability - the bios call handlers, interfaces, and lba manipulation
are handled by SeaBIOS.
-Kevin
5550
days inactive
5554
days old
6 comments
4 participants
participants (4)
-
Anthony Liguori -
Gerd Hoffmann -
Jan Kiszka -
Kevin O'Connor