qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Gleb Natapov
Subject: Re: [Qemu-devel] [RFC] Plan for moving forward with QOM
Date: Thu, 15 Sep 2011 19:59:21 +0300

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?

> 
> 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.

> 
> 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!

> 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?

> 
> 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.

--
                        Gleb.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]