On 26/10/2018 10:05, Sergey Dyasli wrote: > > On 25/10/2018 16:39, Andrew Cooper wrote: >> This is very dangerous from a security point of view, because a missing entry >> will cause L2's action to be interpreted as L1's action. >> >> Signed-off-by: Andrew Cooper <[email protected]> >> --- >> CC: Sergey Dyasli <[email protected]> >> CC: Jan Beulich <[email protected]> >> CC: Wei Liu <[email protected]> >> CC: Jun Nakajima <[email protected]> >> CC: Kevin Tian <[email protected]> >> --- >> xen/arch/x86/hvm/vmx/vvmx.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c >> index d1c8a41..817d85f 100644 >> --- a/xen/arch/x86/hvm/vmx/vvmx.c >> +++ b/xen/arch/x86/hvm/vmx/vvmx.c >> @@ -2609,8 +2609,9 @@ int nvmx_n2_vmexit_handler(struct cpu_user_regs *regs, >> nvcpu->nv_vmexit_pending = 1; >> break; >> default: >> - gprintk(XENLOG_ERR, "Unexpected nested vmexit: reason %u\n", >> + gprintk(XENLOG_ERR, "Unhandled nested vmexit: reason %u\n", >> exit_reason); >> + domain_crash(v->domain); >> } >> >> return ( nvcpu->nv_vmexit_pending == 1 ); > Can you consider adding handling for the following? > > EXIT_REASON_INVD > EXIT_REASON_RDTSCP > EXIT_REASON_VMFUNC
Looks like these should be merged in with the INVVPID change, if your happy with that? ~Andrew _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
