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

[Paolo Bonzini <pbonzini@redhat.com>]

On 06/08/2010 05:12 AM, 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.

I agree I don't like patch 13 (the parallel/virtcon/vga/floppy/cdrom 
QemuOpts).  Maybe those QemuOpts can be marked in a way that they're not 
user-accessible (and though in some cases customizing max_cpus may make 
sense, that option could also fall in that category).  Everything else 
is very much reasonable in Anthony's patch series, I think.

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

> I'm extremely tempted by the extreme approach of punting everything to an
> external device tree builder. i.e. remove automagical device reation
> altogether.

I think this should have been raised when the -readconfig/-writeconfig 
scheme was proposed and committed.  I don't think it's reasonable to 
block this patch series (or something very much like it) on the grounds 
that a better device tree description model than QemuOpts can be designed.

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

Again, the patch is not making anything worse.

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

I think that's the obvious next step, but there's no reason not to split 
it at this point.

Paolo