From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:56620) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RWDid-00025Q-LQ for qemu-devel@nongnu.org; Thu, 01 Dec 2011 15:59:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RWDia-0003JE-Na for qemu-devel@nongnu.org; Thu, 01 Dec 2011 15:58:59 -0500 Received: from mail-gy0-f173.google.com ([209.85.160.173]:58347) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RWDia-0003J9-LA for qemu-devel@nongnu.org; Thu, 01 Dec 2011 15:58:56 -0500 Received: by ghbg19 with SMTP id g19so2928067ghb.4 for ; Thu, 01 Dec 2011 12:58:55 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <1322672293.19120.232.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> <1322672293.19120.232.camel@bling.home> Date: Thu, 1 Dec 2011 14:58:54 -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 >> The attributes are not intrinsic features of the domain. =A0User space w= ill >> need to set them. =A0But in thinking about it a bit more I think the att= ributes >> are more properties of the domain rather than a per map() operation >> characteristic. =A0I think a separate API might be appropriate. =A0Defin= e a >> new set_domain_attrs() op in the iommu_ops. =A0 =A0In user space, perhap= s >> =A0a new vfio group API-- VFIO_GROUP_SET_ATTRS, >> VFIO_GROUP_GET_ATTRS. > > In that case, you should definitely be following what Alexey is thinking > about with an iommu_setup IOMMU API callback. =A0I think it's shaping up > to do: > > x86: > =A0- Report any IOVA range restrictions imposed by hw implementation > POWER: > =A0- Request IOVA window size, report size and base > powerpc: > =A0- Set domain attributes, probably report range as well. One other mechanism we need as well is the ability to enable/disable a domain. For example-- suppose a device is assigned to a VM, the device is in use when the VM is abruptly terminated. The VM terminate would shut off DMA at the IOMMU, but now the device is in an indeterminate state. Some devices have no simple reset bit and getting the device back into a sane state could be complicated-- something the hypervisor doesn't want to do. So now KVM restarts the VM, vfio init happens for the device and the IOMMU for that device is re-configured, etc, but we really can't re-enable DMA until the guest OS tells us (via an hcall) that it is ready. The guest needs to get the assigned device in a sane state before DMA is enabled. Does this warrant a new domain enable/disable API, or should we make this part of the setup API we are discussing here? Stuart