From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:42196)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mst@redhat.com>) id 1VJ3r1-0006tO-P7
	for qemu-devel@nongnu.org; Mon, 09 Sep 2013 11:58:25 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <mst@redhat.com>) id 1VJ3qv-0006LH-O1
	for qemu-devel@nongnu.org; Mon, 09 Sep 2013 11:58:19 -0400
Received: from mx1.redhat.com ([209.132.183.28]:13713)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mst@redhat.com>) id 1VJ3qv-0006LA-F8
	for qemu-devel@nongnu.org; Mon, 09 Sep 2013 11:58:13 -0400
Date: Mon, 9 Sep 2013 19:00:14 +0300
From: "Michael S. Tsirkin" <mst@redhat.com>
Message-ID: <20130909160014.GH1930@redhat.com>
References: <20130909125914.GA1052@redhat.com>
	<CAFEAcA_AnnitjLwHvfRUceP6KvaDyz394fQMTBQ7ETXOY1w7tA@mail.gmail.com>
	<1378732537.3072.49.camel@localhost.localdomain>
	<CAFEAcA9zpFhkUP1QouZP0JToDBnzTvsBcDE7ufVc5skwS22aAw@mail.gmail.com>
	<1378733344.3072.58.camel@localhost.localdomain>
	<CAFEAcA9j34x__fnQdXY7K6NNSoobZOxsD61w-b=O57KpBZ74Qw@mail.gmail.com>
	<1378735459.3072.83.camel@localhost.localdomain>
	<CAFEAcA8iW6fkmxqgNM1raDp-8_LKkaufRqqzQZSThS1FSjGHxw@mail.gmail.com>
	<1378738262.3072.99.camel@localhost.localdomain>
	<CAFEAcA9W+J33+HCiti_=qZtY5A+htGLCtqT9VC=GF_MDBaxs7A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAFEAcA9W+J33+HCiti_=qZtY5A+htGLCtqT9VC=GF_MDBaxs7A@mail.gmail.com>
Subject: Re: [Qemu-devel] [PATCH RFC v2 2/2] hw/pci: handle unassigned pci
 addresses
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Anthony Liguori <aliguori@us.ibm.com>, Jan Kiszka <jan.kiszka@siemens.com>, QEMU Developers <qemu-devel@nongnu.org>, Marcel Apfelbaum <marcel.a@redhat.com>

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.
> 
> -- PMM

Device in question being PCI host right?
Just remove the assumption it's device 0...