From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50458) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VJ4O1-0003A7-PH for qemu-devel@nongnu.org; Mon, 09 Sep 2013 12:32:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VJ4Nv-0008DW-Qp for qemu-devel@nongnu.org; Mon, 09 Sep 2013 12:32:25 -0400 Received: from mx1.redhat.com ([209.132.183.28]:23689) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VJ4Nv-0008DN-IO for qemu-devel@nongnu.org; Mon, 09 Sep 2013 12:32:19 -0400 Date: Mon, 9 Sep 2013 19:34:22 +0300 From: "Michael S. Tsirkin" Message-ID: <20130909163422.GI1930@redhat.com> References: <1378732537.3072.49.camel@localhost.localdomain> <1378733344.3072.58.camel@localhost.localdomain> <1378735459.3072.83.camel@localhost.localdomain> <1378738262.3072.99.camel@localhost.localdomain> <20130909160014.GH1930@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH RFC v2 2/2] hw/pci: handle unassigned pci addresses List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Paolo Bonzini , Anthony Liguori , Jan Kiszka , QEMU Developers , Marcel Apfelbaum On Mon, Sep 09, 2013 at 05:02:15PM +0100, Peter Maydell wrote: > On 9 September 2013 17:00, Michael S. Tsirkin wrote: > > On Mon, Sep 09, 2013 at 03:58:36PM +0100, Peter Maydell wrote: > >> On 9 September 2013 15:51, Marcel Apfelbaum 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