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

[Blue Swirl]

On 6/7/09, Jan Kiszka <address@hidden> wrote:
> Blue Swirl wrote:
>  > On 6/7/09, Jan Kiszka <address@hidden> wrote:
>  >> Blue Swirl wrote:
>  >>  > On 6/7/09, Jan Kiszka <address@hidden> 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.
>  >>  >
>  >>  > I pulled qemu-kvm and it looks to me that
>  >>  > KVM_CAP_DESTROY_MEMORY_REGION_WORKS and the derived functions
>  >>  > kvm_destroy_memory_region_works() and must_use_aliases_*() are only
>  >>  > used in very few places. Do I miss something, how can this be of any
>  >>  > restriction?
>  >>
>  >>
>  >> Check e.g the diff of hw/vga.c against upstream: All the magic dances
>  >>  there are required as qemu-kvm tracking cpu_register_physical_memory and
>  >>  kvm_log_start cannot cope with all the patterns normal qemu code comes
>  >>  up with. Upstream slot management now provides the same features
>  >>  (including migration) like qemu-kvm, it just does not deal with legacy,
>  >>  thus it does not have to patch qemu code (rather, we were able to remove
>  >>  some already merged hooks - vga_dirty_log_stop).
>  >
>  > Still not very restrictive, all this could be encapsulated with for
>  > example macro COMPAT_NO_DMRW which could be removed when we don't care
>  > anymore. Next?
>
>
> Really, it's not worth the maintenance pain: Every new device emulation
>  code that wants to be KVM-legacy-compatible would need to be written
>  like that. And unless you are familiar with the slot management
>  internals, the "correct" pattern will not be obvious.
>
>  I've just finished a patch for configure and for the runtime code to
>  tell the user what the maturer alternatives are. Will send it out in a
>  minute.

kvm-kmod seems to be available only for x86, not amd64. This is not
mentioned in README (in fact, there is no README), configure will
succeed and make will only generate funky errors. I only found this
mentioned in http://www.linux-kvm.org/page/Code after quite a bit of
head scratching.