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

["Michael S. Tsirkin" <mst@redhat.com>]

On Tue, Sep 10, 2013 at 01:50:47PM +0100, Peter Maydell wrote:
> On 10 September 2013 13:39, Michael S. Tsirkin <mst@redhat.com> wrote:
> > On Mon, Sep 09, 2013 at 02:16:41PM +0100, Peter Maydell wrote:
> >>     memory_region_init_alias(&pci_dev->bus_master_enable_region,
> >>                              OBJECT(pci_dev), "bus master",
> >>                              dma_as->root, 0,
> >>                              memory_region_size(dma_as->root));
> >>
> >> If instead of using this alias directly as the
> >> bus_master_enable region you instead:
> >>  * create a container region
> >>  * create a 'background' region at negative priority
> >>    (ie one per device, and you can make the 'opaque' pointer
> >>    point to the device, not the bus)
> >>  * put the alias and the background region into the container
> >>  * use the container as the bus_master_enable region
> >
> > Interesting. There's one thing I don't understand here:
> > as far as I can see bus_master_enable_region covers the
> > whole 64 bit memory address space.
> >
> > It looks like it will always override the background
> > region in the same container. What did I miss?
> 
> That should be itself a container,
> so assuming it doesn't
> itself have any kind of background region the "holes"
> inside it will still be present when we put it in
> our new container. (Basically putting a container,
> or an alias to one, inside a region is just saying
> "put everything in that container inside this region
> at the appropriate place").

Confused.  "That" and "it" here refers to what exactly?

> >> then you will get in your callback a pointer to the
> >> device which caused the abort. You can then have your
> >> callback call a method defined on PCIDevice which we
> >> implement:
> >>  * as do-nothing in the PCI device base class
> >>  * as set-the-master-abort bit in the PCI host bridge
> >>    class
> >> (and anybody who wants to get fancy about handling aborts
> >> can override it in their own device implementation)
> >>
> >> That seems achievable without really requiring new
> >> infrastructure. Have I missed something that wouldn't
> >> work if we did this?
> 
> > Actually, I think a base class would have to set received master abort
> > bit in the status register.
> > And it's not even that simple: memory writes are completed by a P2P
> > bridge so I think it has to set a bit in the primary status register for
> > the bridge and not for the device (though I'm speaking from memory,
> > need to check the spec).
> 
> Yes, I didn't really work through how bridges might
> need to be handled. Hopefully we can come up with
> a neat trick for those too :-)
> 
> -- PMM