On 9 September 2013 14:29, Marcel Apfelbaum <marce...@redhat.com> wrote: > My issue is that we have at least 2 ways to model the bridges: > 1. TYPE_PCI_HOST_BRIDGE > * derives from TYPE_SYS_BUS_DEVICE > * has a bus > * one of the bus devices is a TYPE_I440FX_PCI_DEVICE which > derives from TYPE_PCI_DEVICE > 2. TYPE_PCIE_HOST_BRIDGE > * derives from TYPE_PCI_HOST_BRIDGE which derives > from TYPE_SYS_BUS_DEVICE > * has a PciDevice and register it to the bus in order > to work as (1)
So I think there are two different (and slightly confusing) things here: (1) the model of the host's PCI controller; this is typically derived from TYPE_SYS_BUS_DEVICE somehow but I guess in theory need not be; often it's a TYPE_PCI_HOST_BRIDGE or TYPE_PCIE_HOST_BRIDGE. (2) the PCI device which sits on the PCI bus and is visible to the guest, usually with a PCI class ID of PCI_CLASS_BRIDGE_HOST (but not necessarily; versatile is different, for instance). Currently we generally make these direct subclasses of TYPE_PCI_DEVICE. [The naming convention confusion arises because different controllers are inconsistent about how they name these classes and which type name ends up with 'host' in it.] What you're going to get in the callback is (2)... > I would like to implement an hierarchy that will allow > all the host bridge devices to have a common ancestor > In this was, we can scan the PCI bus to look for > master... ...and yes, we could insert an extra class and make all those bridge hosts derive from it rather than directly from TYPE_PCI_DEVICE if we needed to. -- PMM
