On 30.09.2009, at 11:24, Avi Kivity wrote:
On 09/30/2009 11:11 AM, Alexander Graf wrote:
The plan is to get qemu ppc64 guest support in a shape where it
can actually use the KVM support. As it is it's rather useless.
When we have that, a PV interface would be needed to get things
fast and then the next thing on my list is the MMU notifiers.
Um. How slow is it today? What paths are problematic? mmu,
context switch?
Instruction emulation.
X86 with virtualization extensions doesn't trap often, as most of
the state can be safely handled within the guest mode.
Now with PPC we're basically running in "ring 3" (called "problem
state" in ppc speech) which traps all the time because guests
change the IF or access some SPRs that we don't really need to trap
on, but only need to sync state with on #VMEXIT.
So the PV idea here is to have a shared page between host and guest
that contains guest specific SPRs and other state (an MSR shadow
for example). That way the guest can patch itself to use that
shared page and KVM always knows about the most current state on
#VMEXIT. At the same time we're reducing exits by a _lot_.
But writing those registers often has side effects. For example,
enabling interrupts should also inject an interrupt when one is
pending. On x86 we have the same problem with the TPR on Windows
XP, so we copy it to the guest on entry (along with the pending
interrupt state) and back to the host on exit. The guest uses an
atomic operation to change the TPR and read pending interrupt
information, and if an interrupt becomes unmasked, it calls a
hypercall to trigger it.
Presumably you'll be doing something similar?
Yes, very similar to the TPR hack. Just on a broader scale :-).
As far as MSR_IF = 1 goes, you're right. It does make sense to trap it
in certain circumstances. Setting it to 0 doesn't need a trap though.
Also since we're PV'ed we could write an atomic bit in the shared page
that says "hey guest - I have an interrupt waiting for you". When that
is set MSR_IF = 1 returns to the host. Something like that.
In any case, I recommend keeping fine-grained control over those
bits so they can be enabled/disabled/expanded as needed.
Yeah, sounds like a good idea. We'll see how this goes. As long as
there are only very few users we can change the interface as much as
we like since we don't break anyone :-). And the PPC user base is
smaller than the x86 one in general.
Alex
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
