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

[Anthony Liguori <anthony@codemonkey.ws>]

On 06/07/2010 10:12 PM, Paul Brook wrote:
>> This series introduces a rather radical change in the way we deal with
>> machine definitions in QEMU.
>>      
> I think we should aim to eliminate machine_register_core, and design
> appropriately.  In particular I'd try and avoid adding options that become
> trivially redundant once you can easily change the device trees.
>
>    

Long term, I'd rather that machine_register_core started with a core 
device tree and manipulated from there.

> 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.
>
> I'm extremely tempted by the extreme approach of punting everything to an
> external device tree builder. i.e. remove automagical device reation
> altogether. If you want USB and 6 virtio disks then ask your device tree
> builder to create a machine description that includes pci-ohci and a bunch of
> virtio-blk-pci devices. The virtio-blk devices reference "drives" by id, so
> the same host configuration can be used with a scsi HBA. A small shell script
> should be sufficient to replicate the limited machine variants currently
> supported.
>    

This is not optimizing for the common case.  The overwhelmingly common 
case is a user that makes small changes to a pre-supplied machine core 
in QEMU.  The problem is that those small changes are not simple things 
like add a device or remove a device.  They often require more 
complicated mapping logic like translate user supplied ram size to the 
following ram allocation layout.  We cannot expect all users to specify 
an explicit ram layout.

An external builder is a usability nightmare.  It has to be something 
that is included as part of qemu proper and that's effectively what 
MachineCore's are.  They are internal builders.

That doesn't mean we shouldn't aim to support external builders.  
Everything that a MachineCore generates should be possible to generate 
via a config file statically.

> The problem with doing clever device tree generation/manipulation inside qemu
> is that for anything vaguely nonstandard you're likely to have to hack your
> own device tree anyway. Even ram allocation is nontrivial, e.g. the hole below
> 4G on the PC, and that's before you start with numa-like layouts.
>    

I'm 100% in agreement that a user should be able to specify the exact 
ram layout for a PC.  However, I strongly disagree that a user should 
have to specify the explicit ram layout if they want to adjust the 
allocated ram for a guest.  Relying on an external shell script would be 
a nightmare for users.

What I think we want is MachineCore to only make use of interfaces that 
are available via the command line. IOW, things like qdev_create() and 
friends.

> On a similar note, I don't see any point having machine_create_from_core,
> we can just ship appropriate config files.
>    

I strongly agree.  I didn't include that in this series because I was 
trying to keep this small and slightly less radical.  It'll be a pain 
for people that don't regularly update their config file via a make install.

Regards,

Anthony Liguori

> Paul
>
>