From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=36993 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OY1VA-0006mt-CE for qemu-devel@nongnu.org; Sun, 11 Jul 2010 14:43:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OY1V9-0001Yy-Bo for qemu-devel@nongnu.org; Sun, 11 Jul 2010 14:43:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:26919) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OY1V9-0001Yk-4V for qemu-devel@nongnu.org; Sun, 11 Jul 2010 14:43:43 -0400 Message-ID: <4C3A10D9.6050609@redhat.com> Date: Sun, 11 Jul 2010 21:43:37 +0300 From: Avi Kivity MIME-Version: 1.0 References: <20100711180910.20121.93313.stgit@localhost6.localdomain6> <4C3A0AB1.3070302@redhat.com> <1278873437.20397.29.camel@x201> In-Reply-To: <1278873437.20397.29.camel@x201> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [RFC PATCH 0/5] QEMU VFIO device assignment List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson Cc: chrisw@redhat.com, mst@redhat.com, qemu-devel@nongnu.org, kvm@vger.kernel.org, pugs@cisco.com On 07/11/2010 09:37 PM, Alex Williamson wrote: > On Sun, 2010-07-11 at 21:17 +0300, Avi Kivity wrote: > >> On 07/11/2010 09:09 PM, Alex Williamson wrote: >> >>> The following series implements QEMU device assignment using the >>> proposed VFIO/UIOMMU kernel interfaces. See the last patch for >>> further vfio description. I've tested this on the v2 VFIO patch, >>> with a number of fixes hacked in along the way. I'll update when >>> Tom releases a new version of VFIO. Hopefully this will provide >>> some support for the usefulness of such an interfaces. Thanks, >>> >>> >>> >> What's the plan for supporting this alongside the existing kvm device >> assignment code? >> >> vfio will only exist in very new kernels, so we have to support the old >> code for a while to give people chance to adjust (say 12-18 months). >> > I was thinking that vfio device assignment might be the qemu acceptable > version of device assignment, and we can let kvm style device assignment > live out it's remaining time in the qemu-kvm tree, before it gets > deprecated. > Definitely, the effort to make qemu-kvm device assignment mergable probably isn't worth it. >> Ideally we'd have compatible command line syntax with qemu choosing vfio >> if available and falling back to kvm device assignment if not. >> > Ideally, yes, but I'm not sure how how feasible that is. For the > command line root user, the syntax is nearly same (s/pci-assign/vfio/), > but once we start trying to do libvirt based assignment, passing vfiofd > & uiommufd, it will need to know the difference anyway. Thanks, > I see. Well, we can probably live with two separate invocations, users who assign devices should be savvy or use libvirt. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.