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, the ability to have arbitrary links between devices, beyond the hierarchical bus topology. 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. > > 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 -- John Williams, PhD, B. Eng, B. IT PetaLogix - Linux Solutions for a Reconfigurable World w: www.petalogix.com p: +61-7-30090663 f: +61-7-30090663
