On 26/10/2018 10:10, Andrew Cooper wrote: > 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 <andrew.coop...@citrix.com> >>> --- >>> CC: Sergey Dyasli <sergey.dya...@citrix.com> >>> CC: Jan Beulich <jbeul...@suse.com> >>> CC: Wei Liu <wei.l...@citrix.com> >>> CC: Jun Nakajima <jun.nakaj...@intel.com> >>> CC: Kevin Tian <kevin.t...@intel.com> >>> --- >>> 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?
Yes, that would be a cleaner way, thanks. -- Sergey _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
