From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:52003) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4Znx-0001CB-92 for qemu-devel@nongnu.org; Fri, 16 Sep 2011 10:54:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R4Znv-00045a-Mt for qemu-devel@nongnu.org; Fri, 16 Sep 2011 10:54:13 -0400 Received: from mail-yi0-f45.google.com ([209.85.218.45]:56620) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4Znv-00045P-Jb for qemu-devel@nongnu.org; Fri, 16 Sep 2011 10:54:11 -0400 Received: by yib2 with SMTP id 2so3611696yib.4 for ; Fri, 16 Sep 2011 07:54:10 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4E71FAD9.1000405@codemonkey.ws> References: <4E70EC90.8000904@us.ibm.com> <20110915063121.GW21417@redhat.com> <4E71FAD9.1000405@codemonkey.ws> From: John Williams Date: Sat, 17 Sep 2011 00:46:11 +1000 Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC] Plan for moving forward with QOM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Peter Maydell , Gleb Natapov , Jan Kiszka , Markus Armbruster , qemu-devel , Gerd Hoffmann , "Edgar E. Iglesias" On Thu, Sep 15, 2011 at 11:17 PM, Anthony Liguori w= rote: > 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. =A0A QOM >>> path name >>> consists of a named device, followed by a series of properties which >>> may or may >>> not refer to other devices. =A0For instance, all of the following are >>> valid paths: >>> >>> =A0/i440fx/piix3/i8042/aux >>> =A0/i440fx/slot[1.0]/i8042/aux >>> =A0/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. =A0The 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. =A0OF is not a canonical > representation of arbitrary hardware. =A0It's a representation chosen (us= ually > by a human) of what information about the hardware is needed by the OS-le= vel > software. That need not be the case - with the link=3D<&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. =A0The reas= on > 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 --=20 John Williams, PhD, B. Eng, B. IT PetaLogix - Linux Solutions for a Reconfigurable World w: www.petalogix.com=A0=A0p: +61-7-30090663=A0 f: +61-7-30090663