[RFC PATCH V4 0/4] x86/Hyper-V: Add AMD Secure AVIC for Hyper-V platform

[RFC PATCH V4 0/4] x86/Hyper-V: Add AMD Secure AVIC for Hyper-V platform

[Tianyu Lan]

From: Tianyu Lan <tiala@microsoft.com>

Secure AVIC is a new hardware feature in the AMD64
architecture to allow SEV-SNP guests to prevent the
hypervisor from generating unexpected interrupts to
a vCPU or otherwise violate architectural assumptions
around APIC behavior.

Each vCPU has a guest-allocated APIC backing page of
size 4K, which maintains APIC state for that vCPU.
APIC backing page's ALLOWED_IRR field indicates the
interrupt vectors which the guest allows the hypervisor
to send.

This patchset is to enable the feature for Hyper-V
platform. Patch "Drivers: hv: Allow vmbus message
synic interrupt injected from Hyper-V" is to expose
new fucntion hv_enable_coco_interrupt() and device
driver and arch code may update AVIC backing page
ALLOWED_IRR field to allow Hyper-V inject associated
vector.

This patchset is based on the AMD patchset "AMD: Add
Secure AVIC Guest Support"
https://lkml.org/lkml/2025/6/10/1579

Chnage since v3:
	- Disable VMBus Message interrupt via hv_enable_
       	  coco_interrupt() in the hv_synic_disable_regs().
	- Fix coding style issue and update change log.

Change since v2:
       - Add hv_enable_coco_interrupt() as wrapper
        of apic_update_vector()
       - Re-work change logs

Change since v1:
       - Remove the check of Secure AVIC when set APIC backing page
       - Use apic_update_vector() instead of exposing new interface
       from Secure AVIC driver to update APIC backing page and allow
       associated interrupt to be injected by hypervisor.

Tianyu Lan (4):
  x86/hyperv: Don't use hv apic driver when Secure AVIC is available
  drivers/hv: Allow vmbus message synic interrupt injected from Hyper-V
  x86/hyperv: Don't use auto-eoi when Secure AVIC is available
  x86/hyperv: Allow Hyper-V to inject STIMER0 interrupts

 arch/x86/hyperv/hv_apic.c      | 8 ++++++++
 arch/x86/hyperv/hv_init.c      | 7 +++++++
 arch/x86/kernel/cpu/mshyperv.c | 2 ++
 drivers/hv/hv.c                | 2 ++
 drivers/hv/hv_common.c         | 5 +++++
 include/asm-generic/mshyperv.h | 1 +
 6 files changed, 25 insertions(+)

-- 
2.25.1

[RFC PATCH V4 1/4] x86/hyperv: Don't use hv apic driver when Secure AVIC is available

[Tianyu Lan]

From: Tianyu Lan <tiala@microsoft.com>

When Secure AVIC is available, the AMD x2apic Secure
AVIC driver will be selected. In that case, have hv_apic_init()
return immediately without doing anything.

Signed-off-by: Tianyu Lan <tiala@microsoft.com>
---
Change since RFC V3:
       - Update Change log and fix coding style issue.
---
 arch/x86/hyperv/hv_apic.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/x86/hyperv/hv_apic.c b/arch/x86/hyperv/hv_apic.c
