Re: [Qemu-devel] [PATCH v2 0/7] APIC/IOAPIC cleanup

[Anthony Liguori]

On 08/22/2010 04:37 AM, Avi Kivity wrote:
>  On 08/19/2010 11:49 PM, Anthony Liguori wrote:
> > > The bus does not need to have any connection to existence or
> > > non-existence of real buses. In SoCs or ASICs, all devices and buses
> > > may reside inside a chip.
> >
> > Well, I think this is part of the trouble with the current qdev 
> > object model.  There are really two distinct types of devices.  There 
> > are chips that have pins whereas the meaning of those pins are 
> > defined by the chip itself.  For instance, a UART16650A is a chip 
> > that has a well defined pin layout.
> >
> > Then there are buses which typically multiplex signals for many 
> > devices over a single set of wires.  Usually you need some type of 
> > logic that decodes the bus signals to the actual chips that sit on 
> > the card.
> >
> > So really, I think this suggests that some devices shouldn't have any 
> > requirement to sit on a bus.  A UART16650A does not sit on bus.  It 
> > sits on a card and is wired to the ISA bus or is sometimes wired 
> > directly to pins on a CPU on a SoC.
>
> I don't think we want to model individual resistors on a serial card 
> as separate qdev objects.  We want the serial card itself to be a qdev 
> (as it is a hotpluggable entity) and the individual serial interfaces 
> on that card (as they are duplicates of each other and of interest to 
> the user).

You're missing the fundamental problem which arises because we've 
introduced an object model without thinking through how devices ought to 
be modelled.

All devices should have a DeviceState associated with them.  Otherwise, 
there's really no point in having qdev at all.

We have lots of devices today that don't have DeviceState's associated 
with them because the have a separate qdev representation with a 
reference to the non-DeviceState object.

We have non-DeviceState objects because otherwise we end up with an 
inheritance diamond.  We have this problem because we want to have 
relationships like: DeviceState <- SystemDeviceState <- ISADevice <- 
ISASerialDevice.

But ISASerialDevice is not the only type of serial device.  You can also 
have a SystemSerialDevice that's directly attached to the System bus.  
That means you'd have to have:

SerialDevice -> ISASerialDevice -> SystemDeviceState -> DeviceState
                     -> SystemSerialDevice -> SystemDeviceState -> 
DeviceState

Which is a classic MI diamond.  The only way to resolve this modelling 
problem is to split out the common code and rely on a has-a relationship 
instead of an is-a.  That gives you:

ISASerialDevice->SystemDeviceState->DeviceState
SystemSerialDevice->SystemDeviceState->DeviceState

ISASerialDevice has-a SerialDevice
SystemSerialDevice has-a SerialDevice

And since we want SerialDevice inherit from a DeviceState (recall, all 
devices should have DeviceStates):

SerialDevice->DeviceState

No more MI diamond and all devices have DeviceStates.  Coincidentally, 
it matches more closely how hardware works..

Generally speaking, any time we have one device that needs to sit on 
multiple busses, we're going to have to model it in this fashion.

Regards,

Anthony Liguori