Guillaume Thouvenin wrote: > Hello, > > I have a question about how guest page table and shadow page table > work together and more precisely, about how host is involved when guest > access a page that it's already in the page table. > > The guest maintains its page table to translate guest virtual address > to guest physical address. It uses the MMU and cr3 register for the > translation. When there is a page fault, the host gets involved and it > catches the guest physical address (by walking through the guest page > table?) and fills its shadow page table.
When a page fault occurs, a vmexit is generated. The vmexit is delivered before delivery to the interrupt handler but after CR2 is populated with the faulting address. We can then obtain the faulting virtual address from CR2 in the host and walk the guest's page table to determine what guest physical address should be mapped at that guest virtual address (if any at all). We then use that information to add an entry to the shadow page table. The guest runs with the shadow page table installed, the hardware never actually sees the guest page table. This is because the hardware has no knowledge of MMU virtualization (this is all assuming pre-EPT/NPT hardware). > Thus the host can make the > translation from guest physical address to physical address. And we use a combination of things to make that determination. First, there is a set of slots that cover ranges of physical addresses. Slots are necessary on x86 as there may be very large holes in physical memory. It also makes certain optimization easier. Each slot contains a base virtual address. This is a QEMU userspace address that is where we malloc()'d memory for that particular slot. Normally, this corresponds to phys_ram_base within QEMU. We add the guest physical address to the virtual address base in the slot (minus the slot starting address) to obtain a QEMU userspace address for the guest physical address. Once we have that, we can call get_user_pages() to pin the userspace memory into physical memory. We can then obtain a host physical address. That's what we use to populate the shadow page table. The flip side of this is that as long as we have a shadow page table mapping referencing a host physical address, we must keep the page pinned into memory. Once we drop the shadow page table entry (because the guest process has gone away or we decide to evict it from the cache) we can reduce the reference count via put_page(). This is where mmu notifiers come into play. If Linux really wants to reclaim memory on the host, there's no way ATM for it to do so with the memory we have pinned. mmu notifiers provide a mechanism to Linux to ask KVM to explicitly unpin a particular guest page. > Now, if > the guest reads the same page, the PTE will point to guest physical > address but there will not be any page fault so the host will not be > involved in the translation (not so sure). I don't see how the guest > virtual address will be translated to physical address? I miss > something but I don't see what. > I think what you're missing is that while the guest is running, it's CR3 does not point to it's own page table but rather to the shadow page table. We intercept CR3 reads to pretend to the guest that it's page table is, in fact, installed but it's really the shadow page table that's in the hardware register. Regards, Anthony Liguori > Thanks for your help, > Guillaume > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > kvm-devel mailing list > kvm-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kvm-devel > ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
