[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] Question on p2m table

  • To: MaoXiaoyun <tinnycloud@xxxxxxxxxxx>, xen devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
  • Date: Tue, 31 May 2011 09:20:40 +0800
  • Accept-language: en-US
  • Acceptlanguage: en-US
  • Cc:
  • Delivery-date: Tue, 31 May 2011 07:09:49 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acwe89j72cbVUsDBQtWToE75FkZblAAPIjRw
  • Thread-topic: [Xen-devel] Question on p2m table

>From: MaoXiaoyun
>Sent: Tuesday, May 31, 2011 12:16 AM

could you use plain text format when posting mail next time, which is easier 
for reply? :-)

>  Question might be simple but really confused me a long time.
>  In my assumption, during VM running, the CPU sees the guest code instruction,
>so when it want to asscess memory, it sees the guest virtual adress(GVA), so 
>it need to 
>first translate to guest physical adress(GPA), and then host physical 
>adress(HPA), and finally 
>access the real memory address.
>Since GPA are always needs to translated to HPA, and p2m table only accessable 
>in Xen for 
>HVM guest, does this mean every memory access will need VMExit to Xen?

W/o EPT, CPU only has VA->PA knowledge, and thus here comes the concept of
shadow page table. Xen marks guest page table as read-only, and then tracks
every update to guest page table (which causes exits), and then construct shadow
page table accordingly which setups GVA->HPA mapping. It's the shadow page
table which is actually walked by the CPU when the guest is running.

W/ EPT, CPU has the concept of GVA->GPA->HPA. So literally the P2M table is
maintained as EPT table, and then CPU will first walk guest page table to 
acquire GPA and then walk EPT table to get final HPA.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.