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

[Marcel Apfelbaum]

On Mon, 2013-09-09 at 17:04 +0300, Michael S. Tsirkin wrote:
> On Mon, Sep 09, 2013 at 04:29:04PM +0300, Marcel Apfelbaum wrote:
> > On Mon, 2013-09-09 at 14:19 +0100, Peter Maydell wrote:
> > > On 9 September 2013 14:15, Marcel Apfelbaum <address@hidden> wrote:
> > > > On Mon, 2013-09-09 at 14:02 +0100, Peter Maydell wrote:
> > > >> Can you just pick the device which is (a subclass of)
> > > >> TYPE_PCI_HOST_BRIDGE, or do we have host bridges which
> > > >> aren't using that class?
> > > > This is what I would really want to do, but some HOST Bridge devices
> > > > inherit directly from PCI_DEVICE.
> > > 
> > > > TYPE_PCI_HOST_BRIDGE derives from TYPE_SYS_BUS_DEVICE which
> > > > is a not a PCI device and does not help us here (not a PCI_DEVICE
> > > > on the bus)
> > > 
> > > Oops, yes, I get those two the wrong way round a lot. Anyway,
> > > if we need to make all host bridges have a common subclass
> > > we could certainly refactor them accordingly.
> > > 
> > > > Strangely TYPE_Q35_HOST_DEVICE derives from TYPE_SYS_BUS_DEVICE
> > > > and it hold as composition a PCIDevice that will be part of
> > > > the bus, as opposed to TYPE_I440FX_PCI_DEVICE which directly
> > > > inherits from PCI_DEVICE.
> > > 
> > > This may just be wrong choice of name rather than actually
> > > wrong hierarchy.
> > I try not to "judge" the naming convention, so let's leave it
> > aside for now.
> > 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)
> > 
> > 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...
> 
> I wouldn't object to is_host is stuct PCIDeviceClass.
> That's probably easier that trying to create
> a common class for devices that share no common code.
This will work too, and less changes to the code.
However Peter suggested that we can unify both upstream
and downstream handling of the master abort by putting
it all in this class.
But if we have "is_host" flag, we can differentiate
regular devices from host devices and handle them different.

If there are no objections, I will chose this path.
Thanks!
Marcel




> 
> 
> > 
> > > 
> > > -- PMM
> >