[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH] vfio: VFIO PCI driver for Qemu

From: Avi Kivity
Subject: Re: [Qemu-devel] [RFC PATCH] vfio: VFIO PCI driver for Qemu
Date: Thu, 26 Jul 2012 11:35:47 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1

On 07/25/2012 10:53 PM, Alex Williamson wrote:
> 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,? 

Read the documentation.

> 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,

It's not.  e1000 is a guest visible feature. vfio and kvm assignment do
exactly the same thing, as far as the guest is concerned, just using a
different driver.  This is more akin to -device virtio-net,vhost=on|off
(where we also have a default and a fallback, which wouldn't make sense
for model=e1000).

error compiling committee.c: too many arguments to function

reply via email to

[Prev in Thread] Current Thread [Next in Thread]