On 05/11/2010 03:31 PM, Gleb Natapov wrote:
On Tue, May 11, 2010 at 11:19:07AM +0300, Avi Kivity wrote:
On 05/10/2010 06:48 PM, Anthony Liguori wrote:
On 05/10/2010 03:11 AM, Gleb Natapov wrote:
This patch adds native support for booting from virtio disks to Seabios.
Signed-off-by: Gleb Natapov<gleb@xxxxxxxxxx>
A related problem that I think we need to think about how we solve
is indicating to Seabios which device we want to boot from
With your patch, a user can select a virtio device explicitly or
if they use only one virtio device, it will Just Work.
However, if a user uses IDE and virtio, or a user has multiple
disks, they cannot select a device via -boot.
Is this something we need to address? I don't think we'd break
libvirt if we didn't.
BIOSes traditionally address this by storing the boot order in RTC
non-volatile memory, and allow the user to configure the order via a
menu. We could do the same (storing the RTC memory in a small disk
image).
Real BIOS can do that because it enumerates all bootable devices,
attach name for each one of them and then asks user to configure
boot order using names it attached to devices. In our case we
want to provide boot order on qemu command line before BIOS
enumerated devices, so qemu should be able to pass enough information
about boot device so that BIOS can uniquely identify it after it will
discover all bootable devices. bus/device pair can be such thing.
Having a BIOS menu is also useful, you don't have to drop to the
management tool, instead you do everything from the console.
Alternatively we can seed the order from the command line (-boot
id1,id2,id3 where id* are some qdev property attached to disks, this
is more flexible than the current syntax I think).
The problem is how to communicate this order to Seabios.
Topology (bus/device/lun).
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
