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 05:02:15PM +0100, Peter Maydell wrote:
> On 9 September 2013 17:00, Michael S. Tsirkin <mst@redhat.com> wrote:
> > On Mon, Sep 09, 2013 at 03:58:36PM +0100, Peter Maydell wrote:
> >> On 9 September 2013 15:51, Marcel Apfelbaum <marcel.a@redhat.com> wrote:
> >> > On Mon, 2013-09-09 at 15:21 +0100, Peter Maydell wrote:
> >> >> 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.
> >> > Thanks, I am not familiar with versatilePB, I may be able
> >> > to code it, I don't know how to test it
> >>
> >> Don't worry about testing versatilePB particularly; you
> >> just need to make sure your code can cope with master
> >> aborts by device initiated transactions.
> >
> > Device in question being PCI host right?
> 
> No, in the scenario described above the device doing the write
> and getting the abort is the EHCI USB controller.
> 
> -- PMM


Well I think we shouldn't require handling this upfront - these
are very uncommon, typically a result of a driver bug.
OTOH master aborts from CPU are common, so a patch fixing
that would be a step in the right direction.

-- 
MST