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

["Liu, Yuan B" <yuan.b.liu@xxxxxxxxx>]

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@xxxxxxxxxxxxx] 
Sent: Friday, September 03, 2010 3:15 PM
To: Liu, Yuan B; xen-devel@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel