Re: [Qemu-devel] [RFC][PATCH 0/21] QEMU Object Model

[Paolo Bonzini <pbonzini@redhat.com>]

On 07/26/2011 05:34 PM, Anthony Liguori wrote:
>> And as such it can add data members. But when a device is on two buses,
>> you cannot have both of them adding data members. I know MI is hard to
>> get right, and in fact I'm not proposing to do MI---not even interface
>> inheritance. I don't want to have any base class but DeviceState.
>
> I could use a concrete example here, but here's how this would be
> expressed:
>
> class MyWeirdDevice : public MyBaseDevice, implements PciDevice, IsaDevice
> {
> PciBus *pci_bus;
> IsaDevice *isa_bus;
> };
>
> Which actually models hw pretty well. A device that exists on two busses
> has to have two sockets that can accept the plugs from the busses
> they're joining.
>
> It's pretty much exactly how it works in real life.

You could just as well say that real life works like this:

class PciSocket {
     PciBus *pci_bus;
     uint8_t *config;
     uint8_t *cmask;
     uint8_t *wmask;
     uint8_t *w1cmask;
     uint8_t *used;
     uint32_t devfn;
     char name[64];
     PCIIORegion io_regions[PCI_NUM_REGIONS];
     ...

};

class IsaSocket {
     IsaBus *isa_bus;
     uint32_t isairq[2];  // not sure this is a good idea, just
     int nirqs;           // mimicking qdev
     uint16_t ioports[32];// statically assigned unlike PCI bars
     int nioports;
}

class MyWeirdDevice : public MyBaseDevice {
     PciSocket pci;
     IsaSocket isa;
};


>> Yes, this is pretty much what I had imagined. But it does not scale to a
>> topology where you have two parents, both of which want to add data
>> members.
>
> Which would be true MI. The problem with true MI is that you'll end up
> with a diamond if you try to have anything useful (like properties) in
> the base.

See above for how you would avoid that.

>>>> 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.
>>
>> Interfaces (is-a) are less flexible than embedded objects (has-a).
>
> It depends on what you're trying to model I guess. In some cases where
> the interface is more or less stateless or that state isn't common among
> implementations, interfaces are quite nice.

Yes, I'm not sure this is the case here. :)

>  > Same as IDE when you used to set
>> jumpers to choose master/slave. Or ISA interrupt lines.
>
> The ISA dip switches literally select which line of the bus gets routed
> to the device. All devices have access to all interrupt lines through
> the bus.
>
> So when modelling, it makes sense to have the irq be a property of the
> device and then to have the bus interface expose the irqs. For instance:
>
> struct IsaBusClass
> {
> void (*set_irq_level)(IsaBus *bus, int irq, bool level);
> };

Agreed.  Though I'm not sure that the same is true for all fields in 
qemu's current PCIDevice.

>> Once you have something like this for a device that bridges two buses,
>> interfaces require a lot of boilerplate for useless getters/setters.
>
> Can you elaborate?

If you store data (configuration space etc.) in the device, and the bus 
has to access it, you need getters/setters in the interface.  Letting 
the bus hold an interior reference to the PciSocket (perhaps adding a 
single get_device_for_socket function to the PciSocketOps) solves the 
problem.

>>> The same applies equally to IDE.
>>>
>>> ide->primary.master = disk1;
>>> ide->secondary.master = cdrom;
>>
>> For IDE, an equally good model would be:
>>
>> ide->primary.add(disk1);
>> disk1.masterSlave = MASTER;
>> ide->secondary.add(cdrom);
>> cdrom.masterSlave = MASTER;
>
> There's a pin in the IDE cable that determines master or slave depending
> on whether it's raised high.

Yes, that's the "newer" way.  There used to be jumpers to choose between 
master, slave and cable-select.

> I think modelling it that way makes more sense from an end user
> perspective since it prevents the possibility of have two master devices
> (which is incorrect).

... but you could do that, if for some reason you wanted to model the 
jumper-based world.  But this is a mostly irrelevant digression.

>>> Interfaces are the right way to do this. Getting MI right is fairly hard
>>
>> But we don't need is-a, we need has-a. Multiple is-a is harder than
>> single is-a. Multiple has-a does not add any complication.
>
> Yeah, that's what plug properties are for :-)

I agree, but at the cost of pointer chasing and making it harder to 
implement get_device_for_socket for buses that need it (in the above 
sketch it can be a simple container_of).

>>> I think all of the requirements you've outlined are currently handled in
>>> QOM.
>>
>> They more than likely are. The question is whether they're handled in
>> the most programmer-efficient manner, and whether the advantages of a
>> single grand unified object model for host and guest devices is worth
>> the effort.
>
> Indeed. I think that it's a no brainer for the backends and that's why
> I'm starting there.

I don't think it's a no brainer.  It's simply much easier, but right now 
it is also a solution in search of a problem (if all you want is dynamic 
creation of character devices, you could do that without a generic 
object model).

If starting from a blank slate, I would be much more enthusiastic.  But 
all that QEMU does _not_ need is yet another incomplete transition.

Paolo