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

[Anthony Liguori <anthony@codemonkey.ws>]

On 06/08/2010 09:30 AM, Paul Brook wrote:
>>> I'm undecided how much parameterisation it's worth trying to support in
>>> the device tree. IMO the current code has way too much magic, because
>>> creating a new variant involves hacking and rebuilding pc.c.
>>>        
>> See patch 22/22.  There is really no magic involved, even though the
>> compat machines are not yet as config files.
>>      
> The magic I'm preferring to is precisely things like pci="on".
> This is an artifact of only having a hardcoded single device tree (defined by
> pc_init), so we need magic parameters to pick between different variants.
>
> If this were just a cleanup of how we implement the various machines that
> would be harmless. However these are now a user-visible interface.
>
> It implies that qemu is expected to know how to add/remove PCI capabilities
> from a machine.

No, this implies that the 'pc' MachineCore is capable of removing PCI 
from a machine and that's all.  'pci' is a MachineCore specific option.

>   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.

> What I'm objecting to is making machine construction be controlled by an
> arbitrary set of hardcoded parameters. One of the goals of the qdev work is
> that you don't need to have hardcoded all the interesting ways a machine can
> vary. Instead you can directly specify how to construct the machine.
>    

MachineCore is orthogonal to constructing a device tree from scratch.  
If you want to express the types of things we allow users to do with 
machines, you are going to need a C function that can manipulate these 
devices trees based on higher level constructs (like PCI enabled and a 
scalar RAM size).

IMHO, the only real question is whether this should be built into QEMU 
or we should rely on an external script to do this work.  Since the vast 
majority of users are going to want this higher level interface, I feel 
pretty confident that we should build this into QEMU.

> My argument is that in the short term this parameterization provides limited
> benefit, and longer term it's going to be obsolete and probably painful to
> support.
>    

And how do you expect this to work for x86 machines?  Even if you had a 
pc-0.13.fdt that represented the base pc-0.13, how do we translate -hda 
foo.img into "add an IDE disk to the primary slot as master to the IDE 
controller on the PIIX3 IDE bus".  Sure, you can say -device 
ide-disk,parent=/piix3/ide0 or something like that but something needs 
to make that translation and it's entirely machine specific.  Because 
with the arm boards, -hda foo.img translates to -device scsi-disk,...

A more complicated example is how you support the behavior of something 
like -usbdevice which adds a usb controller if one isn't already present.

This is the logic that MachineCore implements and it will always be 
needed.  The MachineCores expose whatever tunables make sense for the 
machines they represent.

Regards,

Anthony Liguori

> Paul
>
>