On Wed, Jul 06, 2011 at 12:18:13PM +0300, Michael S. Tsirkin wrote:
On Wed, Jul 06, 2011 at 10:57:41AM +0200, Gerd Hoffmann wrote:
On 07/05/11 18:23, Michael S. Tsirkin wrote:
On Tue, Jul 05, 2011 at 05:27:03PM +0200, Gerd Hoffmann wrote:
Try to handle address space shortage by skipping any device which isn't essential for boot.
Signed-off-by: Gerd Hoffmannkraxel@redhat.com
At least in a virt setup, it's much easier to debug things if boot just fails. Partial boot could be an option I guess.
Yea, I think that is pretty much the fundamental question. Does it make sense to try boot up even if we can't fit some devices into the pci memory hole.
Well, the real fix is for the management to remove the offending devices, so I think we should make it as easy as possible to detect the problem and implement the fix.
We could also implement an interface allowing the user to select which devices to disable.
Interface that requires device identifications between qemu and the BIOS involve device paths. Not sure you want to go there :) (Although for PCI devices this is solved problem).
At least linux guests will try to map devices below the pci memory hole in case seabios didn't assign an address.
Of course this works only if the guest hasn't too much memory so there is some free space between end of ram and the start of the pci memory hole.
IO port memory is a problem too, BTW, and not that easily worked around. It's becoming rare in the non-virtualized systems but is unfortunately the mechanism of choice for virtualization.
We usually have a list of bootable devices we got from qemu - want to use that?
Why? seabios knows itself which devices it can use to boot. Also the list from qemu is incomplete, the boot menu can have more entries than what we get passed in from qemu as boot order list.
cheers, Gerd
SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
-- Gleb.