Alexander Graf wrote:
Hmm yes, this is a problem. So this optimization will not work. We need
other ways to optimize :)
Well it would work for the KVM-in-KVM case, where we know that VMRUN
is always triggered with IF=1 and V_INTR=1. The only case that hack
fails is when we have IF=0 and V_INTR=1. Everything else should work
just fine. And in this case we would simply issue some VMEXITs 0x60,
so no big deal IMHO. It should be worth the tradeoff of making most
VMMs a lot faster.
There should be a compile-option to enable the "correct" behavior
though. If we join that with the VMLOAD and VMSAVE hack there would be
only the VMRUN and DR exits left. That sounds like a really good
improvement where I wouldn't mind to break some specs :-).
Maybe a hypercall, so it can be enabled on a guest-by-guest basis.
I must say that if we do guest-specific hacking this way, a paravirt
approach doesn't look so bad.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
