On 03/11/2010 06:14 PM, Marek Olszewski wrote:
It doesn't, and there are often multiple shadow pages per guest page,
distinguished by their sp-role field.
Oh, great! Does this mean that there is already a mechanism for
synchronizing all shadow pages shadowing the same guest when such a
guest
It doesn't, and there are often multiple shadow pages per guest page,
distinguished by their sp-role field.
Oh, great! Does this mean that there is already a mechanism for
synchronizing all shadow pages shadowing the same guest when such a
guest page changes?
Marek
--
To unsubscribe from
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
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
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
