On 10 September 2013 13:39, Michael S. Tsirkin <m...@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"). >> 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