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

[Gleb Natapov]

On Thu, Sep 15, 2011 at 12:51:23PM -0500, Anthony Liguori wrote:
> 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.
> 
And ISA device with UART on it definitely knows that.

> 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.
> 
The UART itself has no knowledge, yes. But UART does not exists in
vacuum. It is always a part of other device that provides bus logic.
Original PC provided 2 or 4 ISA devices with UART on them. That is how
we need to model them on a PC. You can (or could) easily buy PCI card
with many more additional UARTs. You wouldn't claim that those UARTs are
not on the PCI bus, would you?

> 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.
> 
That is where we differ. My view that there is no such device as PIIX3
(really what is the functionality of this device?).  PIIX3 is only a
collection of devices. It provides ISA bus logic and it also has 4 ISA
UART cards and each card has the logic to decode access to it.

> 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
Why UART should talk to PIIX3 (what is this PIIX3 anyway)?

> can't query it to figure out where it lives in the device graph.
The way you model it - PIIX3 will have this knowledge. The way I propose
to model it ISA UART card will have it. But really, thinking more about
it there is no much difference. The part that decodes access to UART can
provide its OF path name node. So in you model PIIX3 will have to be
able to provide OF path name node for each device it includes. Not so elegant.

> 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.
Correct. I am not saying UART is an ISA device, I am saying UART is a
part of ISA device. It may be a part of PCI device or something other.
 
> 
> >
> >>
> >>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;
> };
> 
OK.

> 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).
It is exists. It decodes access from CPU (in/out) and pass it to UART.
You are saying that since this logic physically resides on PIIX3 chip it
is not ISA bus logic, but PIIX3 logic.

> 
> All devices don't sit on buses.  That's the main design problem of qdev.
> 
Why not? Bus is something that carries signals. Each device needs to
get/set signals to do something useful. One line can be a valid bus.
I thought that qdev problem was that it mandates tree topology.
I can see how device can be on multiple buses (I do not know one),
but not on a bus at all...?

> >>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?
16650A is not a device. ISA card it resides on is a device.
 
> 
> 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.
> 
Why?

--
                        Gleb.