On 30.09.2009, at 10:59, Avi Kivity wrote:
On 09/30/2009 10:47 AM, Alexander Graf wrote:
What's the plan here? While not a requirement for merging, that's
one of the kvm points of strength and I'd like to see it supported
across the board.
I'm having a deja vu :-).
Will probably get one on every repost.
Yippie :)
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_.
A short kvm_stat during boot of a ppc32 guest on ppc64 shows what I'm
talking about:
dec 3224 168
exits 18957500 1037240
ext_intr 75 5
halt_wakeup 6874 0
inst_emu 8570503 818597
ld 0 0
ld_slow 0 0
mmio 8719444 26249
pf_instruc 302572 35379
pf_storage 9215970 86750
queue_intr 354020 31482
sig 7244 188
sp_instruc 302541 35365
sp_storage 370002 45370
st 0 0
st_slow 0 0
sysc 57907 5342
As you can see the bulk of exits are from MMIO and emulation.
We certainly won't be able to get rid of all the emulation exits, but
quite a bunch of them aren't really that useful.
For MMIO we'll hopefully be able to use virtio.
Our experience with pv on x86 has been mostly negative. It's not
trivial to get security right, it ended up slower than non-pv, and
hardware obsoleted it fairly quickly.
Yes, and I really don't want to overdo it. PV for mfmsr/mtmsr and
mfspr/mtspr is really necessary. X86 simply has that in hardware.
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