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 16:40:15 +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:
> 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




reply via email to

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