Thanks for the response. I've looked through the code some more and
think I have figured it out now. I finally see that the root_hpa
variable gets switched before entering the guest in mmu_alloc_roots, to
correspond with the new cr3. Thanks again.
Perhaps you can help me with one more question. I was hoping to try out
a certain change for a research project. I would like to "privatize"
kvm_mmu_page's and their spe's for each guest thread running in certain
designated guest processes. The goal is to give each thread its own
shadow page table graphs that map the same guest logical addresses to
guest physical addresses (with some changes to be introduced later).
Are there any assumptions that KVM makes that will break if I do
something like this? I understand that I will have to add some code
throughout the mmu to make sure that these structures are synchronized
when a guest thread makes a change, but I'm wondering if there is
anything else. Does the reverse mapping data structure you have assume
that there is only one shadow page per guest page?
Thanks!
Marek
Avi Kivity wrote:
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.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
