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: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH 0/3] VFIO-based PCI device assignment for QEMU 1.2
Date: Tue, 14 Aug 2012 17:04:20 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

On 2012-08-14 16:53, Cole Robinson wrote:
> On 08/13/2012 03: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?
>>
>> 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?
>>
> 
> Speaking as a Fedora maintainer, compatibility with old kernels isn't that
> important to us, provided the functionality of the new way is comparable to
> the old way.
> 
> As far as switching over to qemu.git, I assume there will eventually be a day
> when the fork would 'end' and qemu-kvm would stop getting its own releases,
> which is when we'd switch. Maybe that assumption is wrong or over simplifying
> the trade offs, but if merge work is ongoing I don't see a very compelling
> reason to switch.

If you sit and wait, you may find out on that specific day that someone
forget to port over feature X and Y, and now QEMU does not fit your
needs and qemu-kvm is dead.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux



reply via email to

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