On Sun, Jun 12, 2011 at 10:21 PM, Anthony Liguori <aligu...@us.ibm.com> wrote: > On 06/12/2011 12:12 PM, Avi Kivity wrote: >> >> On 06/10/2011 06:43 PM, Anthony Liguori wrote: >>> >>>> What exactly is so very wrong about buses that they need to die? >>> >>> They force a device tree. The device model shouldn't be a tree, but a >>> directed graph. >> >> Right. As an example, you configure PCI interrupt routing and the memory >> controller by writing to a PCI device, which logically doesn't have >> access to any of this stuff if it's behind the PCI bus. >> >> However, I don't think buses should die. They should be available as an >> easy way to model the devices that do follow the rules. But we should >> also expose everything else for the exceptional cases. >> >>> It's perfectly fine to have a type called PCIBus that I440FX extends, >>> but qdev shouldn't have explicit knowledge of something called a "bus" >>> IMHO. Doing this forces a limited mechanism of connecting devices >>> because it creates an artificial tree (by implying a parent/child >>> relationship). It makes composition difficult if not impossible. >> >> I think qdev buses are useful as long as they don't enforce their >> interfaces. That is, a qdev that is a child of a qbus has access to the >> qbus's interfaces, but also access to other stuff. > > I see two independent data structures. The first is the "instantiation > tree". > > The instantiation tree may look like this: > > +-- i440fx > | | > | +-- PIIX3 > | | | > | | +-- mc146818a > | | +-- uart > | | +-- DMA > | | +-- keyboard controller > | | +-- (remaining platform ISA devices > | | > | +-- UHCI USB controller > | +-- IDE controller > | > +-- e1000 > +-- cirrus-vga > +-- virtio-balloon-pci > +-- IDE disk0 > > Instantiating i440fx makes a bunch of default stuff. This is composition. > Everything else requires explicit instantiation. This is, strictly > speaking, the parent/child relationships. If you destroy i440fx, all of > it's children have to also go away (by definition). Nothing about bus > relationship is implied here. Even if i440fx exposes a PCI bus, the PIIX3 > is a child of i440fx even though e1000 is not (even if they're both PCI > devices).
I actually like this slot idea in place of buses. But wouldn't there be two classes of devices (or two APIs), slot devices and composable devices? > That said, there absolutely should be the following paths: > > /i440fx/IDE controller/primary/master -> IDE disk0 > /i440fx/slot3 -> cirrus-vga > > The expression of bus should just be a bidirectional path (when that makes > sense). IOW: > > /i440fx/slot3 -> cirrus-vga > /cirrus-vga/bus -> i440fx > > There, of course, can be all sorts of crazy paths through the graph. The > following should be valid: > > /i440fx/slot2 -> IDE controller > /cirrus-vga/bus/slot2/primary/master > > But separating out hw paths from instantiation tree has some nice > characteristics. The instantiation tree is the obvious place to implement > live migration whereas reset would probably walk device paths. > > Regards, > > Anthony Liguori > >
