From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:45563) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RWUIO-00059n-2l for qemu-devel@nongnu.org; Fri, 02 Dec 2011 09:41:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RWUIH-0001qk-NQ for qemu-devel@nongnu.org; Fri, 02 Dec 2011 09:41:00 -0500 Received: from mail-qw0-f45.google.com ([209.85.216.45]:40016) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RWUIH-0001pf-Hk for qemu-devel@nongnu.org; Fri, 02 Dec 2011 09:40:53 -0500 Received: by qadz30 with SMTP id z30so518039qad.4 for ; Fri, 02 Dec 2011 06:40:53 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <1322774717.26545.118.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> <1322774717.26545.118.camel@bling.home> Date: Fri, 2 Dec 2011 08:40:52 -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 Thu, Dec 1, 2011 at 3:25 PM, Alex Williamson wrote: > On Thu, 2011-12-01 at 14:58 -0600, Stuart Yoder wrote: >> 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. =A0The >> VM terminate would shut off DMA at the IOMMU, but now >> the device is in an indeterminate state. =A0 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 =A0the 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. =A0 The guest needs to get the >> assigned device in a sane state before DMA is enabled. > > Giant red flag. =A0We need to paravirtualize the guest? =A0Not on x86. It's the reality we have to deal with, but doing this would obviously only apply to platforms that need it. > Some > devices are better for assignment than others. =A0PCI devices are moving > towards supporting standard reset mechanisms. > >> Does this warrant a new domain enable/disable API, or should >> we make this part of the setup API we are discussing >> here? > > What's wrong with simply not adding any DMA mapping entries until you > think your guest is ready? =A0Isn't that effectively the same thing? > Unmap ~=3D disable. =A0If the IOMMU API had a mechanism to toggle the iom= mu > domain on and off, I wouldn't be opposed to adding an ioctl to do it, > but it really seems like just a shortcut vs map/unmap. =A0Thanks, Yes, we could do something like that I guess. Stuart