From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47380) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4azj-0001T9-JK for qemu-devel@nongnu.org; Fri, 16 Sep 2011 12:10:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R4azf-0004IS-FC for qemu-devel@nongnu.org; Fri, 16 Sep 2011 12:10:27 -0400 Received: from mail-gw0-f53.google.com ([74.125.83.53]:33391) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4azf-0004IL-8K for qemu-devel@nongnu.org; Fri, 16 Sep 2011 12:10:23 -0400 Received: by gwj20 with SMTP id 20so3949791gwj.12 for ; Fri, 16 Sep 2011 09:10:22 -0700 (PDT) Message-ID: <4E7374EB.2050407@codemonkey.ws> Date: Fri, 16 Sep 2011 11:10:19 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4E70EC90.8000904@us.ibm.com> <20110915063121.GW21417@redhat.com> <4E71FAD9.1000405@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] Plan for moving forward with QOM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: John Williams Cc: Peter Maydell , Gleb Natapov , Jan Kiszka , qemu-devel , Markus Armbruster , Gerd Hoffmann , "Edgar E. Iglesias" On 09/16/2011 09:46 AM, John Williams wrote: > On Thu, Sep 15, 2011 at 11:17 PM, Anthony Liguori 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