qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Anthony Liguori
Subject: Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support
Date: Tue, 08 Jun 2010 10:28:25 -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/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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]