Re: [PATCH 00/27] Add KVM support for Book3s_64 (PPC64) hosts v4

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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

[Index of Archives]     [KVM Development]     [KVM ARM]     [KVM ia64]     [Linux Virtualization]     [Linux USB Devel]     [Linux Video]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux