Xen devel - Feb 2006 - [PATCH] HVM x86_32 PAE guest support on 64-bit Xen

The patch enables x86_32 PAE unmodified guests on 64-bit Xen when the
hvm feature is present. We tested only Linux at this point, and we''ll
improve the functionality as we test other guests.

The SVM needs the equivalent changes to the vmc.c to get this
functionality working, but this patch does not break the build.

Signed-off-by: Jun Nakajima <jun.nakajima@intel.com>
Signed-off-by: Xiaohui Xin <xiaohui.xin@intel.com>
Signed-off-by: Yunhong Jiang <yunhong.jiang@intel.com>

 b/xen/arch/x86/shadow_guest32pae.c |   18 ++
 xen/arch/x86/Makefile              |    2 
 xen/arch/x86/hvm/vmx/vmx.c         |  113 ++++++++++++++--
 xen/arch/x86/shadow.c              |  258
++++++++++++++++++++++++++++++-------
 xen/arch/x86/shadow_public.c       |   32 ++++
 xen/common/page_alloc.c            |    1 
 xen/include/asm-x86/hvm/hvm.h      |   10 +
 xen/include/asm-x86/hvm/vmx/vmx.h  |    8 +
 xen/include/asm-x86/shadow_64.h    |   78 ++++++++++-
 9 files changed, 457 insertions(+), 63 deletions(-)
 
Jun
---
Intel Open Source Technology Center 



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

On 18 Feb 2006, at 00:26, Nakajima, Jun wrote:
> The patch enables x86_32 PAE unmodified guests on 64-bit Xen when the
> hvm feature is present. We tested only Linux at this point, and
we''ll
> improve the functionality as we test other guests.
>
> The SVM needs the equivalent changes to the vmc.c to get this
> functionality working, but this patch does not break the build.
Now that you (wisely) no longer mess with MSR_EFER directly (leaving it 
to the the vmexit/vmentry protocol) can you get rid of the 
VMX_INDEX_MSR_EFER? There''s no point in saving/restoring it, since
it''s
value will not be different from normal while you run in Xen context.

  -- Keir


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

Keir Fraser wrote:
> On 18 Feb 2006, at 00:26, Nakajima, Jun wrote:
> 
>> The patch enables x86_32 PAE unmodified guests on 64-bit Xen when the
>> hvm feature is present. We tested only Linux at this point, and
we''ll
>> improve the functionality as we test other guests.
>> 
>> The SVM needs the equivalent changes to the vmc.c to get this
>> functionality working, but this patch does not break the build.
> 
> Now that you (wisely) no longer mess with MSR_EFER directly (leaving
> it to the the vmexit/vmentry protocol) can you get rid of the
> VMX_INDEX_MSR_EFER? There''s no point in saving/restoring it, since
> it''s value will not be different from normal while you run in Xen
> context. 
> 
>   -- Keir
> 
The VMX does not save/restore NXE (bit 11) and SCE (bit 0), and they are
always set in Xen (on machines where VMX is available). So it''s
possible
that those bits are still effectively on in the guest even after the
guest attempted to clear them (and we ignore such writes). I don''t
think
bad things can happen practically. We need to check carefully if we
might expose security holes there.

Jun
---
Intel Open Source Technology Center

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

On 19 Feb 2006, at 02:39, Nakajima, Jun wrote:
> The VMX does not save/restore NXE (bit 11) and SCE (bit 0), and they 
> are
> always set in Xen (on machines where VMX is available). So it''s 
> possible
> that those bits are still effectively on in the guest even after the
> guest attempted to clear them (and we ignore such writes). I don''t
> think
> bad things can happen practically. We need to check carefully if we
> might expose security holes there.
Isn''t SYSENTER effectively disabled if SYSENTER_CS == 0? Presumably the
guest wouldn''t touch that MSR unless it intends to set SCE.

And NXE should be okay so long as no OS has been borrowing the m.s.b. 
of PTEs in PAE36. Which seems unlikely.

  -- Keir


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

On 19 Feb 2006, at 07:58, Keir Fraser wrote:
>> The VMX does not save/restore NXE (bit 11) and SCE (bit 0), and they 
>> are
>> always set in Xen (on machines where VMX is available). So
it''s
>> possible
>> that those bits are still effectively on in the guest even after the
>> guest attempted to clear them (and we ignore such writes). I
don''t
>> think
>> bad things can happen practically. We need to check carefully if we
>> might expose security holes there.
>
> Isn''t SYSENTER effectively disabled if SYSENTER_CS == 0?
Presumably
> the guest wouldn''t touch that MSR unless it intends to set SCE.
Oops, SCE enables SYSCALL. Yes, that might be a problem -- I think 
there is no ''safety catch'' except for that EFER flag. Possibly
the MSR
does need save/restore on context switch.

  -- Keir


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