From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40556) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VJ3lC-0004YW-KJ for qemu-devel@nongnu.org; Mon, 09 Sep 2013 11:52:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VJ3l6-0004At-Fo for qemu-devel@nongnu.org; Mon, 09 Sep 2013 11:52:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:2020) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VJ3l6-0004Aj-67 for qemu-devel@nongnu.org; Mon, 09 Sep 2013 11:52:12 -0400 Date: Mon, 9 Sep 2013 18:54:15 +0300 From: "Michael S. Tsirkin" Message-ID: <20130909155415.GE1930@redhat.com> References: <1378730629.3072.32.camel@localhost.localdomain> <20130909125914.GA1052@redhat.com> <1378732537.3072.49.camel@localhost.localdomain> <1378733344.3072.58.camel@localhost.localdomain> <1378735459.3072.83.camel@localhost.localdomain> 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 03:21:44PM +0100, Peter Maydell wrote: > On 9 September 2013 15:04, Marcel Apfelbaum 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 ...)