index bfde0a3498b9..e669053b637d 100644
--- a/arch/x86/hyperv/hv_apic.c
+++ b/arch/x86/hyperv/hv_apic.c
@@ -293,6 +293,9 @@ static void hv_send_ipi_self(int vector)
 
 void __init hv_apic_init(void)
 {
+	if (cc_platform_has(CC_ATTR_SNP_SECURE_AVIC))
+		return;
+
 	if (ms_hyperv.hints & HV_X64_CLUSTER_IPI_RECOMMENDED) {
 		pr_info("Hyper-V: Using IPI hypercalls\n");
 		/*
-- 
2.25.1

[RFC PATCH V4 2/4] drivers/hv: Allow vmbus message synic interrupt injected from Hyper-V

[Tianyu Lan]

From: Tianyu Lan <tiala@microsoft.com>

When Secure AVIC is enabled, VMBus driver should
call x2apic Secure AVIC interface to allow Hyper-V
to inject VMBus message interrupt.

Signed-off-by: Tianyu Lan <tiala@microsoft.com>
---
Change since RFC V3:
       - Disable VMBus Message interrupt via hv_enable_
       	 coco_interrupt() in the hv_synic_disable_regs().
---
 arch/x86/hyperv/hv_apic.c      | 5 +++++
 drivers/hv/hv.c                | 2 ++
 drivers/hv/hv_common.c         | 5 +++++
 include/asm-generic/mshyperv.h | 1 +
 4 files changed, 13 insertions(+)

diff --git a/arch/x86/hyperv/hv_apic.c b/arch/x86/hyperv/hv_apic.c
index e669053b637d..a8de503def37 100644
--- a/arch/x86/hyperv/hv_apic.c
+++ b/arch/x86/hyperv/hv_apic.c
@@ -53,6 +53,11 @@ static void hv_apic_icr_write(u32 low, u32 id)
 	wrmsrq(HV_X64_MSR_ICR, reg_val);
 }
 
+void hv_enable_coco_interrupt(unsigned int cpu, unsigned int vector, bool set)
+{
+	apic_update_vector(cpu, vector, set);
+}
+
 static u32 hv_apic_read(u32 reg)
 {
 	u32 reg_val, hi;
diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
index 308c8f279df8..aa384dbf38ac 100644
--- a/drivers/hv/hv.c
+++ b/drivers/hv/hv.c
@@ -310,6 +310,7 @@ void hv_synic_enable_regs(unsigned int cpu)
 	if (vmbus_irq != -1)
 		enable_percpu_irq(vmbus_irq, 0);
 	shared_sint.as_uint64 = hv_get_msr(HV_MSR_SINT0 + VMBUS_MESSAGE_SINT);
+	hv_enable_coco_interrupt(cpu, vmbus_interrupt, true);
 
 	shared_sint.vector = vmbus_interrupt;
 	shared_sint.masked = false;
@@ -342,6 +343,7 @@ void hv_synic_disable_regs(unsigned int cpu)
 	union hv_synic_scontrol sctrl;
 
 	shared_sint.as_uint64 = hv_get_msr(HV_MSR_SINT0 + VMBUS_MESSAGE_SINT);
+	hv_enable_coco_interrupt(cpu, vmbus_interrupt, false);
 
 	shared_sint.masked = 1;
 
diff --git a/drivers/hv/hv_common.c b/drivers/hv/hv_common.c
index 49898d10faff..0f024ab3d360 100644
--- a/drivers/hv/hv_common.c
+++ b/drivers/hv/hv_common.c
@@ -716,6 +716,11 @@ u64 __weak hv_tdx_hypercall(u64 control, u64 param1, u64 param2)
 }
 EXPORT_SYMBOL_GPL(hv_tdx_hypercall);
 
+void __weak hv_enable_coco_interrupt(unsigned int cpu, unsigned int vector, bool set)
+{
+}
+EXPORT_SYMBOL_GPL(hv_enable_coco_interrupt);
+
 void hv_identify_partition_type(void)
 {
 	/* Assume guest role */
diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyperv.h
index a729b77983fa..7907c9878369 100644
--- a/include/asm-generic/mshyperv.h
+++ b/include/asm-generic/mshyperv.h
@@ -333,6 +333,7 @@ bool hv_is_isolation_supported(void);
 bool hv_isolation_type_snp(void);
 u64 hv_ghcb_hypercall(u64 control, void *input, void *output, u32 input_size);
 u64 hv_tdx_hypercall(u64 control, u64 param1, u64 param2);
+void hv_enable_coco_interrupt(unsigned int cpu, unsigned int vector, bool set);
 void hyperv_cleanup(void);
 bool hv_query_ext_cap(u64 cap_query);
 void hv_setup_dma_ops(struct device *dev, bool coherent);
-- 
2.25.1

[RFC PATCH V4 3/4] x86/hyperv: Don't use auto-eoi when Secure AVIC is available

[Tianyu Lan]

From: Tianyu Lan <tiala@microsoft.com>

Hyper-V doesn't support auto-eoi with Secure AVIC.
So set the HV_DEPRECATING_AEOI_RECOMMENDED flag
to force writing the EOI register after handling
an interrupt.

Signed-off-by: Tianyu Lan <tiala@microsoft.com>
---
Change since RFC V3:
       - Update title prefix from "x86/Hyper-V" to "x86/hyperv"
---
 arch/x86/kernel/cpu/mshyperv.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index c78f860419d6..8f029650f16c 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -463,6 +463,8 @@ static void __init ms_hyperv_init_platform(void)
 		 ms_hyperv.max_vp_index, ms_hyperv.max_lp_index);
 
 	hv_identify_partition_type();
+	if (cc_platform_has(CC_ATTR_SNP_SECURE_AVIC))
+		ms_hyperv.hints |= HV_DEPRECATING_AEOI_RECOMMENDED;
 
 	if (ms_hyperv.hints & HV_X64_HYPERV_NESTED) {
 		hv_nested = true;
-- 
2.25.1

[RFC PATCH V4 4/4] x86/hyperv: Allow Hyper-V to inject STIMER0 interrupts

[Tianyu Lan]

From: Tianyu Lan <tiala@microsoft.com>

When Secure AVIC is enabled, call Secure AVIC
function to allow Hyper-V to inject STIMER0 interrupt.

Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Signed-off-by: Tianyu Lan <tiala@microsoft.com>
---
 arch/x86/hyperv/hv_init.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index 3d1d3547095a..591338162420 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -132,6 +132,10 @@ static int hv_cpu_init(unsigned int cpu)
 		wrmsrq(HV_X64_MSR_VP_ASSIST_PAGE, msr.as_uint64);
 	}
 
+	/* Allow Hyper-V stimer vector to be injected from Hypervisor. */
+	if (ms_hyperv.misc_features & HV_STIMER_DIRECT_MODE_AVAILABLE)
+		apic_update_vector(cpu, HYPERV_STIMER0_VECTOR, true);
+
 	return hyperv_init_ghcb();
 }
 
