On 03/11/2010 02:06 AM, Marek Olszewski wrote:
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?
It doesn't, and there are often multiple shadow pages per guest page,
distinguished by their sp->role field.
--
error compiling committee.c: too many arguments to function
--
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
