Re: [Xen-devel] Some tables used when shadowable

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

Not really my area of expertise but lets see if I can help without
misleading too gratuitously (iow take what I say with a grain of salt).

On Fri, 2011-05-27 at 18:15 +0100, confucius wrote:
> Hi, I find there are several kinds of tables are used when shadowsable. They
> are defined as follow:
>   xen/include/asm-86/domain.h
>  struct arch_vcpu
> {
>     .........................
>     pagetable_t guest_table;            /* (MFN) guest notion of cr3 */
>     pagetable_t shadow_table[4];        /* (MFN) shadow(s) of guest */
>     pagetable_t monitor_table;          /* (MFN) hypervisor PT (for HVM) */
>     unsigned long cr3;                  /* (MA) value to install in HW CR3
> */
>     ...............
> 
> }
> I am confused by these tables. My understanding as follow:
> 
> 1.    guest_table
> Does guest_table point to MFN of page tables which constructed used by guest
> kernel?

I believe so, and the comment concurs.

> where it convert from? guest_cr[3] or hw_cr[3]?
> What is it used?

These are questions which "grep" or you favorite ctags style application
can answer for you.

>  Does it used for VMM when emulating? such as: when guest
> generate page fault, it will trigger VM exit, 
> then VMM read GUEST_CR3 and convert GUEST_CR3 to MFN ïthen store the MFN in
> guest_table, now because the MFN is the guest physical
> address ,so VMM will convert it to the machine physical address via P2M
> table? right?

guest_table is not updated on a page fault, but when the guest tries to
write to its cr3, which causes a vmexit. I think hvm_set_cr3() is the
function which does this.

> 2. shadow_table
> hw_cr[3] and GUEST_CR3  both point to shadow_table, right?

If you are using shadow (and not HAP) then I expect that hw_cr[3] does
point to the shadow_table.

GUEST_CR3 is a field in the VMCS and I expect it contains the guest's
current idea of CR3, IOW the unshadowed CR3. This value is cached in
guest_cr[3] to avoid having to read it from the VMCS each time it is
needed.

Things are probably different when HAP rather than shadow is used.

> 3. monitor_table
> I am not sure the use of monitor_table.

It is the page table used in root (also called host) context, i.e. when
running the hypervisor itself. An HVM guest will not have mapping for
the hypervisor in its page tables and so the hypervisor needs to provide
something suitable to switch to on vmexit.

> Does it used for VMM access guest's address space?
> And I find HOST_CR3 point to monitor tableïwhy HOST_CR3 pointing it?

As described above, the host page table is the one the hypervisor runs
on.

> I think HOST_CR3 should point to VMM's page table when VM exit, then VMM can
> access address space itself. But why HOST_CR3 don't point to the page table
> itself?

I can't understand what you are saying/asking here. The VMM is the
hypervisor so HOST_CR3 _does_ point to the VMM's page table (called
monitor page table, monitor is basically another word for VMM).

Ian.

> 
> 
> Anyone help me? 
> 
> 
> 
> 
> --
> View this message in context: 
> http://xen.1045712.n5.nabble.com/Some-tables-used-when-shadowable-tp4432753p4432753.html
> Sent from the Xen - Dev mailing list archive at Nabble.com.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel