Re: [Qemu-devel] [RFC] Plan for moving forward with QOM

[Anthony Liguori]

On 09/15/2011 11:59 AM, Gleb Natapov wrote:
> On Thu, Sep 15, 2011 at 11:33:00AM -0500, Anthony Liguori wrote:
> > On 09/15/2011 10:38 AM, Gleb Natapov wrote:
> > > On Thu, Sep 15, 2011 at 10:28:52AM -0500, Anthony Liguori wrote:
> > > > On 09/15/2011 09:25 AM, Gleb Natapov wrote:
> > > >
> > > > There is no canonical parent link.  A device may have multiple (more
> > > > or less equivalent) parents.
> > > >
> > > > What should be treated as the "canonical" link depends on what
> > > > you're trying to do.  In the case of OF, you want to treat the bus
> > > > as a parent.  If a device happens to sit on multiple buses, I'm not
> > > > really sure what you do.
> > > Yes, "canonical" is a link to a bus. Can you give an example of a device
> > > that sits on multiple buses?
> >
> > Not all devices buses that they sit on.
> Missing "have"? If device has no bus how do you talk to it? Who carries
> the signal from a cpu to a device?
>
> > A good example is our favorite one to debate--the PIIX3.  Devices
> PIIX3 is a collection of devices, not a device.
>
> > like the UART don't sit on a bus.  They don't have any links at all.
> In PC UART sits on isa bus. How device can have no links at all? It just
> glued to a motherboard not touching any wires?

A bus implies a bidirectional relationship.  IOW, the device has to know that it 
sits on a ISA bus to be an ISA device.

The UART has no knowledge of the fact that is mapped behind ISA.  The UART 
exposes a public interface (through it's pins) that's orthogonal to any buses.

That public interface may be consumed by 1 or more consumers.  Some pins may be 
used by one device while other pins are used by another device.

Some other logic maps the UART to the rest of the system.  My view of modelling 
the PIIX3 that I illustrated in this thread is that the PIIX3 encompasses this 
logic.

Another way to view it, the PIIX3 has direct knowledge of a UART's public 
interface but a UART has no knowledge of the PIIX3's public interface.

> > Instead, the PIIX3 itself bridges the public interface of the UART
> > via its PC interface.  So it looks something like this:
> Again you are talking about particular HW implantation, not SW interface
> that the package implements and we need to emulate the later not the
> former.

I'm not.  There is no way for a UART to talk to the PIIX3.  You can't query it 
to figure out where it lives in the device graph.  All it can do is generate an 
interrupt and hope something is listening.  There is no hardware equivalent of 
'cpu_register_physical_memory'.  Some other piece of hardware has to route 
requests to it in a form that it understands.

> > class Serial : public Device
> > {
> >     uint8_t read(uint8_t addr);
> > };
> >
> > class PIIX3 : public PciDevice, implements PciBus
> > {
> >     Serial *tty[4];
> > };
> Make this isa slots, encapsulate UART into isa device and plug one
> into another. You just cut corners here. You wouldn't do the same for
> PCI device, but theoretically you can. You will be able to compose new
> chipset with config file too!

But then you need to have:

class IsaSerial : public IsaDevice
{
   Serial uart;
};

All you've done is take the dispatch logic and moved it from PIIX3 to IsaSerial 
for the only purpose of creating an artificial abstraction (of having a bus that 
doesn't exist).

All devices don't sit on buses.  That's the main design problem of qdev.

> > uint32_t PIIX3::pio_access(uint16_t addr, int size)
> > {
> >     if (addr == 0x3f8&&  this->tty[0]) {
> >         return this->tty[0]->read(addr - 0x3f8);
> >     } else {
> >         ...
> >     }
> > }
> Wow, hard coded that way? So another chipset implementation will
> have to duplicate the same exact code?

Yup.  We're moving to this model anyway with the memory API.  The Serial device 
will export a MemoryRegion where its registers start at address 0 and then a 
higher layer (IsaSerial or PIIX3) will add that MemoryRegion to it's 
MemoryRegion starting at a given offset.

> > There is no backlink in the Serial device so there's no way of
> > walking up the graph from the Serial device itself.  You have to
> > transverse to it to build a path.
> That because implementation cut corners (read "incorrect"). Actually
> ability to walk the graph all the way up is a good test that we didn't
> cheated anywhere by pretending that devices are connected by magic.

How do you "walk up the device graph" from a 16650A?  What signals are you going 
to send out of the pins to do that?

If a device can always do self->parent->parent->parent->send_io(foo) then the 
design is fundamentally broken and you will end up with devices that do things 
that they shouldn't do.

Regards,

Anthony Liguori

> --
>                         Gleb.