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
|
Home