Re: Shadow page table questions

[Avi Kivity <avi@redhat.com>]

On 03/10/2010 06:57 AM, Marek Olszewski wrote:
> Hello,
>
> I was wondering if someone could point me to some documentation that 
> explains the basic non-nested-paging shadow page table 
> algorithm/strategy used by KVM.  I understand that KVM caches shadow 
> page tables across context switches and that there is a reverse 
> mapping and page protection to help zap shadow page tables when the 
> guest page tables change.  However, I'm not entirely sure how the 
> actual caching is done.  At first I assumed that KVM would change the 
> host CR3 on every guest context switch such that it would point to a 
> cached shadow page table for the currently running guest user thread, 
> however, as far as I can tell, the host CR3 does not change so I'm a 
> little lost.  If indeed it doesn't change the CR3, how does KVM solve 
> the problem that arises when two processes in the guest OS share the 
> same guest logical addresses?

The host cr3 does change, though not by using the 'mov cr3' instruction 
(that would cause the host to immediately switch to the guest address 
space, which would be bad).

See the calls to kvm_x86_ops->set_cr3().

>
> I'm also interested in figuring out what KVM does when running with 
> multiple virtual CPUs.  Looking at the code, I can see that each VCPU 
> has its own root pointer to a shadow page table graph, but I have yet 
> to figure out if this graph has node's shared between VCPUs, or 
> whether they are all private.

Everything is shared.  If the guest is running with identical cr3s, kvm 
will load identical cr3s in guest mode.

An exception is when we use 32-bit pae mode.  In that case, the guest 
cr3s will be different (but guest PDPTRs will be identical).  Instead of 
dealing with the pae cr3, we deal with the four PDPTRs.

-- 
error compiling committee.c: too many arguments to function