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

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@amd.com <mailto:wei.huang2@amd.com>
)
 
 



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

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@amd.com> 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@amd.com
<mailto:wei.huang2@amd.com> )
>  
>  



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

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@xensource.com] 
Sent: Tuesday, March 27, 2007 11:14 AM
To: Huang2, Wei; xen-devel@lists.xensource.com; 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@amd.com> 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@amd.com
<mailto:wei.huang2@amd.com> )
	
	 
	





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