qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: [PATCH 0/2] port over extboot from kvm


From: Avi Kivity
Subject: Re: [Qemu-devel] Re: [PATCH 0/2] port over extboot from kvm
Date: Tue, 08 Sep 2009 22:11:18 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.1) Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Lightning/1.0pre Thunderbird/3.0b3

On 09/08/2009 08:21 PM, Anthony Liguori wrote:
Avi Kivity wrote:
On 09/08/2009 05:32 PM, Anthony Liguori wrote:
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

x86 boot is strange. The BIOS boots from the "first hard disk" What extboot allows you do to is redefine to the bios what constitutes the "first hard disk".

It's not just booting - it's the int 0x13 interface. Grub for example continues to use it and can boot from the second hard disk if desired.

Our BIOS can only support booting from the 0x80 and this is pretty normal.

The bios exports the "bios drives". You can tell grub to load a kernel from the first partition of the second disk: (hd1,0) or even chain-load another boot loaded from another disk.


The right way to do this from a BBS perspective would be to implement BCV support. We could then have BCV entries for every possible disk. Option roms (like extboot/gpxe) can register add new BCV entries. We'd want the user to be able to specify the priority of each disk, so..

I don't know anything about BBS/BCV but it seems reasonable.


I agree with this and I think we should extend it to boot=0x80|0x81.... boot=on is an alias to boot=0x80.

Would be better to stick with 0-based integers. We would then use this to generate BCV priorities.

Sure.


The highest priority BCV device is still exposed as int13 disk 0x80. I suspect certain OSes will only boot from disk 0x80 (probably Windows).

Windows has its own boot loader drive format that can specify other drives (I think using its own drivers, not the bios).

--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]