On Mon, Sep 09, 2013 at 03:21:44PM +0100, Peter Maydell wrote: > On 9 September 2013 15:04, Marcel Apfelbaum <marce...@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 ...)