[libvirt] Re: [PATCH 0/2] port over extboot from kvm
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
-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
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
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
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
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
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=7ac72... 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
participants (4)
-
Anthony Liguori -
Gerd Hoffmann -
Jan Kiszka -
Kevin O'Connor