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

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

On Mon, Sep 09, 2013 at 03:21:44PM +0100, Peter Maydell wrote:
> On 9 September 2013 15:04, Marcel Apfelbaum <marcel.a@redhat.com> wrote:
> > 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?
> 
> No, it's perfectly possible for a bus master transaction
> to abort. The PC's host controller happens to be set up so
> that bus master DMA covers the whole of the PCI memory space
> and so it's probably not possible to get an abort on that
> platform, but this isn't necessarily the case. For instance
> the versatilePB's PCI controller only responds to accesses
> within its programmed MMIO BAR ranges, so if the device
> or the controller have been misconfigured you can get an
> abort when the device tries to do DMA. (This usually causes
> the device to decide something has gone seriously wrong.
> For instance an EHCI USB controller device will stop
> and set the STS_FATAL bit in its status register:
> http://lxr.free-electrons.com/source/include/linux/usb/ehci_def.h#L96
> 
> If we wanted to implement this correctly we would need
> to be able to return an "access succeeded/failed" indicator
> from dma_memory_write(): check hw/usb/hcd-ehci.c:get_dwords()
> (which already has the logic for "whoops, DMA failed"
> for the extremely simple case of "no DMA address space").
> 
> -- PMM

Yes but that's not enough, you also need to set
the PCI status accordingly (and optionally AER if enabled  ...)