How to get guest PTEs info of a HVM with EPT

How to get guest PTEs info of a HVM with EPT

[KennyChen]

Hi, all:

When EPT is enabled for a HVM guest, is that possible for hypervisor to get the
PTE information of guest page table? e.g, R/W, Supervisor flags?
We wonder to explore the information from guest page table to perform some other
tasks.

Thanks,
Kenny

Re: How to get guest PTEs info of a HVM with EPT

[Tim Deegan]

At 02:50 +0000 on 20 Jan (1295491817), KennyChen wrote:
> When EPT is enabled for a HVM guest, is that possible for hypervisor
> to get the PTE information of guest page table? e.g, R/W, Supervisor
> flags? 

Yes, of course - you know the guest's CR3 value and you can map all its
memory so you can read its pagetables.  Look at hap_gva_to_gfn() and 
how it calls guest_walk_tables().  You can even do it from userspace 
in dom0 - see xc_translate_foreign_address().

What you can't do easily without shadow paging is _control_ the
pagetable values.

Cheers,

Tim.

-- 
Tim Deegan <Tim.Deegan@citrix.com>
Principal Software Engineer, Xen Platform Team
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

Re: How to get guest PTEs info of a HVM with EPT

[KennyChen]

Tim Deegan <Tim.Deegan <at> citrix.com> writes:

> 
> At 02:50 +0000 on 20 Jan (1295491817), KennyChen wrote:
> > When EPT is enabled for a HVM guest, is that possible for hypervisor
> > to get the PTE information of guest page table? e.g, R/W, Supervisor
> > flags? 
> 
> Yes, of course - you know the guest's CR3 value and you can map all its
> memory so you can read its pagetables.  Look at hap_gva_to_gfn() and 
> how it calls guest_walk_tables().  You can even do it from userspace 
> in dom0 - see xc_translate_foreign_address().
> 
> What you can't do easily without shadow paging is _control_ the
> pagetable values.
> 
> Cheers,
> 
> Tim.
> 

Thanks for the hint, Tim, but I still got some questions.

When I put debug dump in the guest_walk_tables() to observe the l4e entry
(64-bit guest with 4GB ram, Centos 5.5), is it normal to get a l4e "10e21a067".
It seems the gfn 0x10e21a has exceeded the maximum physical memory of the guest
(0x100000 for 4GB). Is this a bug of the guest or some tricks in the l4e?

The other weird thing is gfn_to_mfn_unshare() called inside hap_gva_to_gfn().
Why is it necessary to unshare the page when we traverse the page table? we are
just reading it right?

Kenny

Re: Re: How to get guest PTEs info of a HVM with EPT

[Tim Deegan]

At 23:30 +0000 on 08 Feb (1297207857), KennyChen wrote:
> Thanks for the hint, Tim, but I still got some questions.
> 
> When I put debug dump in the guest_walk_tables() to observe the l4e entry
> (64-bit guest with 4GB ram, Centos 5.5), is it normal to get a l4e "10e21a067".

Yes, quite normal.

> It seems the gfn 0x10e21a has exceeded the maximum physical memory of the guest
> (0x100000 for 4GB). Is this a bug of the guest or some tricks in the l4e?

Neither.  Some addresses below 4GB don't contain RAM, so the highest RAM
address is larger than the amount of RAM.

> The other weird thing is gfn_to_mfn_unshare() called inside
> hap_gva_to_gfn().  Why is it necessary to unshare the page when we
> traverse the page table? we are just reading it right?

You're right, it's probably not necessary, though pagetable pages are
unlikely to be shared between domains.  I'm not inclined to change it
just now since we're supposed to be freezing for the 4.1 release.

Tim.

-- 
Tim Deegan <Tim.Deegan@citrix.com>
Principal Software Engineer, Xen Platform Team
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

Question about page table used by hypervisor

[KennyChen]

Hi, Tim:

One more doubt here.
In the Linux concept, each process all share a common part of kernel page
tables, e.g., 3-4GB address mapping are the same among all processes. Thus when
switching to kernel, there is no need to change hardware CR3.

But when going to PV guest, is that the same way?
I thought Xen prepares the page tables for PV guest in such a way that some
portion of address mapping is reserved particularly for hypervisor, which can be
used for translation inside hypervisor.

For PV, it might be ok because the page table is directly translated to machine
physical address. So when switching to hypervisor, this page table (same cr3)
can still be used for address translation.

But how about HVM guest (assume EPT is enabled)?
When vmexit happens, does the hardware CR3 switches to some other value, which
points to a special page table for Xen's use? If no switching happens, then the
hardware MMU would walk through guest page table for translation which is weird
to me.

If such special page table exists, could you point it out?

Thanks,
Kenny

Re: Question about page table used by hypervisor

[Tim Deegan]

Hi, 

At 02:42 +0100 on 30 Mar (1301452953), KennyChen wrote:
> Hi, Tim:
> 
> One more doubt here.
> In the Linux concept, each process all share a common part of kernel page
> tables, e.g., 3-4GB address mapping are the same among all processes. Thus when
> switching to kernel, there is no need to change hardware CR3.
> 
> But when going to PV guest, is that the same way?
> I thought Xen prepares the page tables for PV guest in such a way that
> some portion of address mapping is reserved particularly for
> hypervisor, which can be used for translation inside hypervisor.

Yes, PV guests share an address space with the hypervisor, as described
in the original "Xen and the art of virtualization" paper. 

> For PV, it might be ok because the page table is directly translated to machine
> physical address. So when switching to hypervisor, this page table (same cr3)
> can still be used for address translation.
> 
> But how about HVM guest (assume EPT is enabled)?
> When vmexit happens, does the hardware CR3 switches to some other value

Yes; it's called the "host cr3" in the APMs and PRMs. 

, which
> points to a special page table for Xen's use? If no switching happens, then the
> hardware MMU would walk through guest page table for translation which is weird
> to me.
> 
> If such special page table exists, could you point it out?

It's called the "monitor table" in the Xen code. 

Cheers,

Tim.

> Thanks,
> Kenny
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

-- 
Tim Deegan <Tim.Deegan@citrix.com>
Principal Software Engineer, Xen Platform Team
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)