Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support

[Anthony Liguori <anthony@codemonkey.ws>]

On 06/08/2010 10:58 AM, Paolo Bonzini wrote:
> On 06/08/2010 05:36 PM, Paul Brook wrote:
>>>>    Once you eliminate machine_register_core that knowledge has
>>>>
>>>> somehow got to come from your device tree description file.  Having a
>>>> single device tree that can morph into significantly different 
>>>> machines
>>>> seems like unnecessary complexity given this is a user-specified file.
>>>
>>> 99% of qemu users will never touch a device tree.  The practical matter
>>> is, we're going to have to provide higher level interfaces that allow a
>>> user to significantly morph a base device tree into something 
>>> different.
>>
>> That's the bit I don't get.  Why are we significantly morphing a base 
>> device
>> tree?  Surely it's easier to just use a different base tree.
>
> Because at some point the base tree will have to be written in C.  Of 
> course you have to decide where to stop allowing customization, but 
> anyway it will be significantly more complex than a QemuOpts config 
> file.  QemuOpts obviously doesn't have the flexibility to create an 
> entire device tree.
>
> Want to let the user add an IDE controller?  Fine, you need to provide 
> him with a way of writing the following logic:
>
>     for(i = 0; i < MAX_IDE_BUS * MAX_IDE_DEVS; i++) {
>         hd[i] = drive_get(IF_IDE, i / MAX_IDE_DEVS, i % MAX_IDE_DEVS);
>     }
>     pci_piix3_ide_init(pci_bus, hd, piix3_devfn + 1);
>
> What do you do?  Invent your own language (another YaST? no thanks)? 
> Massive refactoring of QEMU's bowels (cannot solve all the problems, 
> Anthony gave more examples in the email I replied to)?  Keep C code 
> (then you're not doing anything different than what Anthony's 
> MachineCore is doing)?

Or punt all of the complexity to the user such that have to manually 
figure out where in the device tree a drive has to be inserted.  That's 
not really reasonable IMHO.

> I think there are four choices:
>
> 1) only merge the first 5-7 patches of the series, basically up to the 
> creation of -machine and conversion of -kernel/-initrd/-M/-m.  This is 
> also what is needed for KVM's irqchip.  Think about some other smart 
> way to implement default devices.

Or don't declare MachineCore options stable across releases.  I concur 
that we probably don't want to support some of these interfaces long 
term but I think we can pretty quickly figure out some better interfaces.

The advantage of a full conversion is that it allows us to focus on 
improving the interfaces since we'll have the architecture in place.

> 2) do not expose some things to the config files.  This requires 
> implementing an additional QemuOpts feature for internal options, plus 
> the current patchset.  It means that moving machine types out to 
> config files is not possible.

I dislike having internal only options as it means we have to keep 
things within qemu.  For things like max_cpus, I think we just need to 
validate that we've got passed sane values.  Setting max_cpus in a 
global config is actually a really useful thing for downstreams to do 
since they are all having a fixed support statement of X VCPUs per VM.

> 3) put some things into an implementation-dependent namespace, i.e. 
> __pci or __default_device or __serial.  In the future it's possible to 
> these things in config files, just nobody has to worry about users 
> relying on them and can refactor to death.  This is the current 
> patchset plus some search and replace, and is my favorite.

Yeah, I'm good with being explicit.  I'd prefer x-pci or x-serial since 
we've already established that as the experimential namespace.

> 4) expose everything to the user, at the cost of regretting it later. 
> This is the current patchset.
>
>
> One "smart way to implement default devices" could be an inclusion 
> mechanism where a machine can ask qemu to read other config files.  
> Then you'd have config files for the default serial/parallel/etc.  
> This could also be implemented on top of choices 2/3/4 though.

Default devices are a real pain.  Fortunately, we only mess with it in 
s390 so I'm fairly certain we can simplify things considerable.  It's 
just not something I wanted to tackle in this series.

Regards,

Anthony Liguori

> Paolo