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