Re: Status of SMP?

Avi Kivity
2007-03-16T06:46:07Z

Nakajima, Jun wrote:
> I assumed that the current virutal MMU code was not designed to support
> SMP (when you said "there's no need to worry about the mmu").

What I meant was that there is no need debug both the core smp support
and the mmu smp support at the same time. Certainly the mmu was written
with smp support in mind.

> The other thing is how do you detect when the guest page tables become
> just data (this is not an SMP issue, though)? If you don't unshadow such
> pages, we'll tend to get (frequent) unnecessary #PF.
>

There are a few heuristics in place for zapping shadow page tables:

- user mode writes (fix_write_pf)
- unaligned writes (kvm_mmu_pre_write)
- lots of writes to the same page (kvm_mmu_pre_write)

We could probably also add a heuristic that checks that the contents
look like a pte if PT_PRESENT is set. This is useful mostly on pae
where there are many reserved bits.

> These are mostly performance optimization issues, but SMP guests will
> use local and IO APICs (and other misc timers), and we'll see more
> frequent VM exits in such a guest. We may need to move them to the KVM
> side if we see performance issues.
>

We've actually done this, and found that performance was not affected.
The reason is that the kernel->user transition is very fast compared to
the guest->kernel transition. It is still worthwhile to do this if we
have to use the apic to inject interrupts from in-kernel paravirtualized
devices, where it makes little sense to go back to userspace in order to
inject the interrupt.

I'd also like to add a read-only memory type so that apic reads can
proceed natively rather than be emulated (the TODO has this now).

--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.