On 26/10/2018 12:09, Andrew Cooper wrote: > Ok - that patch is now as follows: > > x86/vvmx: Let L1 handle all the unconditional vmexit instructions > > Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> > ... > diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c > index aa202e0..7051eb3 100644 > --- a/xen/arch/x86/hvm/vmx/vvmx.c > +++ b/xen/arch/x86/hvm/vmx/vvmx.c > @@ -2383,6 +2383,8 @@ int nvmx_n2_vmexit_handler(struct cpu_user_regs *regs, > case EXIT_REASON_TRIPLE_FAULT: > case EXIT_REASON_TASK_SWITCH: > case EXIT_REASON_CPUID: > + case EXIT_REASON_GETSEC: > + case EXIT_REASON_INVD: > case EXIT_REASON_VMCALL: > case EXIT_REASON_VMCLEAR: > case EXIT_REASON_VMLAUNCH: > @@ -2395,6 +2397,7 @@ int nvmx_n2_vmexit_handler(struct cpu_user_regs *regs, > case EXIT_REASON_VMXON: > case EXIT_REASON_INVEPT: > case EXIT_REASON_XSETBV: > + case EXIT_REASON_INVVPID: > /* inject to L1 */ > nvcpu->nv_vmexit_pending = 1; > break; > > RDTSCP and VMFUNC mustn't be blindly forwarded to L1. We need to check > whether the intercepts are active and either forward to L1 or handle at L0.
I think the below will do for RDTSCP. VMFUNC is trickier but Xen currently doesn't provide this capability to L1 anyway. diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c index aa202e0d12..1d1a0921af 100644 --- a/xen/arch/x86/hvm/vmx/vvmx.c +++ b/xen/arch/x86/hvm/vmx/vvmx.c @@ -2653,6 +2653,13 @@ int nvmx_n2_vmexit_handler(struct cpu_user_regs *regs, if ( ctrl & CPU_BASED_TPR_SHADOW ) nvcpu->nv_vmexit_pending = 1; break; + + case EXIT_REASON_RDTSCP: + ctrl = __n2_exec_control(v); + if ( ctrl & CPU_BASED_RDTSC_EXITING ) + nvcpu->nv_vmexit_pending = 1; + break; + default: gprintk(XENLOG_ERR, "Unexpected nested vmexit: reason %u\n", exit_reason); --- Thanks, Sergey _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel