From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51202) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RVmIG-0007XL-Pj for qemu-devel@nongnu.org; Wed, 30 Nov 2011 10:42:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RVmIE-00074i-2j for qemu-devel@nongnu.org; Wed, 30 Nov 2011 10:41:56 -0500 Received: from mail-qw0-f52.google.com ([209.85.216.52]:56167) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RVmID-00074d-RS for qemu-devel@nongnu.org; Wed, 30 Nov 2011 10:41:54 -0500 Received: by qady1 with SMTP id y1so699211qad.4 for ; Wed, 30 Nov 2011 07:41:53 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <1322610273.19120.209.camel@bling.home> References: <20111103195452.21259.93021.stgit@bling.home> <4ED43AD9.5090509@au1.ibm.com> <4ED43CFE.8040009@au1.ibm.com> <1322538856.19120.126.camel@bling.home> <1322594768.19120.194.camel@bling.home> <1322610273.19120.209.camel@bling.home> Date: Wed, 30 Nov 2011 09:41:49 -0600 Message-ID: From: Stuart Yoder Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC PATCH] vfio: VFIO Driver core framework List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson Cc: chrisw@sous-sol.org, Alexey Kardashevskiy , kvm@vger.kernel.org, pmac@au1.ibm.com, joerg.roedel@amd.com, konrad.wilk@oracle.com, qemu-devel@nongnu.org, agraf@suse.de, aafabbri@cisco.com, B08248@freescale.com, iommu@lists.linux-foundation.org, avi@redhat.com, linux-pci@vger.kernel.org, dwg@au1.ibm.com, B07421@freescale.com, benve@cisco.com On Tue, Nov 29, 2011 at 5:44 PM, Alex Williamson wrote: > On Tue, 2011-11-29 at 17:20 -0600, Stuart Yoder wrote: >> > >> > BTW, github now has updated trees: >> > >> > git://github.com/awilliam/linux-vfio.git vfio-next-20111129 >> > git://github.com/awilliam/qemu-vfio.git vfio-ng >> >> Hi Alex, >> >> Have been looking at vfio a bit. =A0 A few observations and things >> we'll need to figure out as it relates to the Freescale iommu. >> >> __vfio_dma_map() assumes that mappings are broken into >> 4KB pages. =A0 That will not be true for us. =A0 We normally will be map= ping >> much larger physically contiguous chunks for our guests. =A0Guests will >> get hugetlbfs backed memory with very large pages (e.g. 16MB, >> 64MB) or very large chunks allocated by some proprietary >> means. > > Hi Stuart, > > I think practically everyone has commented on the 4k mappings ;) =A0There > are a few problems around this. =A0The first is that iommu drivers don't > necessarily support sub-region unmapping, so if we map 1GB and later > want to unmap 4k, we can't do it atomically. =A04k gives us the most > flexibility for supporting fine granularities. =A0Another problem is that > we're using get_user_pages to pin memory. =A0It's been suggested that we > should use mlock for this, but I can't find anything that prevents a > user from later munlock'ing the memory and then getting access to memory > they shouldn't have. =A0Those kind of limit us, but I don't see it being > an API problem for VFIO, just implementation. Ok. >> Also, mappings will have additional Freescale-specific attributes >> that need to get passed through to dma_map somehow. =A0 For >> example, the iommu can stash directly into a CPU's cache >> and we have iommu mapping properties like the cache stash >> target id and an operation mapping attribute. >> >> How do you envision handling proprietary attributes >> in struct vfio_dma_map? > > Let me turn the question around, how do you plan to support proprietary > attributes in the IOMMU API? =A0Is the user level the appropriate place t= o > specify them, or are they an intrinsic feature of the domain? =A0We've > designed struct vfio_dma_map for extension, so depending on how many > bits you need, we can make a conduit using the flags directly or setting > a new flag to indicate presence of an arch specific attributes field. The attributes are not intrinsic features of the domain. User space will need to set them. But in thinking about it a bit more I think the attribut= es are more properties of the domain rather than a per map() operation characteristic. I think a separate API might be appropriate. Define a new set_domain_attrs() op in the iommu_ops. In user space, perhaps a new vfio group API-- VFIO_GROUP_SET_ATTRS, VFIO_GROUP_GET_ATTRS. Stuart