From: Tianyu Lan <ltyker...@gmail.com> Sent: Tuesday, May 6, 2025 6:07 AM >
Update Subject prefix to "x86/hyperv". > When Secure AVIC is enabled, call Secure AVIC > function to allow Hyper-V to inject REENLIGHTENMENT, > STIMER0 and CALLBACK vectors. > > Signed-off-by: Tianyu Lan <ti...@microsoft.com> > --- > arch/x86/hyperv/hv_init.c | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c > index ddeb40930bc8..d75df5c3965d 100644 > --- a/arch/x86/hyperv/hv_init.c > +++ b/arch/x86/hyperv/hv_init.c > @@ -131,6 +131,18 @@ static int hv_cpu_init(unsigned int cpu) > wrmsrl(HV_X64_MSR_VP_ASSIST_PAGE, msr.as_uint64); > } > > + /* Allow Hyper-V vector to be injected from Hypervisor. */ > + if (ms_hyperv.features & HV_ACCESS_REENLIGHTENMENT) > + x2apic_savic_update_vector(cpu, > + HYPERV_REENLIGHTENMENT_VECTOR, true); This will allow Hyper-V to submit the re-enlightenment interrupt on any vCPU, even though the Linux guest has programmed the interrupt to only arrive to a particular vCPU. That selected vCPU is set up in set_hv_tscchange_cb(), and maintained in clear_hv_tscchange_cb() and in hv_cpu_die(). I'm not super familiar with the re-enlightenment code, but I don't see a problem if Hyper-V sends the interrupt on an unexpected vCPU. So it's probably OK to enable this interrupt vector on all vCPUs. > + > + if (ms_hyperv.misc_features & HV_STIMER_DIRECT_MODE_AVAILABLE) > + x2apic_savic_update_vector(cpu, > + HYPERV_STIMER0_VECTOR, true); > + > + x2apic_savic_update_vector(cpu, HYPERVISOR_CALLBACK_VECTOR, true); This is redundant with Patch 3 of your patch set. In Patch 3, vmbus_interrupt is set to HYPERVISOR_CALLBACK_VECTOR. > + > + > return hyperv_init_ghcb(); > } > > -- > 2.25.1 >
