From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:33243) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QliDr-00048n-0a for qemu-devel@nongnu.org; Tue, 26 Jul 2011 10:03:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QliDp-0007FW-1E for qemu-devel@nongnu.org; Tue, 26 Jul 2011 10:02:58 -0400 Received: from mail-yx0-f173.google.com ([209.85.213.173]:57443) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QliDo-0007FO-I8 for qemu-devel@nongnu.org; Tue, 26 Jul 2011 10:02:56 -0400 Received: by yxt3 with SMTP id 3so326597yxt.4 for ; Tue, 26 Jul 2011 07:02:56 -0700 (PDT) Message-ID: <4E2EC90E.8090409@codemonkey.ws> Date: Tue, 26 Jul 2011 09:02:54 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1311558293-5855-1-git-send-email-aliguori@us.ibm.com> <4E2EBA1E.90006@redhat.com> In-Reply-To: <4E2EBA1E.90006@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC][PATCH 0/21] QEMU Object Model List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org On 07/26/2011 07:59 AM, Paolo Bonzini wrote: > For host devices (Char/Block/Network) we have a relatively simple > interface but we need a richer way to create and destroy the objects at > runtime. We have it already for block and network, we don't for char, > but it is done ad hoc for each hierarchy. We do not have a deep > hierarchy, in fact there is no hierarchy at all (only one abstract class > per subsystem). > > Honestly, it is not too bad. It may not be the cleanest code, but is it > worth the kind of ramifications that your patch has? Of course, the > answer could be "yes" if the same model can be applied to devices. > Devices do have the same introspection needs more or less, and I like > your ideas there. However, the requirements are very different in terms > of composition. > > Also because there is no hierarchy, composition in host devices can be > done very easily. A decorator for char/block devices, such as a "tee" > device, can treat the wrapped object(s) the same independent of the > actual class. A simple vtable works very well. GObject would also do > well, unifying the introspection at the cost of significantly more > boilerplate. The polymorphism model of QOM is identical to GObject so I'm not sure what you mean here. In the case of tee, it's just an object with two sockets. > (Of course, we could rewrite QEMU in Vala). > > For *guest* devices, however, this is not the case. The PCI host needs > to know that the device on the other end is a PCI device. Even the > simplest bus, for example I2C, has methods defined on its children. I have PCI patches, but didn't post them in the series. Here's how it works: The PCI host controller, the i440fx, has 32 sockets of PCIDevice. PCIDevice is a base class. The PCI host controller implements a PCIBus interface. The PCIDevices have a socket of a PCIBus Connecting a PCIDevice to the host bus involves setting the socket on the PCI host controller with the PCIDevice and then setting the PCIDevice's bus socket with the host controller. A PCIDevice can also be a PCIBus by implementing the PCIBus interface. This is what enables a PCI bridge to make sense in this model. If you're interested, the tree that has this is http://repo.or.cz/w/qemu/aliguori.git/tree/qdev2:/devices > So, the most important point, it seems to me, is to support composition > effectively. There need not be any hierarchy at all---not even the > two-level hierarchy we have now, everything can inherit from > DeviceState---but the combination between devices must be: I think composition is being overloaded here. When I say composition, I mean that one device is created out of multiple other devices. Something like the PIIX3 is composed of an RTC, UART, etc. That's different that connecting up the links in the device tree graph. > 1) in a flexible manner, so that it can express complex topologies (as > long as "plugs" and "sockets" have the same shape of course); Right, this is what we do today in QOM. Plugs and Sockets are typed. Those types can be interfaces or base classes so there's a lot of flexibility. > 2) in an easily introspectable manner, so that migration and QMP and so > on work very well in the presence of said topologies; The 'qsh' tree can view the entire device model as a synthetic file system. Plugs are represented as sub directories and sockets as symbolic links. I plan on writing a quick FUSE file system too. There is type information with all of the attributes that's not visible in this view but it's there nonetheless. > 3) in a precise manner, so that the two devices being connected can > interact effectively; > > > The current qdev fails completely at (1). (2) is very limited if you > consider qdev only; qdev+VMState is at least decent, though nowhere near > the potential of QOM. > > However, qdev gets (3) right by making interaction between the parent > and the child go through a bus object that knows the details of both. In > particular, bus objects and their vtable structures are very effective > in qdev because they provide flexibility and avoid impedence mismatch, > with a very limited amount of boilerplate. > > By contrast, the plug/socket model in QOM achieves (1) and (2), but in > my opinion it fails at (3). The model for example is not effective in > specifying the properties of the socket, which are roughly are the bus > properties and the fields added by DeviceState abstract subclasses in > the current qdev; There are no properties of the socket. If you look at something like adding a PCI device in qdev, you add a child and set properties of the child to identify how the device sits on the PCI bus. I'd characterize this as awkward, at best. The slot index is not a property of the device, it's a property of how the device is connected to the PCI bus. In my attempt at PCI modelling, I had something like: struct I440FX { Device parent; PciDevice slots[32]; }; Which means that to attach to bus 0, slot 3, fn 0, you do: i440fx->slots[3] = mydevice Likewise, if slot 4 contains a PCI-to-PCI bridge that ends up being bus 1, and you want to assign to bus 1, slot 2, fn 0: i440fx->slots[4]->slots[2] = myotherdevice; Now you may observe that this is awkward compared to saying "bus 1". But bus numbering is actually a guest concept, not a hardware concept. When constructing the device tree, the physical topology is actually what make sense in terms of constructing devices, not a guest derived numbering concept. The same applies equally to IDE. You'd have: struct IDEBus { IDEDevice *master, *slave; }; struct IDEChipset { IDEBus primary; IDEBus secondary; }; This would result in: ide->primary.master = disk1; ide->secondary.master = cdrom; > it is not clear where they would live in QOM. Perhaps > in the parent device or in an intermediate object between the parent and > the child; if the latter, it looks like a lot of pointer chasing and a > conversion nightmare. It's a characteristic of the property itself. It's definitely very different than how we do it today. > > Based on my earlier conversations with Peter, I thought a bit on how to > do more incremental changes to qdev in order to overcome the > inflexibility. Here is a rough overview of the steps: > > > 1) make properties more flexible. In particular, we *absolutely* need > array properties, either static or dynamic. The current special casing > of GPIO pins is required exactly because we do not have arrays of > properties. > > Also, since arrays occur a lot in the device state, array properties > would also be required to be able to introspect on run-time properties > (which are now part of VMState only). However, I am not going to > consider run-time introspection much more. It is "a simple matter of > programming" if your general introspection design is done right. Arrays of properties already work in QOM. Part of the trouble with qdev today (and QObject for that matter), is that properties are a characteristic of a class, not an object. This is the primary difference between the QOM Plug and is required for proper array support. > 2) add more kinds of first-class (user specifiable) properties. GPIO > pins, for example, which are already part of qdev but cannot be > specified by the user on the command line. Possibly memory regions too. > Anything that can be used to configure a device (with respect to the > main bus or to its parent) should be a property. > > > 3) at this point, you can get rid of the specialties of SysBus devices. > IRQs are an array of GPIO properties, same for memory regions. SysBus > devices can use a naked DeviceState structure. > > At this point, many embedded devices could be entirely described in > terms of configuration files, except for legacy options (-serial kind) > and for the few devices that attach directly to the CPU. This without > the need to define artificial buses that do not exist in real hardware. > > > 4) add support for compound properties. A compound properties is such > that you define a property named (coincidence...) "bus" and you get > automatically "bus.parent", "bus.addr", "bus.romfile", "bus.rombar" etc. Because QOM uses visitors for properties, properties can be arbitrarily complicated structures. How that maps to command line arguments, I haven't thought through yet but you can certainly do: plug_set(obj, "bus", { 'parent': x, 'addr': y, ...}) > > 5) convert buses to compound properties. Rather than inheriting from > PCIDevice, a PCI device would inherit straight from DeviceState and > include a PCIDevice struct that defines the backlink from a device to > its parent. Note that since we're using C, this is not a big change from > what we're doing now! (Inheritance by containment is a special case of > containment.) And it allows to define very flexibly a device that would > have to sit on two or more buses in the current qdev model. More > importantly, it keeps the effectiveness of the qbus ops model, while > removing the constraint of a tree topology. Interfaces are the right way to do this. Getting MI right is fairly hard and since qdev uses a simple container_of, it's not going to work very well. That's another advantage of QOM, casting from interfaces to objects Just Works. > > > It is only when this is done, that we should reconsider introspection > and see if it is useful/sensible to unify the host and guest device > object models. > > Because the host models we have now, with all the defects they may have, > *work*. The guest models hardly work for anything but PCs, and even then > only for the subset of devices which are interesting to hot-plug/unplug. > And so it is from them that we should start designing. > > Thoughts? I think all of the requirements you've outlined are currently handled in QOM. I think it would probably be a good idea to set up a wiki page that focused just on qdev-next requirements and that would give us a rigorious mechanism to evaluate how well QOM satisfies those requirements. I haven't thought through how to do OQM incrementally with qdev. It's probably possible but I wanted to focus on the backends first before really attacking that. Regards, Anthony Liguori > > Paolo > >