qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 0/3] VFIO-based PCI device assignment for QEMU 1


From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH 0/3] VFIO-based PCI device assignment for QEMU 1.2
Date: Tue, 14 Aug 2012 17:42:44 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0

On 08/13/2012 10:31 PM, Anthony Liguori wrote:
> Jan Kiszka <address@hidden> writes:
> 
>> On 2012-08-13 15:58, Avi Kivity wrote:
>>> On 08/13/2012 04:27 PM, Anthony Liguori wrote:
>>> 
>>>> Thanks for pushing this forward!  Hopefully this will finally kill off
>>>> qemu-kvm.git for good.
>>> 
>>> No, it won't.  vfio requires a 3.6 kernel, which we cannot assume anyone
>>> has.  We'll need the original device assignment code side-by-side.
>>
>> ...which is on my to-do list for 1.3.
> 
> Is there a deprecation plan for the old device assignment code?

Not yet.  I would say 2-3 years from the release that has full support
(3.7, since we need more support for INTx in kvm).

This feature is user visible, all the way up to scripts and management
tools.  It's not a plug-in replacement (though I tried).  Even with a
new kernel, we can't just drop it and point users to vfio.

> 
> I'm not really against the idea of requiring a new kernel for new
> features.
> 
> From a Fedora/OpenSUSE point of view, would supporting old kernels be a
> requirement to stop shipping qemu-kvm.git over qemu.git?
> 
> Since distros ship new kernels and new userspaces, I don't think distros
> would care so I'm not sure who we're trying to support old kernels for.

People do all sort of wierd things.  qemu and the kernel are not just
for fedora/opensuse consumers who have someone to take care of the
entire stack for them, when we deprecate an ABI we need to give them
plenty of time to adjust.  I think this is even more relevant for device
assignment which is sometimes used with unusual use cases.

-- 
error compiling committee.c: too many arguments to function



reply via email to

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