Re: Status of SMP?

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

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=DEVDEV