From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [RFC PATCH] vfio: VFIO PCI driver for Qemu Date: Thu, 26 Jul 2012 19:47:11 +0300 Message-ID: <5011748F.2060005@redhat.com> References: <20120725165948.17260.82862.stgit@bling.home> <50104973.3090302@redhat.com> <1343246026.2229.374.camel@bling.home> <50110163.30209@redhat.com> <1343314583.3125.17.camel@ul30vt> <50116B1E.8030209@redhat.com> <1343320859.3125.47.camel@ul30vt> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org, aik@ozlabs.ru, benh@kernel.crashing.org To: Alex Williamson Return-path: Received: from mx1.redhat.com ([209.132.183.28]:4394 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752247Ab2GZSoH (ORCPT ); Thu, 26 Jul 2012 14:44:07 -0400 In-Reply-To: <1343320859.3125.47.camel@ul30vt> Sender: kvm-owner@vger.kernel.org List-ID: On 07/26/2012 07:40 PM, Alex Williamson wrote: > On Thu, 2012-07-26 at 19:06 +0300, Avi Kivity wrote: >> On 07/26/2012 05:56 PM, Alex Williamson wrote: >> > >> > Both KVM and VFIO do strive to make the device in the guest look as much >> > like it does on bare metal as possible, but we don't guarantee they're >> > identical and we don't guarantee to match each other. >> >> btw, this is somewhat problematic, conceivably this could break a guest >> (due to a guest bug). But with device assignment the compatibility >> requirements can be relaxed a bit since there is no live migration. > > Well, I would hope that things work better in vfio and we work to make > that the recommended method of device assignment. We can't hold one > back to make things identical. The only barrier I see to this is that > vfio focuses on security, enforcing things like ACS to make sure devices > can't do DMA to other devices outside of the group whereas KVM > assignment will let you attempt to do nearly anything and counts on > libvirt to only let the user attempt to do sane things. As you say, > there's no live migration with device assignment, so absolute identical > config space is not a requirement and the difference we do have should > be sufficiently subtle that the guest doesn't care boot-to-boot. We could add a strict backward compatibility option that forces the layout, but it isn't worth it. -- error compiling committee.c: too many arguments to function