From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:49323)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <alex.williamson@redhat.com>) id 1Su7ea-0008GZ-Tr
	for qemu-devel@nongnu.org; Wed, 25 Jul 2012 15:53:53 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <alex.williamson@redhat.com>) id 1Su7ea-0003xh-00
	for qemu-devel@nongnu.org; Wed, 25 Jul 2012 15:53:52 -0400
Received: from mx1.redhat.com ([209.132.183.28]:17574)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <alex.williamson@redhat.com>) id 1Su7eZ-0003xc-Ns
	for qemu-devel@nongnu.org; Wed, 25 Jul 2012 15:53:51 -0400
Message-ID: <1343246026.2229.374.camel@bling.home>
From: Alex Williamson <alex.williamson@redhat.com>
Date: Wed, 25 Jul 2012 13:53:46 -0600
In-Reply-To: <50104973.3090302@redhat.com>
References: <20120725165948.17260.82862.stgit@bling.home>
	<50104973.3090302@redhat.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [RFC PATCH] vfio: VFIO PCI driver for Qemu
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Avi Kivity <avi@redhat.com>
Cc: aik@ozlabs.ru, qemu-devel@nongnu.org, kvm@vger.kernel.org

On Wed, 2012-07-25 at 22:30 +0300, Avi Kivity wrote:
> On 07/25/2012 08:03 PM, Alex Williamson wrote:
> > This adds PCI based device assignment to Qemu using the Linux VFIO
> > userspace driver interface.  After setting up VFIO device access,
> > devices can be added to Qemu guests using the vfio-pci device
> > option:
> >
> >  -device vfio-pci,host=1:10.1,id=net0
> >
> >
> 
> Let's use the same syntax as for kvm device assignment.  Then we can
> fall back on kvm when vfio is not available.  We can also have an
> optional parameter kernel-driver to explicitly select vfio or kvm.

This seems confusing to me, pci-assign already has options like
prefer_msi, share_intx, and configfd that vfio doesn't.  I'm sure vfio
will eventually get options that pci-assign won't have.  How is a user
supposed to figure out what options are actually available from -device
pci-assign,?  Isn't this the same as asking to drop all model specific
devices and just use -device net,model=e1000... hey, we've been there
before ;)  Thanks,

Alex