From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41605) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X2ncO-0005rH-7e for qemu-devel@nongnu.org; Thu, 03 Jul 2014 16:28:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X2ncI-0004sL-Pg for qemu-devel@nongnu.org; Thu, 03 Jul 2014 16:28:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:20564) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X2ncI-0004sH-GD for qemu-devel@nongnu.org; Thu, 03 Jul 2014 16:28:26 -0400 Date: Thu, 3 Jul 2014 23:30:25 +0300 From: "Michael S. Tsirkin" Message-ID: <20140703203025.GD30281@redhat.com> References: <1404375987-29810-1-git-send-email-tamlokveer@gmail.com> <53B517CD.7090209@web.de> <20140703100219.GA24859@redhat.com> <53B5888F.50609@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53B5888F.50609@web.de> Subject: Re: [Qemu-devel] [PATCH] ahci: map memory via device's address space instead of address_space_memory List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: kwolf@redhat.com, peter.maydell@linaro.org, Le Tan , qemu-devel@nongnu.org, pbonzini@redhat.com, afaerber@suse.de On Thu, Jul 03, 2014 at 06:45:03PM +0200, Jan Kiszka wrote: > On 2014-07-03 12:02, Michael S. Tsirkin wrote: > > On Thu, Jul 03, 2014 at 10:43:57AM +0200, Jan Kiszka wrote: > >> On 2014-07-03 10:26, Le Tan wrote: > >>> In map_page() in hw/ide/ahci.c, replace cpu_physical_memory_map() and > >>> cpu_physical_memory_unmap() with dma_memory_map() and dma_memory_unmap(), > >>> because ahci devices should not access memory directly but via their address > >>> space. Add an AddressSpace parameter to map_page(). In order to call > >>> map_page(), we should pass the AHCIState.as as the AddressSpace argument. > >> > >> BTW, when doing "git grep cpu_physical_memory_map hw", there are some > >> more cases that should be checked (for x86). I suppose vhost is > >> incompatible with an IOMMU, > > > > vhost can be made to work: you just need to > > update its memory tables as appropriate. > > But see below > > > >> but plain virtio should work, > > > > It doesn't: all guests pass in physical addresses at the moment. > > You mean they do not put virtio devices into IOMMU domains, or they do > put them but ignore any translation rules that are not 1:1? Look at the code. We just pass in physical addresses ignoring which iommu domain device ended up with. > > We discussed requiring this for virtio 1.0, but in the end, > > most people thought that passing through virtio devices > > isn't worthwhile. > > It should be consistent at least. If virtio is not translated, we have > to exclude such devices via ACPI tables from the scope of our IOMMUs. I didn't know this is possible. How does one do this? > > We can certainly add that as an option, with a feature bit. > > > > If you feel otherwise, you can comment on the latest spec draft. > > Does the spec at least state that "virtio devices are not subject to any > guest configured IOMMU translation"? Is is this left undefined? > > Jan > > I don't think we have anything like this. -- MST