From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48014) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VJ2MD-0000D8-67 for qemu-devel@nongnu.org; Mon, 09 Sep 2013 10:22:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VJ2Lu-0002OW-RX for qemu-devel@nongnu.org; Mon, 09 Sep 2013 10:22:25 -0400 Received: from mail-lb0-f181.google.com ([209.85.217.181]:35827) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VJ2Lu-0002OJ-KQ for qemu-devel@nongnu.org; Mon, 09 Sep 2013 10:22:06 -0400 Received: by mail-lb0-f181.google.com with SMTP id u14so5115270lbd.12 for ; Mon, 09 Sep 2013 07:22:05 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1378735459.3072.83.camel@localhost.localdomain> References: <1378725114-13197-1-git-send-email-marcel.a@redhat.com> <1378725114-13197-3-git-send-email-marcel.a@redhat.com> <20130909114029.GB31476@redhat.com> <1378728715.3072.14.camel@localhost.localdomain> <20130909122307.GB583@redhat.com> <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> From: Peter Maydell Date: Mon, 9 Sep 2013 15:21:44 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 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: Marcel Apfelbaum Cc: Paolo Bonzini , Anthony Liguori , Jan Kiszka , QEMU Developers , "Michael S. Tsirkin" 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