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

[Cole Robinson <crobinso@redhat.com>]

On 08/14/2012 11:04 AM, Jan Kiszka wrote:
> On 2012-08-14 16:53, Cole Robinson wrote:
>> On 08/13/2012 03:31 PM, Anthony Liguori wrote:
>>> Jan Kiszka <jan.kiszka@siemens.com> 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.
> 

My head isn't entirely in the sand here, I've watched the patches go by and
feel pretty confident that you and co. wouldn't drop qemu-kvm if there was
something missing that left qemu.git substantially lacking, at least not
without announcing it clearly. I know certain defaults will change and certain
cli options will go away but that just requires user education.

And qemu-kvm won't really 'die', the code isn't going to disappear. If we
switch to qemu.git and discover some vital piece is missing, we can
temporarily carry the relevant qemu-kvm bits and try to get the issue resolved
upstream. If upstream doesn't want to change, then we are back to user education.

- Cole