On Fri, 2010-03-12 at 16:25 +0100, Jan Kiszka wrote:
> Hi,
> 
> this is still in the state "study", but it is working fairly nicely so far:
> 
> These two patches harden latest KVM for use over I-pipe kernels and make
> Xenomai aware of the lazy host state restoring that KVM uses for
> performance reasons. The latter basically means calling the sched-out
> notifier that KVM registers with the kernel when switching from a Linux
> task to some shadow. This is safe in all recent versions of KVM and
> still gives nice KVM performance (that of KVM before 2.6.32) without
> significant impact on the RT latency (Note: if you have an old VT-x CPU,
> guest-issued wbinvd will ruin RT as it is not intercepted by the hardware!).
> 
> To test it, you need to apply the kernel patch on top of current kvm.git
> master [1], obtain kvm-kmod.git [2], run configure on it (assuming your
> host kernel is a Xenomai one, otherwise use --kerneldir) and then "make
> sync-kmod LINUX=/path/to/kvm.git". After a final make && make install,
> you will have recent kvm modules that are I-pipe aware. The Xenomai
> patch simply appies to the 2.5 tree. This has been tested with
> ipipe-2.6.32-x86-2.6-01 + [3] and Xenomai-2.5 git.
> 
> Feedback welcome, specifically if you think it's worth integrating both
> patches into upstream. The kernel bits would make sense over some
> 2.6.33-x86, but additional work will be required to account for the
> user-return notifiers introduced with that release (kvm-kmod currently
> wraps them away for older kernels).

No concern on the final goal, running a Xenomai-enabled kernel
rock-solid over KVM is a must.

The KVM code ironing from the 1st patch looks fine to me, no big deal to
maintain AFAICS. I would be only concerned by the 2nd patch,
specifically how the KVM callout is invoked from the Xenomai context
switching code:

- depending on CONFIG_PREEMPT_NOTIFIERS is much broader than required; I
guess that CONFIG_KVM would be enough.

- calling the KVM callout directly instead of going through the notifier
list would be more acceptable, so that we don't assume anything from the
non-KVM hooks (whether they exist or not), albeit we may assume that we
have complete information about which KVM callout has to be run for a
particular kernel version.

But again, rock-solid KVM+Xenomai is a much desirable feature.

> 
> Jan
> 
> [1]git://git.kernel.org/pub/scm/virt/kvm/kvm.git
> [2]git://git.kernel.org/pub/scm/virt/kvm/kvm-kmod.git
> [3]http://git.kiszka.org/?p=ipipe-2.6.git;a=commitdiff;h=0bddff1716aba6dd5ca11627ee377a5a25fa3dae
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@gna.org
> https://mail.gna.org/listinfo/xenomai-core


-- 
Philippe.



_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to