Re: [Qemu-devel] [PATCH RFC v2 2/2] hw/pci: handle unassigned pci addresses

[Peter Maydell]

On 9 September 2013 14:29, Marcel Apfelbaum <address@hidden> 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