@@ -239,6 +243,9 @@ static int hv_cpu_die(unsigned int cpu)
 		*ghcb_va = NULL;
 	}
 
+	if (ms_hyperv.misc_features & HV_STIMER_DIRECT_MODE_AVAILABLE)
+		apic_update_vector(cpu, HYPERV_STIMER0_VECTOR, false);
+
 	hv_common_cpu_die(cpu);
 
 	if (hv_vp_assist_page && hv_vp_assist_page[cpu]) {
-- 
2.25.1

RE: [RFC PATCH V4 1/4] x86/hyperv: Don't use hv apic driver when Secure AVIC is available

[Michael Kelley]

From: Tianyu Lan <ltykernel@gmail.com> Sent: Saturday, July 26, 2025 6:43 AM
> 
> When Secure AVIC is available, the AMD x2apic Secure
> AVIC driver will be selected. In that case, have hv_apic_init()
> return immediately without doing anything.
> 
> Signed-off-by: Tianyu Lan <tiala@microsoft.com>
> ---
> Change since RFC V3:
>        - Update Change log and fix coding style issue.
> ---
>  arch/x86/hyperv/hv_apic.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/x86/hyperv/hv_apic.c b/arch/x86/hyperv/hv_apic.c
> index bfde0a3498b9..e669053b637d 100644
> --- a/arch/x86/hyperv/hv_apic.c
> +++ b/arch/x86/hyperv/hv_apic.c
> @@ -293,6 +293,9 @@ static void hv_send_ipi_self(int vector)
> 
>  void __init hv_apic_init(void)
>  {
> +	if (cc_platform_has(CC_ATTR_SNP_SECURE_AVIC))
> +		return;
> +
>  	if (ms_hyperv.hints & HV_X64_CLUSTER_IPI_RECOMMENDED) {
>  		pr_info("Hyper-V: Using IPI hypercalls\n");
>  		/*
> --
> 2.25.1
> 

Reviewed-by: Michael Kelley <mhklinux@outlook.com>

RE: [RFC PATCH V4 2/4] drivers/hv: Allow vmbus message synic interrupt injected from Hyper-V

[Michael Kelley]

From: Tianyu Lan <ltykernel@gmail.com> Sent: Saturday, July 26, 2025 6:43 AM
> 

Nit: The patch "Subject:" prefix here should be "Drivers: hv:" with no slash, as
it was in v3 of the patch. That's admittedly not consistent with "x86/hyperv:"
that is used for the other patches in this series, but it is consistent with historical
practice for the files in the drivers/hv folder. You have to look at past commits
for a particular file to see what the typical prefix is.

Michael

> When Secure AVIC is enabled, VMBus driver should
> call x2apic Secure AVIC interface to allow Hyper-V
> to inject VMBus message interrupt.
> 
> Signed-off-by: Tianyu Lan <tiala@microsoft.com>
> ---
> Change since RFC V3:
>        - Disable VMBus Message interrupt via hv_enable_
>        	 coco_interrupt() in the hv_synic_disable_regs().
> ---
>  arch/x86/hyperv/hv_apic.c      | 5 +++++
>  drivers/hv/hv.c                | 2 ++
>  drivers/hv/hv_common.c         | 5 +++++
>  include/asm-generic/mshyperv.h | 1 +
>  4 files changed, 13 insertions(+)
> 
> diff --git a/arch/x86/hyperv/hv_apic.c b/arch/x86/hyperv/hv_apic.c
> index e669053b637d..a8de503def37 100644
> --- a/arch/x86/hyperv/hv_apic.c
> +++ b/arch/x86/hyperv/hv_apic.c
> @@ -53,6 +53,11 @@ static void hv_apic_icr_write(u32 low, u32 id)
>  	wrmsrq(HV_X64_MSR_ICR, reg_val);
>  }
> 
> +void hv_enable_coco_interrupt(unsigned int cpu, unsigned int vector, bool set)
> +{
> +	apic_update_vector(cpu, vector, set);
> +}
> +
>  static u32 hv_apic_read(u32 reg)
>  {
>  	u32 reg_val, hi;
> diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
> index 308c8f279df8..aa384dbf38ac 100644
> --- a/drivers/hv/hv.c
> +++ b/drivers/hv/hv.c
> @@ -310,6 +310,7 @@ void hv_synic_enable_regs(unsigned int cpu)
>  	if (vmbus_irq != -1)
>  		enable_percpu_irq(vmbus_irq, 0);
>  	shared_sint.as_uint64 = hv_get_msr(HV_MSR_SINT0 + VMBUS_MESSAGE_SINT);
> +	hv_enable_coco_interrupt(cpu, vmbus_interrupt, true);
> 
>  	shared_sint.vector = vmbus_interrupt;
>  	shared_sint.masked = false;

Something I just noticed. The existing code in hv_synic_enable_regs()
is reading the SINT MSR, updating some values, and then writing back
the SINT MSR. Those steps act as a unit to update the MSR. You've added
the call to hv_enable_coco_interrupts() in the middle of that unit, which
implies there might be a reason for it. If there's not a reason, I would
expect the call to hv_enable_coco_interrupt() to be before the unit,
not in the middle of it.

> @@ -342,6 +343,7 @@ void hv_synic_disable_regs(unsigned int cpu)
>  	union hv_synic_scontrol sctrl;
> 
>  	shared_sint.as_uint64 = hv_get_msr(HV_MSR_SINT0 + VMBUS_MESSAGE_SINT);
> +	hv_enable_coco_interrupt(cpu, vmbus_interrupt, false);

Same here with the hv_enable_coco_interrupt() call in the middle
of the unit that is updating the SINT MSR. In the disable path, I would
have expected hv_enable_coco_interrupt() to be *after* the unit so
that disable operations are in reverse order of the corresponding enable
operation.

> 
>  	shared_sint.masked = 1;
> 
> diff --git a/drivers/hv/hv_common.c b/drivers/hv/hv_common.c
> index 49898d10faff..0f024ab3d360 100644
> --- a/drivers/hv/hv_common.c
> +++ b/drivers/hv/hv_common.c
> @@ -716,6 +716,11 @@ u64 __weak hv_tdx_hypercall(u64 control, u64 param1, u64 param2)
>  }
>  EXPORT_SYMBOL_GPL(hv_tdx_hypercall);
> 
> +void __weak hv_enable_coco_interrupt(unsigned int cpu, unsigned int vector, bool set)
> +{
> +}
> +EXPORT_SYMBOL_GPL(hv_enable_coco_interrupt);
> +
>  void hv_identify_partition_type(void)
>  {
>  	/* Assume guest role */
> diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyperv.h
> index a729b77983fa..7907c9878369 100644
> --- a/include/asm-generic/mshyperv.h
> +++ b/include/asm-generic/mshyperv.h
> @@ -333,6 +333,7 @@ bool hv_is_isolation_supported(void);
>  bool hv_isolation_type_snp(void);
>  u64 hv_ghcb_hypercall(u64 control, void *input, void *output, u32 input_size);
>  u64 hv_tdx_hypercall(u64 control, u64 param1, u64 param2);
> +void hv_enable_coco_interrupt(unsigned int cpu, unsigned int vector, bool set);
>  void hyperv_cleanup(void);
>  bool hv_query_ext_cap(u64 cap_query);
>  void hv_setup_dma_ops(struct device *dev, bool coherent);
> --
> 2.25.1
> 

RE: [RFC PATCH V4 3/4] x86/hyperv: Don't use auto-eoi when Secure AVIC is available

[Michael Kelley]

From: Tianyu Lan <ltykernel@gmail.com> Sent: Saturday, July 26, 2025 6:43 AM
> 
> Hyper-V doesn't support auto-eoi with Secure AVIC.
> So set the HV_DEPRECATING_AEOI_RECOMMENDED flag
> to force writing the EOI register after handling
> an interrupt.
> 
> Signed-off-by: Tianyu Lan <tiala@microsoft.com>
> ---
> Change since RFC V3:
>        - Update title prefix from "x86/Hyper-V" to "x86/hyperv"
> ---
>  arch/x86/kernel/cpu/mshyperv.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
> index c78f860419d6..8f029650f16c 100644
> --- a/arch/x86/kernel/cpu/mshyperv.c
> +++ b/arch/x86/kernel/cpu/mshyperv.c
> @@ -463,6 +463,8 @@ static void __init ms_hyperv_init_platform(void)
>  		 ms_hyperv.max_vp_index, ms_hyperv.max_lp_index);
> 
>  	hv_identify_partition_type();
> +	if (cc_platform_has(CC_ATTR_SNP_SECURE_AVIC))
> +		ms_hyperv.hints |= HV_DEPRECATING_AEOI_RECOMMENDED;
> 
>  	if (ms_hyperv.hints & HV_X64_HYPERV_NESTED) {
>  		hv_nested = true;
> --
> 2.25.1
> 

Reviewed-by: Michael Kelley <mhklinux@outlook.com>

Re: [RFC PATCH V4 2/4] drivers/hv: Allow vmbus message synic interrupt injected from Hyper-V

[Tianyu Lan]

On Mon, Jul 28, 2025 at 10:45 PM Michael Kelley <mhklinux@outlook.com> wrote:
>
> From: Tianyu Lan <ltykernel@gmail.com> Sent: Saturday, July 26, 2025 6:43 AM
> >
>
> Nit: The patch "Subject:" prefix here should be "Drivers: hv:" with no slash, as
> it was in v3 of the patch. That's admittedly not consistent with "x86/hyperv:"
> that is used for the other patches in this series, but it is consistent with historical
> practice for the files in the drivers/hv folder. You have to look at past commits
> for a particular file to see what the typical prefix is.
>
> Michael
>
> > When Secure AVIC is enabled, VMBus driver should
> > call x2apic Secure AVIC interface to allow Hyper-V
> > to inject VMBus message interrupt.
> >
> > Signed-off-by: Tianyu Lan <tiala@microsoft.com>
> > ---
> > Change since RFC V3:
> >        - Disable VMBus Message interrupt via hv_enable_
> >                coco_interrupt() in the hv_synic_disable_regs().
> > ---
> >  arch/x86/hyperv/hv_apic.c      | 5 +++++
> >  drivers/hv/hv.c                | 2 ++
> >  drivers/hv/hv_common.c         | 5 +++++
> >  include/asm-generic/mshyperv.h | 1 +
> >  4 files changed, 13 insertions(+)
> >
> > diff --git a/arch/x86/hyperv/hv_apic.c b/arch/x86/hyperv/hv_apic.c
> > index e669053b637d..a8de503def37 100644
> > --- a/arch/x86/hyperv/hv_apic.c
> > +++ b/arch/x86/hyperv/hv_apic.c
> > @@ -53,6 +53,11 @@ static void hv_apic_icr_write(u32 low, u32 id)
> >       wrmsrq(HV_X64_MSR_ICR, reg_val);
> >  }
> >
> > +void hv_enable_coco_interrupt(unsigned int cpu, unsigned int vector, bool set)
> > +{
> > +     apic_update_vector(cpu, vector, set);
> > +}
> > +
> >  static u32 hv_apic_read(u32 reg)
> >  {
> >       u32 reg_val, hi;
> > diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
> > index 308c8f279df8..aa384dbf38ac 100644
> > --- a/drivers/hv/hv.c
> > +++ b/drivers/hv/hv.c
> > @@ -310,6 +310,7 @@ void hv_synic_enable_regs(unsigned int cpu)
> >       if (vmbus_irq != -1)
> >               enable_percpu_irq(vmbus_irq, 0);
> >       shared_sint.as_uint64 = hv_get_msr(HV_MSR_SINT0 + VMBUS_MESSAGE_SINT);
> > +     hv_enable_coco_interrupt(cpu, vmbus_interrupt, true);
> >
> >       shared_sint.vector = vmbus_interrupt;
> >       shared_sint.masked = false;
>
> Something I just noticed. The existing code in hv_synic_enable_regs()
> is reading the SINT MSR, updating some values, and then writing back
> the SINT MSR. Those steps act as a unit to update the MSR. You've added
> the call to hv_enable_coco_interrupts() in the middle of that unit, which
> implies there might be a reason for it. If there's not a reason, I would
> expect the call to hv_enable_coco_interrupt() to be before the unit,
> not in the middle of it.
>
> > @@ -342,6 +343,7 @@ void hv_synic_disable_regs(unsigned int cpu)
> >       union hv_synic_scontrol sctrl;
> >
> >       shared_sint.as_uint64 = hv_get_msr(HV_MSR_SINT0 + VMBUS_MESSAGE_SINT);
> > +     hv_enable_coco_interrupt(cpu, vmbus_interrupt, false);
>
> Same here with the hv_enable_coco_interrupt() call in the middle
> of the unit that is updating the SINT MSR. In the disable path, I would
> have expected hv_enable_coco_interrupt() to be *after* the unit so
> that disable operations are in reverse order of the corresponding enable
> operation.
>

Agree. Have updated in the RFC V5 series. Thanks for your suggestion, Michael!

--
Thanks
Tianyu Lan