Re: [Qemu-devel] [RFC] Plan for moving forward with QOM

[Anthony Liguori]

On 09/16/2011 09:46 AM, John Williams wrote:
> On Thu, Sep 15, 2011 at 11:17 PM, Anthony Liguori<address@hidden>  wrote:
> > On 09/15/2011 01:31 AM, Gleb Natapov wrote:
> > > On Wed, Sep 14, 2011 at 01:04:00PM -0500, Anthony Liguori wrote:
> > > > All device relationships are identified as named properties.  A QOM
> > > > path name
> > > > consists of a named device, followed by a series of properties which
> > > > may or may
> > > > not refer to other devices.  For instance, all of the following are
> > > > valid paths:
> > > >
> > > >   /i440fx/piix3/i8042/aux
> > > >   /i440fx/slot[1.0]/i8042/aux
> > > >   /i440fx/slot[1.0]/bus/piix3/i8042/aux
> > > Have you looked at device paths generated by get_fw_dev_path() in qdev?
> >
> > get_fw_dev_path() won't exist in QOM.  The fact that it exists in qdev is a
> > problem with qdev.
> >
> > > This function generates Open Firmware device path.
> >
> > The function generates *a* OF device path.  OF is not a canonical
> > representation of arbitrary hardware.  It's a representation chosen (usually
> > by a human) of what information about the hardware is needed by the OS-level
> > software.
>
> That need not be the case - with the
>
>   link=<&target>
>
> syntax, device trees can be topologically accurate descriptions - this
> is part of our still-unreviewed patchset,

It's not unreviewed.  Any type of machine configuration needs to be done using 
qdev/qom factory interfaces, not implementing custom logic tied to a config format.

Can you construct OF paths based on link attributes?  What would that look like 
in practice?

> Another counter-example - our device trees are autogenerated out of a
> high level system synthesis tool.  One path is a device tree for QEMU
> and kernel configuration, the other is to actually create the system
> based on a high level design specification.

That's all well and good, but the mechanism that I think is important to have in 
QEMU is a programmatic interface for constructing and manipulating the guest 
devices.  A config file is not a programmatic interface.  You can implement 
config file support in terms of a programmatic interface but implementing the 
later in terms of the former is extremely painful.

Regards,

Anthony Liguori

> > If you look at what other folks have done with OF integration in QEMU,
> > you'll see a recurring theme of two OF trees, one used to create the
> > hardware and the other that is actually exposed to the guest.  The reason
> > you need two is because guests sometimes expect very specific things that
> > you really can't generate programmatically in every circumstance.
>
> Again this is contrary to our experience - the predominant reason we
> have differing OF trees is because we routinely encounter machine
> models that contain devices that QEMU knows nothing about.  So, we
> invalidate them in the device tree before passing it through to the
> guest kernel, to avoid the problem of drives trying to probe hardware
> that isn't there.
>
> John