Xen devel - Sep 2010 - [PATCH]: Add handlers for missing exit_reasons documented by Intel SDM 3B

These are just two trivial patches.

xen/arch/x86/hvm/vmx/vmx.c        |  14 ++++++++++++++
xen/include/asm-x86/hvm/vmx/vmx.h |   6 ++++++
2 files changed, 20 insertions(+), 0 deletions(-)

Thanks,
Yuan




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

Is this just for neatness (we never actually should be vmexit''ing for
these
reasons)? If so, isn''t it really better to keep these handled by the
default
case which logs the vmexit as an unexpected error?

 -- Keir

On 03/09/2010 07:11, "Liu, Yuan B" <yuan.b.liu@intel.com> wrote:
> These are just two trivial patches.
>  
> xen/arch/x86/hvm/vmx/vmx.c       |  14 ++++++++++++++
> xen/include/asm-x86/hvm/vmx/vmx.h |   6 ++++++
> 2 files changed, 20 insertions(+), 0 deletions(-)
>  
> Thanks,
> Yuan
> 


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

According to the SDM, GETSEC, INVEPT, INVVPID can be executed by guests in some
cases. For e.g.

GETSEC(SDM 2B 6.2.1)
System software enables SMX operation by setting CR4.SMXE[Bit 14] = 1 before
attempting to execute GETSEC. Otherwise, execution of GETSEC results in the
processor signaling an invalid opcode exception (#UD).

Since Xen doesn''t permit guests to set the SMXE bit in CR4 (refer to
hvm_set_cr4 in hvm.c) GETSEC should generate an #UD instead of referring to
default handler.

Simply put, for these three reasons, crashing the guest is considered to
overkill and #UD is better.

For ACCESS_GDTR_OR_IDTR, ACCESS_LDTR_OR_TR , vm-exiting is not expected and is
considered to be hardware fault, so they go to default handler path. Xen
doesn''t implement logic to take this VMX_PREEMPTION_TIMER_EXPIRED
feature. So it shouldn''t happen in a sound hardware configuration.
Patches just make this more explicit.

Thanks,
Yuan

-----Original Message-----
From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] 
Sent: Friday, September 03, 2010 3:15 PM
To: Liu, Yuan B; xen-devel@lists.xensource.com
Cc: Dong, Eddie
Subject: Re: [Xen-devel] [PATCH]: Add handlers for missing exit_reasons
documented by Intel SDM 3B

Is this just for neatness (we never actually should be vmexit''ing for
these
reasons)? If so, isn''t it really better to keep these handled by the
default
case which logs the vmexit as an unexpected error?

 -- Keir

On 03/09/2010 07:11, "Liu, Yuan B" <yuan.b.liu@intel.com> wrote:
> These are just two trivial patches.
>  
> xen/arch/x86/hvm/vmx/vmx.c       |  14 ++++++++++++++
> xen/include/asm-x86/hvm/vmx/vmx.h |   6 ++++++
> 2 files changed, 20 insertions(+), 0 deletions(-)
>  
> Thanks,
> Yuan
> 


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

On 03/09/2010 09:29, "Liu, Yuan B" <yuan.b.liu@intel.com> wrote:
> According to the SDM, GETSEC, INVEPT, INVVPID can be executed by guests in
> some cases. For e.g.
> 
> GETSEC(SDM 2B 6.2.1)
> System software enables SMX operation by setting CR4.SMXE[Bit 14] = 1
before
> attempting to execute GETSEC. Otherwise, execution of GETSEC results in the
> processor signaling an invalid opcode exception (#UD).
> 
> Since Xen doesn''t permit guests to set the SMXE bit in CR4 (refer
to
> hvm_set_cr4 in hvm.c) GETSEC should generate an #UD instead of referring to
> default handler.
Well actually given that CR4.SMXE always is 0 when the guest runs, the
VMEXIT will never be taken, since the CPU checks CR4.SMXE before checking
for running in non-root context.

I guess I agree with the patch overall. I would consider putting a
WARN_ON(1) on the GETSEC vmexit path, with a code comment explaining it
should be unreachable currently. What do you think? I can make that change
myself if you agree.

 -- Keir



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

Yes, sounds better with a warn_on. Thanks for helping me add it : )

Yuan

-----Original Message-----
From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] 
Sent: Friday, September 03, 2010 4:40 PM
To: Liu, Yuan B; xen-devel@lists.xensource.com
Cc: Dong, Eddie; Zhang, Xiantao
Subject: Re: [Xen-devel] [PATCH]: Add handlers for missing exit_reasons
documented by Intel SDM 3B

On 03/09/2010 09:29, "Liu, Yuan B" <yuan.b.liu@intel.com> wrote:
> According to the SDM, GETSEC, INVEPT, INVVPID can be executed by guests in
> some cases. For e.g.
> 
> GETSEC(SDM 2B 6.2.1)
> System software enables SMX operation by setting CR4.SMXE[Bit 14] = 1
before
> attempting to execute GETSEC. Otherwise, execution of GETSEC results in the
> processor signaling an invalid opcode exception (#UD).
> 
> Since Xen doesn''t permit guests to set the SMXE bit in CR4 (refer
to
> hvm_set_cr4 in hvm.c) GETSEC should generate an #UD instead of referring to
> default handler.
Well actually given that CR4.SMXE always is 0 when the guest runs, the
VMEXIT will never be taken, since the CPU checks CR4.SMXE before checking
for running in non-root context.

I guess I agree with the patch overall. I would consider putting a
WARN_ON(1) on the GETSEC vmexit path, with a code comment explaining it
should be unreachable currently. What do you think? I can make that change
myself if you agree.

 -- Keir



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