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

[Anthony Liguori <anthony@codemonkey.ws>]

On 09/16/2011 09:46 AM, John Williams wrote:
> On Thu, Sep 15, 2011 at 11:17 PM, Anthony Liguori<anthony@codemonkey.ws>  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