Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support
> >> AFAICS the current commandline options only result in simple addition of
> >> devices. They might add slightly different devices in slightly different
> >> places, but that's easy to accommodate by having the machine define a
> >> few standard device/bus IDs.
> >>
> >> IMO it's even more lame if -hda shops working when you supply a device
> >> tree.
> >
> > The tree supplied by the user should label a bus node with a property
> > 'QEMU,hda'. The C version (called by the board) would be something
> > like setprop("/i440fx/pci.0/ide.0", "QEMU,hda"). QEMU should search
> > the device tree for such labels at startup.
>
> That works for the very simple case of -hda, but what do you do for:
>
> -drive file=foo.img,bus=0,index=2
I don't see how that is any harder. I'm assuming that -hda is a trivial alias
for -drive bus=0,index=0. Fact is that -drive supports a very limited set of
operations. Figuring out the default interface is easy - use whatever exists
on the machine. Creating IDE disks is easy, just add them to the existing IDE
bus. For SCSI/virtio you might need to add a HBA first, but that's also
fairly trivial. Most other interfaces (sd, pflash) don't do automagical
device creation to start with - if you don't specify an image then you get an
empty/disconnected device.
> I think it's possible to come up with some form of solution once you
> start adding synthetic properties or dummy devices but ultimately I
> think it pollutes the device tree. I think the easiest way to support
> the interfaces we provide now is to just code the device tree
> manipulation in C.
I disagree. If programmatic machine construction/manipulation was sufficient
then we wouldn't need device trees at all. Current qemu supports an extremely
limited set of machines. Bear in mind that x86 PCs are, pretty much by
definition, approximately all the same to start with. Once you start looking
at other platforms (e.g. arm boards) you realise just how cripplingly
restrictive the this is. Restricting -hda, -drive, etc. and similar to a
small subset of built-in machines is IMO and unacceptably poor solution.
Some of your arguments seem to be self-fulfilling prophecies. If you design
your new option structure around a magical self-morphing device tree then it's
unlikely that this will work with user specified device trees. I believe the
current set of commandline options are sufficient abstract that they do not
dictate a particular implementation.
Paul
Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support
On Wed, Jun 9, 2010 at 8:52 PM, Anthony Liguori wrote:
> On 06/09/2010 03:47 PM, Blue Swirl wrote:
>>
>> On Wed, Jun 9, 2010 at 2:30 PM, Paul Brook wrote:
>>
>>
>> Because at some point the base tree will have to be written in C.
>>
>
> No. You can start with a completely empty machine.
> We don't/shouldn't need any machine specific C code.
>
I think you're missing the argument. I should be possible to create a
machine entirely from a FDT or via -device options.
However, to continue to support the interfaces that we support today, it
will be necessary to have C code that manipulates a base device tree.
When a user specifies '-M pc -hda foo.img' verses '-M versatilepb -hda
foo.img', the equivalent are two very different operations on a device
tree. The former adds an ide disk to the default controller and the
later potentially creates a new scsi bus and then adds a disk to a
specific bus.
>>>
>>> AFAICS the current commandline options only result in simple addition of
>>> devices. They might add slightly different devices in slightly different
>>> places, but that's easy to accommodate by having the machine define a few
>>> standard device/bus IDs.
>>>
>>> IMO it's even more lame if -hda shops working when you supply a device
>>> tree.
>>>
>>
>> The tree supplied by the user should label a bus node with a property
>> 'QEMU,hda'. The C version (called by the board) would be something
>> like setprop("/i440fx/pci.0/ide.0", "QEMU,hda"). QEMU should search
>> the device tree for such labels at startup.
>>
>
> That works for the very simple case of -hda, but what do you do for:
>
> -drive file=foo.img,bus=0,index=2
This is a host device, so the device tree does not address that. But
previously I proposed that also the host devices (drives, chardev,
netdev etc.) could be considered to be qdev like devices and qemu_irqs
could be used to communicate between the host devices and
machine/board. Maybe that should be reconsidered.
> I think it's possible to come up with some form of solution once you start
> adding synthetic properties or dummy devices but ultimately I think it
> pollutes the device tree. I think the easiest way to support the interfaces
> we provide now is to just code the device tree manipulation in C.
I don't think pollution is a problem with careful prefixing, also
Linux adds some properties to its device tree. We could also prune our
properties from the tree before passing it around if necessary.
Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support
On 06/09/2010 03:47 PM, Blue Swirl wrote:
On Wed, Jun 9, 2010 at 2:30 PM, Paul Brook wrote:
Because at some point the base tree will have to be written in C.
No. You can start with a completely empty machine.
We don't/shouldn't need any machine specific C code.
I think you're missing the argument. I should be possible to create a
machine entirely from a FDT or via -device options.
However, to continue to support the interfaces that we support today, it
will be necessary to have C code that manipulates a base device tree.
When a user specifies '-M pc -hda foo.img' verses '-M versatilepb -hda
foo.img', the equivalent are two very different operations on a device
tree. The former adds an ide disk to the default controller and the
later potentially creates a new scsi bus and then adds a disk to a
specific bus.
AFAICS the current commandline options only result in simple addition of
devices. They might add slightly different devices in slightly different
places, but that's easy to accommodate by having the machine define a few
standard device/bus IDs.
IMO it's even more lame if -hda shops working when you supply a device tree.
The tree supplied by the user should label a bus node with a property
'QEMU,hda'. The C version (called by the board) would be something
like setprop("/i440fx/pci.0/ide.0", "QEMU,hda"). QEMU should search
the device tree for such labels at startup.
That works for the very simple case of -hda, but what do you do for:
-drive file=foo.img,bus=0,index=2
I think it's possible to come up with some form of solution once you
start adding synthetic properties or dummy devices but ultimately I
think it pollutes the device tree. I think the easiest way to support
the interfaces we provide now is to just code the device tree
manipulation in C.
Regards,
Anthony Liguori
Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support
On Wed, Jun 9, 2010 at 2:30 PM, Paul Brook wrote:
>> >> Because at some point the base tree will have to be written in C.
>> >
>> > No. You can start with a completely empty machine.
>> > We don't/shouldn't need any machine specific C code.
>>
>> I think you're missing the argument. I should be possible to create a
>> machine entirely from a FDT or via -device options.
>>
>> However, to continue to support the interfaces that we support today, it
>> will be necessary to have C code that manipulates a base device tree.
>>
>> When a user specifies '-M pc -hda foo.img' verses '-M versatilepb -hda
>> foo.img', the equivalent are two very different operations on a device
>> tree. The former adds an ide disk to the default controller and the
>> later potentially creates a new scsi bus and then adds a disk to a
>> specific bus.
>
> AFAICS the current commandline options only result in simple addition of
> devices. They might add slightly different devices in slightly different
> places, but that's easy to accommodate by having the machine define a few
> standard device/bus IDs.
>
> IMO it's even more lame if -hda shops working when you supply a device tree.
The tree supplied by the user should label a bus node with a property
'QEMU,hda'. The C version (called by the board) would be something
like setprop("/i440fx/pci.0/ide.0", "QEMU,hda"). QEMU should search
the device tree for such labels at startup.
Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support
> >> Because at some point the base tree will have to be written in C. > > > > No. You can start with a completely empty machine. > > We don't/shouldn't need any machine specific C code. > > I think you're missing the argument. I should be possible to create a > machine entirely from a FDT or via -device options. > > However, to continue to support the interfaces that we support today, it > will be necessary to have C code that manipulates a base device tree. > > When a user specifies '-M pc -hda foo.img' verses '-M versatilepb -hda > foo.img', the equivalent are two very different operations on a device > tree. The former adds an ide disk to the default controller and the > later potentially creates a new scsi bus and then adds a disk to a > specific bus. AFAICS the current commandline options only result in simple addition of devices. They might add slightly different devices in slightly different places, but that's easy to accommodate by having the machine define a few standard device/bus IDs. IMO it's even more lame if -hda shops working when you supply a device tree. Paul
Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support
On 06/08/2010 09:11 PM, Paul Brook wrote: Because at some point the base tree will have to be written in C. No. You can start with a completely empty machine. We don't/shouldn't need any machine specific C code. I think you're missing the argument. I should be possible to create a machine entirely from a FDT or via -device options. However, to continue to support the interfaces that we support today, it will be necessary to have C code that manipulates a base device tree. When a user specifies '-M pc -hda foo.img' verses '-M versatilepb -hda foo.img', the equivalent are two very different operations on a device tree. The former adds an ide disk to the default controller and the later potentially creates a new scsi bus and then adds a disk to a specific bus. We could force users to these explicit operations instead of the generic options we provide today but we would certain end up having our users hate us as a result. When I submitted the original qdev code I also posted a proof-of-concept patch that built the whole machine based on a config file with no hardcoded knowledge of the machine structure. And in your proof-of-concept patches, you couldn't use -hda or any of the other command line options that are currently used. To support those things, something would have to understand the device tree well enough to know what -hda is supposed to mean. That's the point of MachineCore. Of course you have to decide where to stop allowing customization, but anyway it will be significantly more complex than a QemuOpts config file. QemuOpts obviously doesn't have the flexibility to create an entire device tree. Why not? The current -device option already provides the majority of the functionality required. Most of the missing bits are incomplete qdev conversion. I'm not saying that creating a whole machine via -device options is an elegant solution (hence the interest in things like FDT) but in I see no reason why it shouldn't work. IMO all uses of the no_user flag are bugs resulting from incomplete/incorrect qdev conversions. I don't disagree. Regards, Anthony Liguori
Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support
> >>>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.
> >
> > That's the bit I don't get. Why are we significantly morphing a base
> > device tree? Surely it's easier to just use a different base tree.
>
> Because at some point the base tree will have to be written in C.
No. You can start with a completely empty machine.
We don't/shouldn't need any machine specific C code.
When I submitted the original qdev code I also posted a proof-of-concept patch
that built the whole machine based on a config file with no hardcoded
knowledge of the machine structure.
> Of course you have to decide where to stop allowing customization, but
> anyway it will be significantly more complex than a QemuOpts config
> file. QemuOpts obviously doesn't have the flexibility to create an
> entire device tree.
Why not?
The current -device option already provides the majority of the functionality
required. Most of the missing bits are incomplete qdev conversion.
I'm not saying that creating a whole machine via -device options is an elegant
solution (hence the interest in things like FDT) but in I see no reason why it
shouldn't work.
IMO all uses of the no_user flag are bugs resulting from incomplete/incorrect
qdev conversions.
> Want to let the user add an IDE controller? Fine, you need to provide
> him with a way of writing the following logic:
>
> for(i = 0; i < MAX_IDE_BUS * MAX_IDE_DEVS; i++) {
> hd[i] = drive_get(IF_IDE, i / MAX_IDE_DEVS, i % MAX_IDE_DEVS);
> }
> pci_piix3_ide_init(pci_bus, hd, piix3_devfn + 1);
>
> What do you do?
-device piix3-ide. See also docs/qdev-device-use.txt
Paul
Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support
On 08.06.2010, at 18:15, Anthony Liguori wrote: > >> 4) expose everything to the user, at the cost of regretting it later. This >> is the current patchset. >> >> >> One "smart way to implement default devices" could be an inclusion mechanism >> where a machine can ask qemu to read other config files. Then you'd have >> config files for the default serial/parallel/etc. This could also be >> implemented on top of choices 2/3/4 though. > > Default devices are a real pain. Fortunately, we only mess with it in s390 > so I'm fairly certain we can simplify things considerable. It's just not > something I wanted to tackle in this series. Wait, what? The only "default" device we have on s390 is virtio-console - and that's basically the same as having VGA output on x86 enabled by default, no? But either way, I agree that we should make things easy for 99% of the users. And taking incremental improvements is useful too. pc.c as it is right now can only be improved, no matter what you do with it. Alex
Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support
On 06/08/2010 04:05 PM, Alexander Graf wrote: On 08.06.2010, at 18:15, Anthony Liguori wrote: 4) expose everything to the user, at the cost of regretting it later. This is the current patchset. One "smart way to implement default devices" could be an inclusion mechanism where a machine can ask qemu to read other config files. Then you'd have config files for the default serial/parallel/etc. This could also be implemented on top of choices 2/3/4 though. Default devices are a real pain. Fortunately, we only mess with it in s390 so I'm fairly certain we can simplify things considerable. It's just not something I wanted to tackle in this series. Wait, what? The only "default" device we have on s390 is virtio-console - and that's basically the same as having VGA output on x86 enabled by default, no? What I was saying is that all the .no_vga/.no_serial/.use_virtcon bits in QEMUMachine are strictly due to s390. Since the use of these are so specific, it'll be fairly easy to eliminate them in a more natural way. What most other boards do is simply ignore whatever vl.c does FWIW. Regards, Anthony Liguori
Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support
One "smart way to implement default devices" could be an inclusion
mechanism where a machine can ask qemu to read other config files.
Then you'd have config files for the default serial/parallel/etc.
This could also be implemented on top of choices 2/3/4 though.
Defaults are tough because there are multiple ways to create devices
today. Here's something that could potentially address the problem.
I'll focus on -serial but it's equally applicable to the other default
devices.
We would introduce serial0, serial1, serial2, serial3 MachineCore
properties. These properties would be chardev names.
The pc machine types would do:
QOPT_VALUE("serial0", "__default_serial0");
In vl.c, we would always create a __default_serial0 chardev of 'vc'.
The -serial option would keep a counter and:
-serial mon:stdio -serial vc
Would be equivalent to:
-chardev mon:stdio,id=__serial0 -machine serial0=__serial0 \
-chardev vc,id=__serial1 -machine serial1=__serial1
-nodefaults simply suppresses the creation of the default serial devices.
It's the job of the MachineCore to try to find each of the serialN
properties and if the chardevs have been created, use qdev to create an
appropriate serial port device.
This would apply equally well to parallel and virtcon.
Networking is a bit of a nightmare as many boards simply ignore the
networking options. Floppy and cdrom can work in this way too.
Regards,
Anthony Liguori
Paolo
Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support
> > 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. That's the bit I don't get. Why are we significantly morphing a base device tree? Surely it's easier to just use a different base tree. Paul
Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support
On 06/08/2010 10:58 AM, Paolo Bonzini wrote:
On 06/08/2010 05:36 PM, Paul Brook wrote:
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.
That's the bit I don't get. Why are we significantly morphing a base
device
tree? Surely it's easier to just use a different base tree.
Because at some point the base tree will have to be written in C. Of
course you have to decide where to stop allowing customization, but
anyway it will be significantly more complex than a QemuOpts config
file. QemuOpts obviously doesn't have the flexibility to create an
entire device tree.
Want to let the user add an IDE controller? Fine, you need to provide
him with a way of writing the following logic:
for(i = 0; i < MAX_IDE_BUS * MAX_IDE_DEVS; i++) {
hd[i] = drive_get(IF_IDE, i / MAX_IDE_DEVS, i % MAX_IDE_DEVS);
}
pci_piix3_ide_init(pci_bus, hd, piix3_devfn + 1);
What do you do? Invent your own language (another YaST? no thanks)?
Massive refactoring of QEMU's bowels (cannot solve all the problems,
Anthony gave more examples in the email I replied to)? Keep C code
(then you're not doing anything different than what Anthony's
MachineCore is doing)?
Or punt all of the complexity to the user such that have to manually
figure out where in the device tree a drive has to be inserted. That's
not really reasonable IMHO.
I think there are four choices:
1) only merge the first 5-7 patches of the series, basically up to the
creation of -machine and conversion of -kernel/-initrd/-M/-m. This is
also what is needed for KVM's irqchip. Think about some other smart
way to implement default devices.
Or don't declare MachineCore options stable across releases. I concur
that we probably don't want to support some of these interfaces long
term but I think we can pretty quickly figure out some better interfaces.
The advantage of a full conversion is that it allows us to focus on
improving the interfaces since we'll have the architecture in place.
2) do not expose some things to the config files. This requires
implementing an additional QemuOpts feature for internal options, plus
the current patchset. It means that moving machine types out to
config files is not possible.
I dislike having internal only options as it means we have to keep
things within qemu. For things like max_cpus, I think we just need to
validate that we've got passed sane values. Setting max_cpus in a
global config is actually a really useful thing for downstreams to do
since they are all having a fixed support statement of X VCPUs per VM.
3) put some things into an implementation-dependent namespace, i.e.
__pci or __default_device or __serial. In the future it's possible to
these things in config files, just nobody has to worry about users
relying on them and can refactor to death. This is the current
patchset plus some search and replace, and is my favorite.
Yeah, I'm good with being explicit. I'd prefer x-pci or x-serial since
we've already established that as the experimential namespace.
4) expose everything to the user, at the cost of regretting it later.
This is the current patchset.
One "smart way to implement default devices" could be an inclusion
mechanism where a machine can ask qemu to read other config files.
Then you'd have config files for the default serial/parallel/etc.
This could also be implemented on top of choices 2/3/4 though.
Default devices are a real pain. Fortunately, we only mess with it in
s390 so I'm fairly certain we can simplify things considerable. It's
just not something I wanted to tackle in this series.
Regards,
Anthony Liguori
Paolo
Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support
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
Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support
On 06/08/2010 05:36 PM, Paul Brook wrote:
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.
That's the bit I don't get. Why are we significantly morphing a base device
tree? Surely it's easier to just use a different base tree.
Because at some point the base tree will have to be written in C. Of
course you have to decide where to stop allowing customization, but
anyway it will be significantly more complex than a QemuOpts config
file. QemuOpts obviously doesn't have the flexibility to create an
entire device tree.
Want to let the user add an IDE controller? Fine, you need to provide
him with a way of writing the following logic:
for(i = 0; i < MAX_IDE_BUS * MAX_IDE_DEVS; i++) {
hd[i] = drive_get(IF_IDE, i / MAX_IDE_DEVS, i % MAX_IDE_DEVS);
}
pci_piix3_ide_init(pci_bus, hd, piix3_devfn + 1);
What do you do? Invent your own language (another YaST? no thanks)?
Massive refactoring of QEMU's bowels (cannot solve all the problems,
Anthony gave more examples in the email I replied to)? Keep C code
(then you're not doing anything different than what Anthony's
MachineCore is doing)?
I think there are four choices:
1) only merge the first 5-7 patches of the series, basically up to the
creation of -machine and conversion of -kernel/-initrd/-M/-m. This is
also what is needed for KVM's irqchip. Think about some other smart way
to implement default devices.
2) do not expose some things to the config files. This requires
implementing an additional QemuOpts feature for internal options, plus
the current patchset. It means that moving machine types out to config
files is not possible.
3) put some things into an implementation-dependent namespace, i.e.
__pci or __default_device or __serial. In the future it's possible to
these things in config files, just nobody has to worry about users
relying on them and can refactor to death. This is the current patchset
plus some search and replace, and is my favorite.
4) expose everything to the user, at the cost of regretting it later.
This is the current patchset.
One "smart way to implement default devices" could be an inclusion
mechanism where a machine can ask qemu to read other config files. Then
you'd have config files for the default serial/parallel/etc. This could
also be implemented on top of choices 2/3/4 though.
Paolo
Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support
> The magic I'm preferring to is precisely things like pci="on". Hmm, pci=on is magic indeed. :-) > What I'm objecting to is making machine construction be controlled by an > arbitrary set of hardcoded parameters. > 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. Then it would be enough to have these options available internally for use in the machine-core but not export them to the command-line. If we only aim at using management interfaces to use the interface we can be very conservative and not export even things like default_drive. Paolo
Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support
> > 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. 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. > > 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. I don't see how the introduction of QemuOpts is relevant. That's just a flexible commandline option handling system, which makes a lot of sense. 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. 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. Paul
