|
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
[Prev in Thread] | Current Thread | [Next in Thread] |