qemu-devel
[Top][All Lists]
Advanced

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

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


From: Marcel Apfelbaum
Subject: Re: [Qemu-devel] [PATCH RFC v2 2/2] hw/pci: handle unassigned pci addresses
Date: Mon, 09 Sep 2013 17:04:19 +0300

On Mon, 2013-09-09 at 14:39 +0100, Peter Maydell wrote:
> 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)...
This I come to understand, thanks!
> 
> > 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.
And we solve the main issue - no need for an API for master abort
- for upstream: use your suggestion (let's hope it works)
- for downstream: look on the bus for a device deriving
  from this class and *this device* will handle the
  master abort
I'll find a way how to handle the PCI bridges.

By the way, I am not sure that the upstream transactions (DMA)
can actually end with a master abort. Master abort would happen
if a transaction will not be claimed by any device on the bus.
But in DMA transactions, maybe the host bridge will always claim it
and return with error. Does anybody know something about this?

Thanks for all the help!
Marcel




> 
> -- PMM





reply via email to

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