In VMX operation, the handling of INIT IPIs is changed. EXIT_REASON_INIT has nothing to do with the guest in question, simply signals that an INIT was received.
Ignoring the INIT is probably the wrong thing to do, but is helpful for debugging. Crashing the domain which happens to be in context is definitely wrong. Print an error message and continue. Discovered as collateral damage from when an AP triple faults on S3 resume on Intel TigerLake platforms. Link: https://github.com/QubesOS/qubes-issues/issues/7283 Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> --- CC: Jan Beulich <jbeul...@suse.com> CC: Roger Pau Monné <roger....@citrix.com> CC: Wei Liu <w...@xen.org> CC: Jun Nakajima <jun.nakaj...@intel.com> CC: Kevin Tian <kevin.t...@intel.com> CC: Thiner Logoer <logoerthin...@163.com> CC: Marek Marczykowski-Górecki <marma...@invisiblethingslab.com> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index c075370f642a..883213ce8f6a 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -3965,6 +3965,10 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs) case EXIT_REASON_MCE_DURING_VMENTRY: do_machine_check(regs); break; + + case EXIT_REASON_INIT: + printk(XENLOG_ERR "Error: INIT received - ignoring\n"); + return; /* Renter the guest without further processing */ } /* Now enable interrupts so it's safe to take locks. */
