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.