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 <[email protected]>
> ...
> 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
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
