[Qemu-devel] Re: POLL: Why do you use kqemu?

[Avi Kivity <avi@redhat.com>]

Jan Kiszka wrote:
> Avi Kivity wrote:
>   
>> Jan Kiszka wrote:
>>     
>>>> Maybe the backwards compatibility features should be ported to QEMU?
>>>> For example, is there a workaround for
>>>> #error Missing KVM capability KVM_CAP_DESTROY_MEMORY_REGION_WORKS
>>>> ?
>>>>     
>>>>         
>>> Given that we have always-up-to-date kvm-kmod packages with support down
>>> to reasonable kernel versions, I would prefer to keep upstream clean
>>> from old workarounds. They should only be needed for issues found very
>>> recently (KVM_CAP_JOIN_MEMORY_REGIONS_WORKS) or that might be found in
>>> the future.
>>>   
>>>       
>> Requiring the latest up-to-date modules is pushing the problem to the
>> users.  Sometimes there is no choice, but when there is, the
>> implementation that cares about its uses prefer unclean code and
>> functionality over perfection and brokenness.
>>     
>
> Let's make it more concrete:
>
> By the time upstream is as well tested, feature-rich and with comparable
> performance as qemu-kvm, its current baseline requirement (2.6.29 due to
> KVM_CAP_DESTROY_MEMORY_REGION_WORKS) will no longer be a problem to most
> normal users. Until then they are better off with qemu-kvm anyway.
>
> So all I wanted to express is that I see no point in merging workarounds
> upstream that hardly anyone will need but that restrict non-kvm code in
> upstream. Basically I have the current line along
> KVM_CAP_DESTROY_MEMORY_REGION_WORKS / clean memory slot management in
> mind. Anything older should be skipped when merging upstream. And unless
> something more problematic comes along (rather unlikely), 2.6.29 or
> compatible kvm-kmod is a reasonable minimum requirement for the long term.
>   

If you put it that way, I agree.  It's reasonable for qemu.git to target 
2.6.29.latest, unless it starts gaining features very rapidly.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.