RE: [Xen-devel] [PATCH][HAP][2/2] fix CR4 initialization when hap is on

["Huang2, Wei" <Wei.Huang2@xxxxxxx>]

There are two CR4 related variables (vmcb->cr4 and cpu_shadow_cr4). I agree that cpu_shadow_cr4 should be zero at start-of-day for both cases. Current construct_vmcb() initializes cpu_shadow_cr4 with read_cr4() & ~(X86_CR4_PGE | X86_CR4_PSE | X86_CR4_PAE), which seems imperfect to me (although it works well so far).

 

On the other hand, initial values of vmcb->cr4 should differ between hap and shadow modes. Nested paging relies vmcb->cr4 (and other control registers) to determine guest paging mode. When hap is on, vmcb->cr4 should be initialized with 0 to reflect correct state of guest. Under shadow mode, the value of vmcb->cr4 is initialized with proper values (none-zero) to utilize shadow page table. That is why we need a different code path for hap.

 

-Wei

---

From: Keir Fraser [mailto:keir@xxxxxxxxxxxxx]
Sent: Tuesday, March 27, 2007 11:14 AM
To: Huang2, Wei; xen-devel@xxxxxxxxxxxxxxxxxxx; Tim Deegan
Subject: Re: [Xen-devel] [PATCH][HAP][2/2] fix CR4 initialization when hap is on

This seems an odd change. The earlier setting of CR4 in 
construct_vmcb() already masks out paging-related bits. So why would the 
remaining bits’ behaviour differ between hap and shadow paging modes? It would 
seem to me that either CR4 should be zero at start-of-day in all cases (seems 
quite likely to me as that’s what happens in a native system), or the existing 
code should be okay in both cases.

 -- Keir

On 22/3/07 16:13, 
"Huang2, Wei" <Wei.Huang2@xxxxxxx> wrote:

> This patch 
>   initializes VMCB CR4 and shadow CR4 with 0 when VMCB is being constructed 
>   under nested paging mode. It complies with recent reset_to_realmode change in 
>   hvmloader.
>
> Signed-off-by: Wei Huang (wei.huang2@xxxxxxx <mailto:wei.huang2@xxxxxxx> 
>   )
>
>  

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