Re: Status of SMP?

Huang2, Wei
2007-03-16T17:51:08Z

I am currently working on supporting nested paging for KVM. As of now, I
am able to boot 32-bit Linux guest (ttylinux) under AMD-V nested paging.
My plan is to support a full-fledged of Linux guests and Windows guests
in the next few weeks.

The current KVM MMU code was not designed with hardware assisted paging
(i.e. nested paging or extended paging) in mind. For instance, some
functions in kvm_main.c (i.e., write_cr functions) need to become become
function pointers. Guest page table walking also needs some re-work. It
will be nice to have both SMP and hardware assisted paging (NPT and EPT)
in place for the next phase of KVM MMU code. I will be happy to provide
help and work on these these areas. :P

Best,

-Wei
-----Original Message-----
From: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
[mailto:kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of Avi Kivity
Sent: Thursday, March 15, 2007 3:43 AM
To: Nakajima, Jun
Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [kvm-devel] Status of SMP?

Nakajima, Jun wrote:
> The key is the virtual MMU; getting bootstrap/IPI working is
> straightforward.

I'm glad to hear you say that.

> Without NPT or EPT, we need to have an SMP-capable shadow pagetable
> code. I think one of the most efficient ways is to re-use the code
> from Xen. The current one is the third generation of the shadow page
> table, and it works well.
>

I'm fairly certain a rip-it-the-old-and-plug-in-the-new approach would
be rejected. Linux development requires incremental patches.

I'm not familiar with the current Xen shadow code, but a cursory look
gave the following impressions:

- it is single threaded, so there's no reason to expect more scalability
out of it
- it is lighter weight, by not maintaining a full reverse mapping. on
the other hand, it is less generic (requires special handling for
linearized page tables)
- does order 2 allocations (which work in Linux, but get less reliable
as uptime increases)

I don't see a compelling reason to change here, but of course I may have
missed something and I'm also biased.

Getting the kvm mmu to do smp involves the following, as far as I can
tell:

- verifying that all the locking in place is correct
- make sure that spurious faults (due to races) are handled well
- install shadow ptes atomically instead of building them incrementally
- replace local tlb flushes by remote tlb flushes (for cpus that have
touched the domain, and later, for cpus that have touched the pagetable)

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

------------------------------------------------------------------------
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE
V
_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org