Re: [RFC PATCH 0/5] QEMU VFIO device assignment

Avi Kivity
2010-07-11T18:43:43Z

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.