qemu-devel
[Top][All Lists]
Advanced

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

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


From: Jan Kiszka
Subject: [Qemu-devel] Re: [PATCH 0/2] port over extboot from kvm
Date: Tue, 08 Sep 2009 18:15:27 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

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




reply via email to

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