[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 0/22] Refactor machine support
From: |
Anthony Liguori |
Subject: |
Re: [Qemu-devel] [PATCH 0/22] Refactor machine support |
Date: |
Tue, 08 Jun 2010 09:04:17 -0500 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4 |
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
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, (continued)
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, Anthony Liguori, 2010/06/08
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, Paul Brook, 2010/06/08
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, Anthony Liguori, 2010/06/09
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, Paul Brook, 2010/06/09
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, Blue Swirl, 2010/06/09
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, Anthony Liguori, 2010/06/09
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, Blue Swirl, 2010/06/09
- Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support, Paul Brook, 2010/06/09
Re: [Qemu-devel] [PATCH 0/22] Refactor machine support,
Anthony Liguori <=