* Re: [PATCH v4 4/7] Drivers: hv: Use hv_setup_*() to set up hypercall arguments
From: Nuno Das Neves @ 2025-07-28 17:02 UTC (permalink / raw)
To: mhklinux, kys, haiyangz, wei.liu, decui, tglx, mingo, bp,
dave.hansen, hpa, lpieralisi, kw, mani, robh, bhelgaas, arnd
Cc: x86, linux-hyperv, linux-kernel, linux-pci, linux-arch
In-Reply-To: <20250718045545.517620-5-mhklinux@outlook.com>
On 7/17/2025 9:55 PM, mhkelley58@gmail.com wrote:
<snip>
> diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
> index 2b4080e51f97..d9b569b204d2 100644
> --- a/drivers/hv/hv_balloon.c
> +++ b/drivers/hv/hv_balloon.c
> @@ -1577,21 +1577,21 @@ static int hv_free_page_report(struct page_reporting_dev_info *pr_dev_info,
> {
> unsigned long flags;
> struct hv_memory_hint *hint;
> - int i, order;
> + int i, order, batch_size;
> u64 status;
> struct scatterlist *sg;
>
> - WARN_ON_ONCE(nents > HV_MEMORY_HINT_MAX_GPA_PAGE_RANGES);
> WARN_ON_ONCE(sgl->length < (HV_HYP_PAGE_SIZE << page_reporting_order));
> local_irq_save(flags);
> - hint = *this_cpu_ptr(hyperv_pcpu_input_arg);
> +
> + batch_size = hv_setup_in_array(&hint, sizeof(*hint), sizeof(hint->ranges[0]));
> if (!hint) {
> local_irq_restore(flags);
> return -ENOSPC;
> }
> + WARN_ON_ONCE(nents > batch_size);
>
I don't think WARN_ON_ONCE is sufficient here... this looks like a bug in the current code.
The loop below will go out of bounds of the input page if nents is too large.
Ideally this function would be refactored to batch the operation so that this isn't a
problem.
Nuno
> hint->heat_type = HV_EXTMEM_HEAT_HINT_COLD_DISCARD;
> - hint->reserved = 0;
> for_each_sg(sgl, sg, nents, i) {
> union hv_gpa_page_range *range;
>
<snip>
^ permalink raw reply
* Re: [PATCH RESEND] netvsc: transfer lower device max tso size
From: Jakub Kicinski @ 2025-07-28 15:19 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Haiyang Zhang, Jason Wang, Cindy Lu, KY Srinivasan, Wei Liu,
Dexuan Cui, Andrew Lunn, David S. Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, Michael Kelley, Shradha Gupta,
Kees Cook, Stanislav Fomichev, Kuniyuki Iwashima,
Alexander Lobakin, Guillaume Nault, Joe Damato, Ahmed Zaki,
open list:Hyper-V/Azure CORE AND DRIVERS,
open list:NETWORKING DRIVERS, open list
In-Reply-To: <20250727200126.2682aa39@hermes.local>
On Sun, 27 Jul 2025 20:01:26 -0700 Stephen Hemminger wrote:
> On Wed, 23 Jul 2025 15:16:22 -0700
> Jakub Kicinski <kuba@kernel.org> wrote:
> >
> > > Actually, we had used the common bonding driver 9 years ago. But it's
> > > replaced by this kernel/netvsc based "transparent" bonding mode. See
> > > the patches listed below.
> > >
> > > The user mode bonding scripts were unstable, and difficult to deliver
> > > & update for various distros. So Stephen developed the new "transparent"
> > > bonding mode, which greatly improves the situation.
> >
> > I specifically highlighted systemd-networkd as the change in the user
> > space landscape.
>
> Haiyang tried valiantly but getting every distro to do the right thing
> with VF's bonding and hot plug was impossible to support.
I understand, but I also don't want it to be an upstream Linux problem.
Again, no other cloud provider seems to have this issue, AFAIU.
^ permalink raw reply
* RE: [RFC PATCH V4 3/4] x86/hyperv: Don't use auto-eoi when Secure AVIC is available
From: Michael Kelley @ 2025-07-28 14:45 UTC (permalink / raw)
To: Tianyu Lan, kys@microsoft.com, haiyangz@microsoft.com,
wei.liu@kernel.org, decui@microsoft.com, tglx@linutronix.de,
mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
x86@kernel.org, hpa@zytor.com, arnd@arndb.de,
Neeraj.Upadhyay@amd.com
Cc: Tianyu Lan, linux-arch@vger.kernel.org,
linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20250726134250.4414-4-ltykernel@gmail.com>
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>
^ permalink raw reply
* RE: [RFC PATCH V4 2/4] drivers/hv: Allow vmbus message synic interrupt injected from Hyper-V
From: Michael Kelley @ 2025-07-28 14:44 UTC (permalink / raw)
To: Tianyu Lan, kys@microsoft.com, haiyangz@microsoft.com,
wei.liu@kernel.org, decui@microsoft.com, tglx@linutronix.de,
mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
x86@kernel.org, hpa@zytor.com, arnd@arndb.de,
Neeraj.Upadhyay@amd.com
Cc: Tianyu Lan, linux-arch@vger.kernel.org,
linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20250726134250.4414-3-ltykernel@gmail.com>
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
>
^ permalink raw reply
* RE: [RFC PATCH V4 1/4] x86/hyperv: Don't use hv apic driver when Secure AVIC is available
From: Michael Kelley @ 2025-07-28 14:43 UTC (permalink / raw)
To: Tianyu Lan, kys@microsoft.com, haiyangz@microsoft.com,
wei.liu@kernel.org, decui@microsoft.com, tglx@linutronix.de,
mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
x86@kernel.org, hpa@zytor.com, arnd@arndb.de,
Neeraj.Upadhyay@amd.com, kvijayab@amd.com
Cc: Tianyu Lan, linux-arch@vger.kernel.org,
linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20250726134250.4414-2-ltykernel@gmail.com>
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>
^ permalink raw reply
* Re: [PATCH RESEND] netvsc: transfer lower device max tso size
From: Stephen Hemminger @ 2025-07-28 3:01 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Haiyang Zhang, Jason Wang, Cindy Lu, KY Srinivasan, Wei Liu,
Dexuan Cui, Andrew Lunn, David S. Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, Michael Kelley, Shradha Gupta,
Kees Cook, Stanislav Fomichev, Kuniyuki Iwashima,
Alexander Lobakin, Guillaume Nault, Joe Damato, Ahmed Zaki,
open list:Hyper-V/Azure CORE AND DRIVERS,
open list:NETWORKING DRIVERS, open list
In-Reply-To: <20250723151622.0606cc99@kernel.org>
On Wed, 23 Jul 2025 15:16:22 -0700
Jakub Kicinski <kuba@kernel.org> wrote:
> On Wed, 23 Jul 2025 20:18:03 +0000 Haiyang Zhang wrote:
> > > > Btw, if I understand this correctly. This is for future development so
> > > > it's not a blocker for this patch?
> > >
> > > Not a blocker, I'm just giving an example of the netvsc auto-weirdness
> > > being a source of tech debt and bugs. Commit d7501e076d859d is another
> > > recent one off the top of my head. IIUC systemd-networkd is broadly
> > > deployed now. It'd be great if there was some migration plan for moving
> > > this sort of VM auto-bonding to user space (with the use of the common
> > > bonding driver, not each hypervisor rolling its own).
> >
> > Actually, we had used the common bonding driver 9 years ago. But it's
> > replaced by this kernel/netvsc based "transparent" bonding mode. See
> > the patches listed below.
> >
> > The user mode bonding scripts were unstable, and difficult to deliver
> > & update for various distros. So Stephen developed the new "transparent"
> > bonding mode, which greatly improves the situation.
>
> I specifically highlighted systemd-networkd as the change in the user
> space landscape.
Haiyang tried valiantly but getting every distro to do the right thing
with VF's bonding and hot plug was impossible to support.
^ permalink raw reply
* RE: [PATCH v6 2/2] Drivers: hv: Introduce mshv_vtl driver
From: Michael Kelley @ 2025-07-26 23:50 UTC (permalink / raw)
To: Naman Jain, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui
Cc: Roman Kisel, Anirudh Rayabharam, Saurabh Sengar,
Stanislav Kinsburskii, Nuno Das Neves, ALOK TIWARI,
Markus Elfring, linux-kernel@vger.kernel.org,
linux-hyperv@vger.kernel.org
In-Reply-To: <20250724082547.195235-3-namjain@linux.microsoft.com>
From: Naman Jain <namjain@linux.microsoft.com> Sent: Thursday, July 24, 2025 1:26 AM
>
> Provide an interface for Virtual Machine Monitor like OpenVMM and its
> use as OpenHCL paravisor to control VTL0 (Virtual trust Level).
> Expose devices and support IOCTLs for features like VTL creation,
> VTL0 memory management, context switch, making hypercalls,
> mapping VTL0 address space to VTL2 userspace, getting new VMBus
> messages and channel events in VTL2 etc.
>
> Co-developed-by: Roman Kisel <romank@linux.microsoft.com>
> Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
> Co-developed-by: Saurabh Sengar <ssengar@linux.microsoft.com>
> Signed-off-by: Saurabh Sengar <ssengar@linux.microsoft.com>
> Reviewed-by: Roman Kisel <romank@linux.microsoft.com>
> Reviewed-by: Alok Tiwari <alok.a.tiwari@oracle.com>
> Message-ID: <20250512140432.2387503-3-namjain@linux.microsoft.com>
> Reviewed-by: Saurabh Sengar <ssengar@linux.microsoft.com>
> Reviewed-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
> Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
> ---
> drivers/hv/Kconfig | 22 +
> drivers/hv/Makefile | 7 +-
> drivers/hv/mshv_vtl.h | 52 ++
> drivers/hv/mshv_vtl_main.c | 1508 +++++++++++++++++++++++++++++++++++
> include/hyperv/hvgdk_mini.h | 106 +++
> include/uapi/linux/mshv.h | 80 ++
> 6 files changed, 1774 insertions(+), 1 deletion(-)
> create mode 100644 drivers/hv/mshv_vtl.h
> create mode 100644 drivers/hv/mshv_vtl_main.c
>
[snip]
> +
> +static int mshv_vtl_set_reg(struct hv_register_assoc *regs)
> +{
> + u64 reg64;
> + enum hv_register_name gpr_name;
> + int i;
> +
> + gpr_name = regs->name;
> + reg64 = regs->value.reg64;
> +
> + /* Search for the register in the table */
> + for (i = 0; i < ARRAY_SIZE(reg_table); i++) {
> + if (reg_table[i].reg_name == gpr_name) {
> + if (reg_table[i].debug_reg_num != -1) {
> + /* Handle debug registers */
> + if (gpr_name == HV_X64_REGISTER_DR6 &&
> + !mshv_vsm_capabilities.dr6_shared)
> + goto hypercall;
> + native_set_debugreg(reg_table[i].debug_reg_num, reg64);
> + } else {
> + /* Handle MSRs */
> + wrmsrl(reg_table[i].msr_addr, reg64);
> + }
> + return 0;
> + }
> + }
> +
> +hypercall:
> + return 1;
> +}
> +
> +static int mshv_vtl_get_reg(struct hv_register_assoc *regs)
> +{
> + u64 *reg64;
> + enum hv_register_name gpr_name;
> + int i;
> +
> + gpr_name = regs->name;
> + reg64 = (u64 *)®s->value.reg64;
> +
> + /* Search for the register in the table */
> + for (i = 0; i < ARRAY_SIZE(reg_table); i++) {
> + if (reg_table[i].reg_name == gpr_name) {
> + if (reg_table[i].debug_reg_num != -1) {
> + /* Handle debug registers */
> + if (gpr_name == HV_X64_REGISTER_DR6 &&
> + !mshv_vsm_capabilities.dr6_shared)
> + goto hypercall;
> + *reg64 = native_get_debugreg(reg_table[i].debug_reg_num);
> + } else {
> + /* Handle MSRs */
> + rdmsrl(reg_table[i].msr_addr, *reg64);
> + }
> + return 0;
> + }
> + }
> +
> +hypercall:
> + return 1;
> +}
> +
One more comment on this patch. What do you think about
combining mshv_vtl_set_reg() and mshv_vtl_get_reg() into a single
function? The two functions have a lot code duplication that could be
avoided. Here's my untested version (not even compile tested):
+static int mshv_vtl_get_set_reg(struct hv_register_assoc *regs, bool set)
+{
+ u64 *reg64;
+ enum hv_register_name gpr_name;
+ int i;
+
+ gpr_name = regs->name;
+ reg64 = ®s->value.reg64;
+
+ /* Search for the register in the table */
+ for (i = 0; i < ARRAY_SIZE(reg_table); i++) {
+ if (reg_table[i].reg_name != gpr_name)
+ continue;
+ if (reg_table[i].debug_reg_num != -1) {
+ /* Handle debug registers */
+ if (gpr_name == HV_X64_REGISTER_DR6 &&
+ !mshv_vsm_capabilities.dr6_shared)
+ goto hypercall;
+ if (set)
+ native_set_debugreg(reg_table[i].debug_reg_num, *reg64);
+ else
+ *reg64 = native_get_debugreg(reg_table[i].debug_reg_num);
+ } else {
+ /* Handle MSRs */
+ if (set)
+ wrmsrl(reg_table[i].msr_addr, *reg64);
+ else
+ rdmsrl(reg_table[i].msr_addr, *reg64);
+ }
+ return 0;
+ }
+
+hypercall:
+ return 1;
+}
+
Two call sites would need to be updated to pass "true" and "false",
respectively, for the "set" parameter.
I changed the gpr_name matching to do "continue" on a mismatch
just to avoid a level of indentation. It's functionally the same as your
code.
Michael
^ permalink raw reply
* [RFC PATCH V4 4/4] x86/hyperv: Allow Hyper-V to inject STIMER0 interrupts
From: Tianyu Lan @ 2025-07-26 13:42 UTC (permalink / raw)
To: kys, haiyangz, wei.liu, decui, tglx, mingo, bp, dave.hansen, x86,
hpa, arnd, Neeraj.Upadhyay, kvijayab
Cc: Tianyu Lan, linux-arch, linux-hyperv, linux-kernel,
Michael Kelley
In-Reply-To: <20250726134250.4414-1-ltykernel@gmail.com>
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
^ permalink raw reply related
* [RFC PATCH V4 3/4] x86/hyperv: Don't use auto-eoi when Secure AVIC is available
From: Tianyu Lan @ 2025-07-26 13:42 UTC (permalink / raw)
To: kys, haiyangz, wei.liu, decui, tglx, mingo, bp, dave.hansen, x86,
hpa, arnd, Neeraj.Upadhyay, kvijayab
Cc: Tianyu Lan, linux-arch, linux-hyperv, linux-kernel
In-Reply-To: <20250726134250.4414-1-ltykernel@gmail.com>
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
^ permalink raw reply related
* [RFC PATCH V4 2/4] drivers/hv: Allow vmbus message synic interrupt injected from Hyper-V
From: Tianyu Lan @ 2025-07-26 13:42 UTC (permalink / raw)
To: kys, haiyangz, wei.liu, decui, tglx, mingo, bp, dave.hansen, x86,
hpa, arnd, Neeraj.Upadhyay, kvijayab
Cc: Tianyu Lan, linux-arch, linux-hyperv, linux-kernel
In-Reply-To: <20250726134250.4414-1-ltykernel@gmail.com>
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
^ permalink raw reply related
* [RFC PATCH V4 1/4] x86/hyperv: Don't use hv apic driver when Secure AVIC is available
From: Tianyu Lan @ 2025-07-26 13:42 UTC (permalink / raw)
To: kys, haiyangz, wei.liu, decui, tglx, mingo, bp, dave.hansen, x86,
hpa, arnd, Neeraj.Upadhyay, kvijayab
Cc: Tianyu Lan, linux-arch, linux-hyperv, linux-kernel
In-Reply-To: <20250726134250.4414-1-ltykernel@gmail.com>
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
^ permalink raw reply related
* [RFC PATCH V4 0/4] x86/Hyper-V: Add AMD Secure AVIC for Hyper-V platform
From: Tianyu Lan @ 2025-07-26 13:42 UTC (permalink / raw)
To: kys, haiyangz, wei.liu, decui, tglx, mingo, bp, dave.hansen, x86,
hpa, arnd, Neeraj.Upadhyay, kvijayab
Cc: Tianyu Lan, linux-arch, linux-hyperv, linux-kernel
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
^ permalink raw reply
* Re: [RFC PATCH net-next v6 00/14] virtio/vsock: support datagrams
From: Amery Hung @ 2025-07-26 5:53 UTC (permalink / raw)
To: Stefano Garzarella
Cc: stefanha, mst, jasowang, xuanzhuo, davem, edumazet, kuba, pabeni,
kys, haiyangz, wei.liu, decui, bryantan, vdasa, pv-drivers,
dan.carpenter, simon.horman, oxffffaa, kvm, virtualization,
netdev, linux-kernel, linux-hyperv, bpf, bobby.eshleman,
jiang.wang, amery.hung, xiyou.wangcong
In-Reply-To: <dsamf7k2byoflztkwya3smj7jyczyq7aludvd36lufdrboxdqk@u73iwrcyb5am>
On Tue, Jul 22, 2025 at 7:35 AM Stefano Garzarella <sgarzare@redhat.com> wrote:
>
> Hi Amery,
>
> On Wed, Jul 10, 2024 at 09:25:41PM +0000, Amery Hung wrote:
> >Hey all!
> >
> >This series introduces support for datagrams to virtio/vsock.
>
> any update on v7 of this series?
>
Hi Stefano,
Sorry that I don't have personal time to work on v7. Since I don't
think people involved in this set are still working on it, I am
posting my v7 WIP here to see if anyone is interested in finishing it.
Would greatly appreciate any help.
Link: https://github.com/ameryhung/linux/tree/vsock-dgram-v7
Here are the things that I haven't address in the WIP:
01/14
- Arseniy suggested doing skb_put(dg->payload_size) and memcpy(dg->payload_size)
07/14
- Remove the double transport lookup in the send path by passing
transport to dgram_enqueue
- Address Arseniy's comment about updating vsock_virtio_transport_common.h
14/14
- Split test/vsock into smaller patches
Finally the spec change discussion also needs to happen.
> Thanks,
> Stefano
>
> >
> >It is a spin-off (and smaller version) of this series from the summer:
> > https://lore.kernel.org/all/cover.1660362668.git.bobby.eshleman@bytedance.com/
> >
> >Please note that this is an RFC and should not be merged until
> >associated changes are made to the virtio specification, which will
> >follow after discussion from this series.
> >
> >Another aside, the v4 of the series has only been mildly tested with a
> >run of tools/testing/vsock/vsock_test. Some code likely needs cleaning
> >up, but I'm hoping to get some of the design choices agreed upon before
> >spending too much time making it pretty.
> >
> >This series first supports datagrams in a basic form for virtio, and
> >then optimizes the sendpath for all datagram transports.
> >
> >The result is a very fast datagram communication protocol that
> >outperforms even UDP on multi-queue virtio-net w/ vhost on a variety
> >of multi-threaded workload samples.
> >
> >For those that are curious, some summary data comparing UDP and VSOCK
> >DGRAM (N=5):
> >
> > vCPUS: 16
> > virtio-net queues: 16
> > payload size: 4KB
> > Setup: bare metal + vm (non-nested)
> >
> > UDP: 287.59 MB/s
> > VSOCK DGRAM: 509.2 MB/s
> >
> >Some notes about the implementation...
> >
> >This datagram implementation forces datagrams to self-throttle according
> >to the threshold set by sk_sndbuf. It behaves similar to the credits
> >used by streams in its effect on throughput and memory consumption, but
> >it is not influenced by the receiving socket as credits are.
> >
> >The device drops packets silently.
> >
> >As discussed previously, this series introduces datagrams and defers
> >fairness to future work. See discussion in v2 for more context around
> >datagrams, fairness, and this implementation.
> >
> >Signed-off-by: Bobby Eshleman <bobby.eshleman@bytedance.com>
> >Signed-off-by: Amery Hung <amery.hung@bytedance.com>
> >---
> >Changes in v6:
> >- allow empty transport in datagram vsock
> >- add empty transport checks in various paths
> >- transport layer now saves source cid and port to control buffer of skb
> > to remove the dependency of transport in recvmsg()
> >- fix virtio dgram_enqueue() by looking up the transport to be used when
> > using sendto(2)
> >- fix skb memory leaks in two places
> >- add dgram auto-bind test
> >- Link to v5: https://lore.kernel.org/r/20230413-b4-vsock-dgram-v5-0-581bd37fdb26@bytedance.com
> >
> >Changes in v5:
> >- teach vhost to drop dgram when a datagram exceeds the receive buffer
> > - now uses MSG_ERRQUEUE and depends on Arseniy's zerocopy patch:
> > "vsock: read from socket's error queue"
> >- replace multiple ->dgram_* callbacks with single ->dgram_addr_init()
> > callback
> >- refactor virtio dgram skb allocator to reduce conflicts w/ zerocopy series
> >- add _fallback/_FALLBACK suffix to dgram transport variables/macros
> >- add WARN_ONCE() for table_size / VSOCK_HASH issue
> >- add static to vsock_find_bound_socket_common
> >- dedupe code in vsock_dgram_sendmsg() using module_got var
> >- drop concurrent sendmsg() for dgram and defer to future series
> >- Add more tests
> > - test EHOSTUNREACH in errqueue
> > - test stream + dgram address collision
> >- improve clarity of dgram msg bounds test code
> >- Link to v4: https://lore.kernel.org/r/20230413-b4-vsock-dgram-v4-0-0cebbb2ae899@bytedance.com
> >
> >Changes in v4:
> >- style changes
> > - vsock: use sk_vsock(vsk) in vsock_dgram_recvmsg instead of
> > &sk->vsk
> > - vsock: fix xmas tree declaration
> > - vsock: fix spacing issues
> > - virtio/vsock: virtio_transport_recv_dgram returns void because err
> > unused
> >- sparse analysis warnings/errors
> > - virtio/vsock: fix unitialized skerr on destroy
> > - virtio/vsock: fix uninitialized err var on goto out
> > - vsock: fix declarations that need static
> > - vsock: fix __rcu annotation order
> >- bugs
> > - vsock: fix null ptr in remote_info code
> > - vsock/dgram: make transport_dgram a fallback instead of first
> > priority
> > - vsock: remove redundant rcu read lock acquire in getname()
> >- tests
> > - add more tests (message bounds and more)
> > - add vsock_dgram_bind() helper
> > - add vsock_dgram_connect() helper
> >
> >Changes in v3:
> >- Support multi-transport dgram, changing logic in connect/bind
> > to support VMCI case
> >- Support per-pkt transport lookup for sendto() case
> >- Fix dgram_allow() implementation
> >- Fix dgram feature bit number (now it is 3)
> >- Fix binding so dgram and connectible (cid,port) spaces are
> > non-overlapping
> >- RCU protect transport ptr so connect() calls never leave
> > a lockless read of the transport and remote_addr are always
> > in sync
> >- Link to v2: https://lore.kernel.org/r/20230413-b4-vsock-dgram-v2-0-079cc7cee62e@bytedance.com
> >
> >
> >Bobby Eshleman (14):
> > af_vsock: generalize vsock_dgram_recvmsg() to all transports
> > af_vsock: refactor transport lookup code
> > af_vsock: support multi-transport datagrams
> > af_vsock: generalize bind table functions
> > af_vsock: use a separate dgram bind table
> > virtio/vsock: add VIRTIO_VSOCK_TYPE_DGRAM
> > virtio/vsock: add common datagram send path
> > af_vsock: add vsock_find_bound_dgram_socket()
> > virtio/vsock: add common datagram recv path
> > virtio/vsock: add VIRTIO_VSOCK_F_DGRAM feature bit
> > vhost/vsock: implement datagram support
> > vsock/loopback: implement datagram support
> > virtio/vsock: implement datagram support
> > test/vsock: add vsock dgram tests
> >
> > drivers/vhost/vsock.c | 62 +-
> > include/linux/virtio_vsock.h | 9 +-
> > include/net/af_vsock.h | 24 +-
> > include/uapi/linux/virtio_vsock.h | 2 +
> > net/vmw_vsock/af_vsock.c | 343 ++++++--
> > net/vmw_vsock/hyperv_transport.c | 13 -
> > net/vmw_vsock/virtio_transport.c | 24 +-
> > net/vmw_vsock/virtio_transport_common.c | 188 ++++-
> > net/vmw_vsock/vmci_transport.c | 61 +-
> > net/vmw_vsock/vsock_loopback.c | 9 +-
> > tools/testing/vsock/util.c | 177 +++-
> > tools/testing/vsock/util.h | 10 +
> > tools/testing/vsock/vsock_test.c | 1032 ++++++++++++++++++++---
> > 13 files changed, 1638 insertions(+), 316 deletions(-)
> >
> >--
> >2.20.1
> >
>
^ permalink raw reply
* Re: [PATCH v3 14/16] x86/fred: Play nice with invoking asm_fred_entry_from_kvm() on non-FRED hardware
From: Xin Li @ 2025-07-26 4:54 UTC (permalink / raw)
To: Peter Zijlstra, x86
Cc: kys, haiyangz, wei.liu, decui, tglx, mingo, bp, dave.hansen, hpa,
seanjc, pbonzini, ardb, kees, Arnd Bergmann, gregkh, jpoimboe,
linux-hyperv, linux-kernel, kvm, linux-efi, samitolvanen, ojeda
In-Reply-To: <20250714103441.245417052@infradead.org>
On 7/14/2025 3:20 AM, Peter Zijlstra wrote:
> call __fred_entry_from_kvm /* Call the C entry point */
> - POP_REGS
> - ERETS
> -1:
> +
> +1: /*
The symbol "1" is misplaced; it needs to be put after the ERETS
instruction.
> + * When FRED, use ERETS to potentially clear NMIs, otherwise simply
> + * restore the stack pointer.
> + */
> + ALTERNATIVE "nop; nop; mov %rbp, %rsp", \
Why explicitly add two nops here?
ALTERNATIVE will still pad three-byte nop after the MOV instruction.
> + __stringify(add $C_PTREGS_SIZE, %rsp; ERETS), \
> + X86_FEATURE_FRED
> +
> /*
> - * Objtool doesn't understand what ERETS does, this hint tells it that
> - * yes, we'll reach here and with what stack state. A save/restore pair
> - * isn't strictly needed, but it's the simplest form.
> + * Objtool doesn't understand ERETS, and the cfi register state is
> + * different from initial_func_cfi due to PUSH_REGS. Tell it the state
> + * is similar to where UNWIND_HINT_SAVE is.
> */
> UNWIND_HINT_RESTORE
> +
> pop %rbp
> RET
>
^ permalink raw reply
* Re: [PATCH v2] net: mana: Use page pool fragments for RX buffers instead of full pages to improve memory efficiency.
From: Jakub Kicinski @ 2025-07-26 0:54 UTC (permalink / raw)
To: Dipayaan Roy
Cc: horms, kys, haiyangz, wei.liu, decui, andrew+netdev, davem,
edumazet, pabeni, longli, kotaranov, ast, daniel, hawk,
john.fastabend, sdf, lorenzo, michal.kubiak, ernis, shradhagupta,
shirazsaleem, rosenp, netdev, linux-hyperv, linux-rdma, bpf,
linux-kernel, ssengar, dipayanroy
In-Reply-To: <20250723190706.GA5291@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
On Wed, 23 Jul 2025 12:07:06 -0700 Dipayaan Roy wrote:
> This patch enhances RX buffer handling in the mana driver by allocating
> pages from a page pool and slicing them into MTU-sized fragments, rather
> than dedicating a full page per packet. This approach is especially
> beneficial on systems with large page sizes like 64KB.
>
> Key improvements:
>
> - Proper integration of page pool for RX buffer allocations.
> - MTU-sized buffer slicing to improve memory utilization.
> - Reduce overall per Rx queue memory footprint.
> - Automatic fallback to full-page buffers when:
> * Jumbo frames are enabled (MTU > PAGE_SIZE / 2).
> * The XDP path is active, to avoid complexities with fragment reuse.
> - Removal of redundant pre-allocated RX buffers used in scenarios like MTU
> changes, ensuring consistency in RX buffer allocation.
>
> Testing on VMs with 64KB pages shows around 200% throughput improvement.
> Memory efficiency is significantly improved due to reduced wastage in page
> allocations. Example: We are now able to fit 35 rx buffers in a single 64kb
> page for MTU size of 1500, instead of 1 rx buffer per page previously.
The diff is pretty large and messy, please try to extract some
refactoring patches that make the final transition easier to review.
> - iperf3, iperf2, and nttcp benchmarks.
> - Jumbo frames with MTU 9000.
> - Native XDP programs (XDP_PASS, XDP_DROP, XDP_TX, XDP_REDIRECT) for
> testing the XDP path in driver.
> - Page leak detection (kmemleak).
kmemleak doesn't detect page leaks AFAIU, just slab objects
> - Driver load/unload, reboot, and stress scenarios.
>
> Signed-off-by: Dipayaan Roy <dipayanroy@linux.microsoft.com>
>
> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
> Reviewed-by: Saurabh Sengar <ssengar@linux.microsoft.com>
> - if (apc->port_is_up)
> + if (apc->port_is_up) {
> + /* Re-create rxq's after xdp prog was loaded or unloaded.
> + * Ex: re create rxq's to switch from full pages to smaller
> + * size page fragments when xdp prog is unloaded and vice-versa.
> + */
> +
> + err = mana_detach(ndev, false);
> + if (err) {
> + netdev_err(ndev, "mana_detach failed at xdp set: %d\n", err);
> + goto out;
> + }
> +
> + err = mana_attach(ndev);
> + if (err) {
> + netdev_err(ndev, "mana_attach failed at xdp set: %d\n", err);
> + goto out;
> + }
If the system is low on memory you will make it unreachable.
It's a very poor design.
> -/* Release pre-allocated RX buffers */
> -void mana_pre_dealloc_rxbufs(struct mana_port_context *mpc)
> -{
> - struct device *dev;
> - int i;
> -
Looks like you're deleting the infrastructure the driver had for
pre-allocating memory. Not even mentioning it in the commit message.
This ability needs to be maintain. Please test with memory allocation
injections and make sure the driver survives failed reconfig requests.
The reconfiguration should be cleanly rejected if mem alloc fails,
and the driver should continue to work with old settings in place.
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH v3 16/16] objtool: Validate kCFI calls
From: Xin Li @ 2025-07-26 0:33 UTC (permalink / raw)
To: Sean Christopherson
Cc: Peter Zijlstra, x86, kys, haiyangz, wei.liu, decui, tglx, mingo,
bp, dave.hansen, hpa, pbonzini, ardb, kees, Arnd Bergmann, gregkh,
jpoimboe, linux-hyperv, linux-kernel, kvm, linux-efi,
samitolvanen, ojeda
In-Reply-To: <aIPhfNxjTL4LiG6Z@google.com>
On 7/25/2025 12:56 PM, Sean Christopherson wrote:
>>
>> BTW, there is a declaration for vmx_do_interrupt_irqoff() in
>> arch/x86/kvm/vmx/vmx.c, so we'd better also do:
>>
>> --- a/arch/x86/kvm/vmx/vmx.c
>> +++ b/arch/x86/kvm/vmx/vmx.c
>> @@ -6945,7 +6945,9 @@ void vmx_load_eoi_exitmap(struct kvm_vcpu *vcpu, u64
>> *eoi_exit_bitmap)
>> vmcs_write64(EOI_EXIT_BITMAP3, eoi_exit_bitmap[3]);
>> }
>>
>> +#ifndef CONFIG_X86_FRED
>> void vmx_do_interrupt_irqoff(unsigned long entry);
>> +#endif
> No, we want to keep the declaration. Unconditionally decaring the symbol allows
> KVM to use IS_ENABLED():
>
> if (IS_ENABLED(CONFIG_X86_FRED))
> fred_entry_from_kvm(EVENT_TYPE_EXTINT, vector);
>
> Hiding the declaration would require that to be a "proper" #ifdef, which would
> be a net negative for readability. The extra declaration won't hurt anything for
> CONFIG_X86_FRED=n, as "bad" usage will still fail at link time.
I did hit a compilation error, so yes, we have to keep it.
^ permalink raw reply
* Re: [RFC PATCH V3 2/4] Drivers: hv: Allow vmbus message synic interrupt injected from Hyper-V
From: Tianyu Lan @ 2025-07-25 20:06 UTC (permalink / raw)
To: Michael Kelley
Cc: kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org,
decui@microsoft.com, tglx@linutronix.de, mingo@redhat.com,
bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org,
hpa@zytor.com, arnd@arndb.de, Neeraj.Upadhyay@amd.com, Tianyu Lan,
linux-arch@vger.kernel.org, linux-hyperv@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <SN6PR02MB4157A59A59B24DB51EAA1ECFD45EA@SN6PR02MB4157.namprd02.prod.outlook.com>
On Fri, Jul 25, 2025 at 7:34 AM Michael Kelley <mhklinux@outlook.com> wrote:
>
> From: Tianyu Lan <ltykernel@gmail.com> Sent: Wednesday, July 23, 2025 12:03 PM
> >
> > 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 v3
> > - Add hv_enable_coco_interrupt() as wrapper
> > of apic_update_vector()
> >
> > 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 1c48396e5389..dd6829440ea2 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..2aafe8946e5b 100644
> > --- a/drivers/hv/hv.c
> > +++ b/drivers/hv/hv.c
> > @@ -20,6 +20,7 @@
> > #include <linux/interrupt.h>
> > #include <clocksource/hyperv_timer.h>
> > #include <asm/mshyperv.h>
> > +#include <asm/apic.h>
>
> This #include is no longer needed since apic_update_vector()
> isn't being called directly. And the file doesn't exist on arm64,
> so it would create a compile error on arm64.
>
> Before submitting, I always do a test compile on arm64 with
> my patches so that errors like this are caught beforehand! :-)
Yes, good suggestion and will add compilation test on ARM64.
before sending out. Thanks.
>
> > #include <linux/set_memory.h>
> > #include "hyperv_vmbus.h"
> >
> > @@ -310,6 +311,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);
>
> In the "RFC Patch v2" version of this patch, I had asked about whether
> the interrupt should be disabled in hv_synic_disable_regs(), so there is
> symmetry. [1] I see that in Patch 4 of this series, you are disabling the
> STIMER0 interrupt when a CPU goes offline. If disabling vmbus_interrupt
> causes a problem, I'm curious about the details.
>
Yes, that makes sense and will add it.
>
> >
> > shared_sint.vector = vmbus_interrupt;
> > shared_sint.masked = false;
> > 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
> >
>
--
Thanks
Tianyu Lan
^ permalink raw reply
* Re: [RFC PATCH V3 1/4] x86/Hyper-V: Not use hv apic driver when Secure AVIC is available
From: Tianyu Lan @ 2025-07-25 20:00 UTC (permalink / raw)
To: Michael Kelley
Cc: kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org,
decui@microsoft.com, tglx@linutronix.de, mingo@redhat.com,
bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org,
hpa@zytor.com, arnd@arndb.de, Neeraj.Upadhyay@amd.com,
kvijayab@amd.com, Tianyu Lan, linux-arch@vger.kernel.org,
linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <SN6PR02MB41570FB8F17994FC7DB369E5D45EA@SN6PR02MB4157.namprd02.prod.outlook.com>
On Fri, Jul 25, 2025 at 7:33 AM Michael Kelley <mhklinux@outlook.com> wrote:
>
> From: Tianyu Lan <ltykernel@gmail.com> Sent: Wednesday, July 23, 2025 12:03 PM
> >
> > When Secure AVIC is available, AMD x2apic Secure
> > AVIC driver should be selected and return directly
> > in the hv_apic_init().
>
> For the "RFC Patch v2" version of this patch, I had provided some comments
> on the wording for the patch "Subject:" and for the commit message. [1] It
> doesn't look like those comments were picked up. The comments
> improve the use of English without changing any substantive information,
> so I think they should be adopted.
>
> [1] https://lore.kernel.org/linux-hyperv/CAMvTesAscN2MyqJXpcbwcXWC-6-en6U_c03M+2=zcMF0bLv4iw@mail.gmail.com/T/#m893e8cac0314e73ee4626d736c623e640b46ef5d
>
Thanks for the reminder. Will update in the next version.
Thanks.
^ permalink raw reply
* Re: [RFC PATCH V3 3/4] x86/Hyper-V: Don't use auto-eoi when Secure AVIC is available
From: Tianyu Lan @ 2025-07-25 19:58 UTC (permalink / raw)
To: Michael Kelley
Cc: kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org,
decui@microsoft.com, tglx@linutronix.de, mingo@redhat.com,
bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org,
hpa@zytor.com, arnd@arndb.de, Neeraj.Upadhyay@amd.com, Tianyu Lan,
linux-arch@vger.kernel.org, linux-hyperv@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <SN6PR02MB4157FC3B69C9E6FB6884CE99D45EA@SN6PR02MB4157.namprd02.prod.outlook.com>
On Fri, Jul 25, 2025 at 7:34 AM Michael Kelley <mhklinux@outlook.com> wrote:
>
> From: Tianyu Lan <ltykernel@gmail.com> Sent: Wednesday, July 23, 2025 12:03 PM
> >
>
> I'm nit-picking, but the patch Subject: line prefix should be "x86/hyperv:"
> for consistency with past patches. Note that there's no capitalization
> or dash. I know not everyone is consistent on this if you look at the git log
> for mshyperv.c, but I try to flag it and encourage consistency.
>
> > Hyper-V doesn't support auto-eoi with Secure AVIC.
> > So set the HV_DEPRECATING_AEOI_RECOMMENDED flag
> > to force writing the EIO register after handling an interrupt.
> >
> > Signed-off-by: Tianyu Lan <tiala@microsoft.com>
> > ---
> > 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
> >
>
Hi Michael:
Thanks for your review. Will update.
--
Thanks
Tianyu Lan
^ permalink raw reply
* Re: [PATCH v3 16/16] objtool: Validate kCFI calls
From: Sean Christopherson @ 2025-07-25 19:56 UTC (permalink / raw)
To: Xin Li
Cc: Peter Zijlstra, x86, kys, haiyangz, wei.liu, decui, tglx, mingo,
bp, dave.hansen, hpa, pbonzini, ardb, kees, Arnd Bergmann, gregkh,
jpoimboe, linux-hyperv, linux-kernel, kvm, linux-efi,
samitolvanen, ojeda
In-Reply-To: <1584052d-4d8c-4b4e-b65b-318296d47636@zytor.com>
On Fri, Jul 25, 2025, Xin Li wrote:
> On 7/24/2025 1:37 PM, Sean Christopherson wrote:
> > On Mon, Jul 14, 2025, Peter Zijlstra wrote:
> > > --- a/arch/x86/kvm/vmx/vmenter.S
> > > +++ b/arch/x86/kvm/vmx/vmenter.S
> > > @@ -361,6 +361,10 @@ SYM_FUNC_END(vmread_error_trampoline)
> > > .section .text, "ax"
> > > +#ifndef CONFIG_X86_FRED
> > > +
> > > SYM_FUNC_START(vmx_do_interrupt_irqoff)
> > > VMX_DO_EVENT_IRQOFF CALL_NOSPEC _ASM_ARG1
> > > SYM_FUNC_END(vmx_do_interrupt_irqoff)
> > > +
> > > +#endif
> >
> > This can go in the previous patch, "x86/fred: KVM: VMX: Always use FRED for IRQs
> > when CONFIG_X86_FRED=y".
> >
>
> I'm going to test patch 13~15, plus this change in patch 16.
>
> BTW, there is a declaration for vmx_do_interrupt_irqoff() in
> arch/x86/kvm/vmx/vmx.c, so we'd better also do:
>
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -6945,7 +6945,9 @@ void vmx_load_eoi_exitmap(struct kvm_vcpu *vcpu, u64
> *eoi_exit_bitmap)
> vmcs_write64(EOI_EXIT_BITMAP3, eoi_exit_bitmap[3]);
> }
>
> +#ifndef CONFIG_X86_FRED
> void vmx_do_interrupt_irqoff(unsigned long entry);
> +#endif
No, we want to keep the declaration. Unconditionally decaring the symbol allows
KVM to use IS_ENABLED():
if (IS_ENABLED(CONFIG_X86_FRED))
fred_entry_from_kvm(EVENT_TYPE_EXTINT, vector);
Hiding the declaration would require that to be a "proper" #ifdef, which would
be a net negative for readability. The extra declaration won't hurt anything for
CONFIG_X86_FRED=n, as "bad" usage will still fail at link time.
> void vmx_do_nmi_irqoff(void);
>
> static void handle_nm_fault_irqoff(struct kvm_vcpu *vcpu)
^ permalink raw reply
* Re: [PATCH v3 16/16] objtool: Validate kCFI calls
From: Xin Li @ 2025-07-25 17:57 UTC (permalink / raw)
To: Sean Christopherson, Peter Zijlstra
Cc: x86, kys, haiyangz, wei.liu, decui, tglx, mingo, bp, dave.hansen,
hpa, pbonzini, ardb, kees, Arnd Bergmann, gregkh, jpoimboe,
linux-hyperv, linux-kernel, kvm, linux-efi, samitolvanen, ojeda
In-Reply-To: <aIKZnSuTXn9thrf7@google.com>
On 7/24/2025 1:37 PM, Sean Christopherson wrote:
> On Mon, Jul 14, 2025, Peter Zijlstra wrote:
>> --- a/arch/x86/kvm/vmx/vmenter.S
>> +++ b/arch/x86/kvm/vmx/vmenter.S
>> @@ -361,6 +361,10 @@ SYM_FUNC_END(vmread_error_trampoline)
>>
>> .section .text, "ax"
>>
>> +#ifndef CONFIG_X86_FRED
>> +
>> SYM_FUNC_START(vmx_do_interrupt_irqoff)
>> VMX_DO_EVENT_IRQOFF CALL_NOSPEC _ASM_ARG1
>> SYM_FUNC_END(vmx_do_interrupt_irqoff)
>> +
>> +#endif
>
> This can go in the previous patch, "x86/fred: KVM: VMX: Always use FRED for IRQs
> when CONFIG_X86_FRED=y".
>
I'm going to test patch 13~15, plus this change in patch 16.
BTW, there is a declaration for vmx_do_interrupt_irqoff() in
arch/x86/kvm/vmx/vmx.c, so we'd better also do:
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -6945,7 +6945,9 @@ void vmx_load_eoi_exitmap(struct kvm_vcpu *vcpu,
u64 *eoi_exit_bitmap)
vmcs_write64(EOI_EXIT_BITMAP3, eoi_exit_bitmap[3]);
}
+#ifndef CONFIG_X86_FRED
void vmx_do_interrupt_irqoff(unsigned long entry);
+#endif
void vmx_do_nmi_irqoff(void);
static void handle_nm_fault_irqoff(struct kvm_vcpu *vcpu)
^ permalink raw reply
* Re: [PATCH hyperv-next v4 12/16] Drivers: hv: Allocate encrypted buffers when requested
From: Tianyu Lan @ 2025-07-25 14:40 UTC (permalink / raw)
To: Roman Kisel
Cc: alok.a.tiwari, arnd, bp, corbet, dave.hansen, decui, haiyangz,
hpa, kys, mhklinux, mingo, rdunlap, tglx, Tianyu.Lan, wei.liu,
linux-arch, linux-coco, linux-doc, linux-hyperv, linux-kernel,
x86, apais, benhill, bperkins, sunilmut
In-Reply-To: <20250714221545.5615-13-romank@linux.microsoft.com>
On Tue, Jul 15, 2025 at 6:28 AM Roman Kisel <romank@linux.microsoft.com> wrote:
>
> Confidential VMBus is built around using buffers not shared with
> the host.
>
> Support allocating encrypted buffers when requested.
>
> Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
> ---
Reviewed-by: Tianyu Lan <tiala@microsoft.com>
> drivers/hv/channel.c | 49 +++++++++++++++++++++++----------------
> drivers/hv/hyperv_vmbus.h | 3 ++-
> drivers/hv/ring_buffer.c | 5 ++--
> 3 files changed, 34 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
> index 35f26fa1ffe7..051eeba800f2 100644
> --- a/drivers/hv/channel.c
> +++ b/drivers/hv/channel.c
> @@ -443,20 +443,23 @@ static int __vmbus_establish_gpadl(struct vmbus_channel *channel,
> return ret;
> }
>
> - /*
> - * Set the "decrypted" flag to true for the set_memory_decrypted()
> - * success case. In the failure case, the encryption state of the
> - * memory is unknown. Leave "decrypted" as true to ensure the
> - * memory will be leaked instead of going back on the free list.
> - */
> - gpadl->decrypted = true;
> - ret = set_memory_decrypted((unsigned long)kbuffer,
> - PFN_UP(size));
> - if (ret) {
> - dev_warn(&channel->device_obj->device,
> - "Failed to set host visibility for new GPADL %d.\n",
> - ret);
> - return ret;
> + gpadl->decrypted = !((channel->co_external_memory && type == HV_GPADL_BUFFER) ||
> + (channel->co_ring_buffer && type == HV_GPADL_RING));
> + if (gpadl->decrypted) {
> + /*
> + * The "decrypted" flag being true assumes that set_memory_decrypted() succeeds.
> + * But if it fails, the encryption state of the memory is unknown. In that case,
> + * leave "decrypted" as true to ensure the memory is leaked instead of going back
> + * on the free list.
> + */
> + ret = set_memory_decrypted((unsigned long)kbuffer,
> + PFN_UP(size));
> + if (ret) {
> + dev_warn(&channel->device_obj->device,
> + "Failed to set host visibility for new GPADL %d.\n",
> + ret);
> + return ret;
> + }
> }
>
> init_completion(&msginfo->waitevent);
> @@ -544,8 +547,10 @@ static int __vmbus_establish_gpadl(struct vmbus_channel *channel,
> * left as true so the memory is leaked instead of being
> * put back on the free list.
> */
> - if (!set_memory_encrypted((unsigned long)kbuffer, PFN_UP(size)))
> - gpadl->decrypted = false;
> + if (gpadl->decrypted) {
> + if (!set_memory_encrypted((unsigned long)kbuffer, PFN_UP(size)))
> + gpadl->decrypted = false;
> + }
> }
>
> return ret;
> @@ -676,12 +681,13 @@ static int __vmbus_open(struct vmbus_channel *newchannel,
> goto error_clean_ring;
>
> err = hv_ringbuffer_init(&newchannel->outbound,
> - page, send_pages, 0);
> + page, send_pages, 0, newchannel->co_ring_buffer);
> if (err)
> goto error_free_gpadl;
>
> err = hv_ringbuffer_init(&newchannel->inbound, &page[send_pages],
> - recv_pages, newchannel->max_pkt_size);
> + recv_pages, newchannel->max_pkt_size,
> + newchannel->co_ring_buffer);
> if (err)
> goto error_free_gpadl;
>
> @@ -862,8 +868,11 @@ int vmbus_teardown_gpadl(struct vmbus_channel *channel, struct vmbus_gpadl *gpad
>
> kfree(info);
>
> - ret = set_memory_encrypted((unsigned long)gpadl->buffer,
> - PFN_UP(gpadl->size));
> + if (gpadl->decrypted)
> + ret = set_memory_encrypted((unsigned long)gpadl->buffer,
> + PFN_UP(gpadl->size));
> + else
> + ret = 0;
> if (ret)
> pr_warn("Fail to set mem host visibility in GPADL teardown %d.\n", ret);
>
> diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
> index 2873703d08a9..beae68a70939 100644
> --- a/drivers/hv/hyperv_vmbus.h
> +++ b/drivers/hv/hyperv_vmbus.h
> @@ -200,7 +200,8 @@ extern int hv_synic_cleanup(unsigned int cpu);
> void hv_ringbuffer_pre_init(struct vmbus_channel *channel);
>
> int hv_ringbuffer_init(struct hv_ring_buffer_info *ring_info,
> - struct page *pages, u32 pagecnt, u32 max_pkt_size);
> + struct page *pages, u32 pagecnt, u32 max_pkt_size,
> + bool confidential);
>
> void hv_ringbuffer_cleanup(struct hv_ring_buffer_info *ring_info);
>
> diff --git a/drivers/hv/ring_buffer.c b/drivers/hv/ring_buffer.c
> index 3c9b02471760..05c2cd42fc75 100644
> --- a/drivers/hv/ring_buffer.c
> +++ b/drivers/hv/ring_buffer.c
> @@ -183,7 +183,8 @@ void hv_ringbuffer_pre_init(struct vmbus_channel *channel)
>
> /* Initialize the ring buffer. */
> int hv_ringbuffer_init(struct hv_ring_buffer_info *ring_info,
> - struct page *pages, u32 page_cnt, u32 max_pkt_size)
> + struct page *pages, u32 page_cnt, u32 max_pkt_size,
> + bool confidential)
> {
> struct page **pages_wraparound;
> int i;
> @@ -207,7 +208,7 @@ int hv_ringbuffer_init(struct hv_ring_buffer_info *ring_info,
>
> ring_info->ring_buffer = (struct hv_ring_buffer *)
> vmap(pages_wraparound, page_cnt * 2 - 1, VM_MAP,
> - pgprot_decrypted(PAGE_KERNEL));
> + confidential ? PAGE_KERNEL : pgprot_decrypted(PAGE_KERNEL));
>
> kfree(pages_wraparound);
> if (!ring_info->ring_buffer)
> --
> 2.43.0
>
>
--
Thanks
Tianyu Lan
^ permalink raw reply
* RE: [PATCH v6 2/2] Drivers: hv: Introduce mshv_vtl driver
From: Michael Kelley @ 2025-07-25 14:35 UTC (permalink / raw)
To: Naman Jain, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui
Cc: Roman Kisel, Anirudh Rayabharam, Saurabh Sengar,
Stanislav Kinsburskii, Nuno Das Neves, ALOK TIWARI,
Markus Elfring, linux-kernel@vger.kernel.org,
linux-hyperv@vger.kernel.org
In-Reply-To: <03c90b7d-e9b8-4f8f-9267-c273791077c2@linux.microsoft.com>
From: Naman Jain <namjain@linux.microsoft.com> Sent: Thursday, July 24, 2025 10:54 PM
>
> On 7/25/2025 8:52 AM, Michael Kelley wrote:
> > From: Naman Jain <namjain@linux.microsoft.com> Sent: Thursday, July 24, 2025 1:26 AM
> >>
[snip]
> >> +
> >> +static int mshv_vtl_sint_ioctl_set_eventfd(struct mshv_vtl_set_eventfd __user *arg)
> >> +{
> >> + struct mshv_vtl_set_eventfd set_eventfd;
> >> + struct eventfd_ctx *eventfd, *old_eventfd;
> >> +
> >> + if (copy_from_user(&set_eventfd, arg, sizeof(set_eventfd)))
> >> + return -EFAULT;
> >> + if (set_eventfd.flag >= HV_EVENT_FLAGS_COUNT)
> >> + return -EINVAL;
> >> +
> >> + eventfd = NULL;
> >> + if (set_eventfd.fd >= 0) {
> >> + eventfd = eventfd_ctx_fdget(set_eventfd.fd);
> >> + if (IS_ERR(eventfd))
> >> + return PTR_ERR(eventfd);
> >> + }
> >> +
> >> + guard(mutex)(&flag_lock);
> >> + old_eventfd = READ_ONCE(flag_eventfds[set_eventfd.flag]);
> >> + WRITE_ONCE(flag_eventfds[set_eventfd.flag], eventfd);
> >> +
> >> + if (old_eventfd) {
> >> + synchronize_rcu();
> >> + eventfd_ctx_put(old_eventfd);
> >
> > Again, I wonder if is OK to do eventfd_ctx_put() while holding
> > flag_lock, since the use of guard() changes the scope of the lock
> > compared with the previous version of this patch.
> >
>
> I didn't find eventfd_ctx_put() to be a blocking operation, so I thought
> of keeping guard() here. Although, synchronize_rcu() is a blocking
> operation. Please advise, I am Ok with removing the guard, as the lock
> is just being used here, and automatic cleanup should not be an issue
> here.
Yes, I think you are right. I saw the kref_put() and was unsure what
would be called if the object was freed. But the "free" function is
right there staring at me. :-) All it does is ida_free() and kfree(),
both of which would be safe.
You should be good keeping the guard().
Michael
>
>
> >> + }
> >> +
> >> + return 0;
> >> +}
> >> +
^ permalink raw reply
* Re: [PATCH hyperv-next v4 10/16] Drivers: hv: Rename the SynIC enable and disable routines
From: Tianyu Lan @ 2025-07-25 11:21 UTC (permalink / raw)
To: Roman Kisel
Cc: alok.a.tiwari, arnd, bp, corbet, dave.hansen, decui, haiyangz,
hpa, kys, mhklinux, mingo, rdunlap, tglx, Tianyu.Lan, wei.liu,
linux-arch, linux-coco, linux-doc, linux-hyperv, linux-kernel,
x86, apais, benhill, bperkins, sunilmut
In-Reply-To: <20250714221545.5615-11-romank@linux.microsoft.com>
On Tue, Jul 15, 2025 at 6:16 AM Roman Kisel <romank@linux.microsoft.com> wrote:
>
> The confidential VMBus requires support for the both hypervisor
> facing SynIC and the paravisor one.
>
> Rename the functions that enable and disable SynIC with the
> hypervisor. No functional changes.
>
> Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
> ---
> drivers/hv/channel_mgmt.c | 2 +-
> drivers/hv/hv.c | 11 ++++++-----
> drivers/hv/hyperv_vmbus.h | 4 ++--
> drivers/hv/vmbus_drv.c | 6 +++---
> 4 files changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
> index 6f87220e2ca3..ca2fe10c110a 100644
> --- a/drivers/hv/channel_mgmt.c
> +++ b/drivers/hv/channel_mgmt.c
> @@ -845,7 +845,7 @@ static void vmbus_wait_for_unload(void)
> /*
> * In a CoCo VM the hyp_synic_message_page is not allocated
> * in hv_synic_alloc(). Instead it is set/cleared in
> - * hv_synic_enable_regs() and hv_synic_disable_regs()
> + * hv_hyp_synic_enable_regs() and hv_hyp_synic_disable_regs()
> * such that it is set only when the CPU is online. If
> * not all present CPUs are online, the message page
> * might be NULL, so skip such CPUs.
> diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
> index a8669843c56e..94a81bb3c8c7 100644
> --- a/drivers/hv/hv.c
> +++ b/drivers/hv/hv.c
> @@ -266,9 +266,10 @@ void hv_synic_free(void)
> }
>
> /*
> - * hv_synic_enable_regs - Initialize the Synthetic Interrupt Controller.
> + * hv_hyp_synic_enable_regs - Initialize the Synthetic Interrupt Controller
> + * with the hypervisor.
> */
> -void hv_synic_enable_regs(unsigned int cpu)
> +void hv_hyp_synic_enable_regs(unsigned int cpu)
> {
> struct hv_per_cpu_context *hv_cpu =
> per_cpu_ptr(hv_context.cpu_context, cpu);
> @@ -334,14 +335,14 @@ void hv_synic_enable_regs(unsigned int cpu)
>
> int hv_synic_init(unsigned int cpu)
> {
> - hv_synic_enable_regs(cpu);
> + hv_hyp_synic_enable_regs(cpu);
>
> hv_stimer_legacy_init(cpu, VMBUS_MESSAGE_SINT);
>
> return 0;
> }
>
> -void hv_synic_disable_regs(unsigned int cpu)
> +void hv_hyp_synic_disable_regs(unsigned int cpu)
> {
> struct hv_per_cpu_context *hv_cpu =
> per_cpu_ptr(hv_context.cpu_context, cpu);
> @@ -528,7 +529,7 @@ int hv_synic_cleanup(unsigned int cpu)
> always_cleanup:
> hv_stimer_legacy_cleanup(cpu);
>
> - hv_synic_disable_regs(cpu);
> + hv_hyp_synic_disable_regs(cpu);
>
> return ret;
> }
> diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
> index 16b5cf1bca19..2873703d08a9 100644
> --- a/drivers/hv/hyperv_vmbus.h
> +++ b/drivers/hv/hyperv_vmbus.h
> @@ -189,10 +189,10 @@ extern int hv_synic_alloc(void);
>
> extern void hv_synic_free(void);
>
> -extern void hv_synic_enable_regs(unsigned int cpu);
> +extern void hv_hyp_synic_enable_regs(unsigned int cpu);
> extern int hv_synic_init(unsigned int cpu);
>
> -extern void hv_synic_disable_regs(unsigned int cpu);
> +extern void hv_hyp_synic_disable_regs(unsigned int cpu);
> extern int hv_synic_cleanup(unsigned int cpu);
>
> /* Interface */
> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> index 72940a64b0b6..13aca5abc7d8 100644
> --- a/drivers/hv/vmbus_drv.c
> +++ b/drivers/hv/vmbus_drv.c
> @@ -2809,7 +2809,7 @@ static void hv_crash_handler(struct pt_regs *regs)
> */
> cpu = smp_processor_id();
> hv_stimer_cleanup(cpu);
> - hv_synic_disable_regs(cpu);
> + hv_hyp_synic_disable_regs(cpu);
> };
>
> static int hv_synic_suspend(void)
> @@ -2834,14 +2834,14 @@ static int hv_synic_suspend(void)
> * interrupts-disabled context.
> */
>
> - hv_synic_disable_regs(0);
> + hv_hyp_synic_disable_regs(0);
>
> return 0;
> }
>
> static void hv_synic_resume(void)
> {
> - hv_synic_enable_regs(0);
> + hv_hyp_synic_enable_regs(0);
>
> /*
> * Note: we don't need to call hv_stimer_init(0), because the timer
> --
> 2.43.0
>
>
Reviewed-by: Tianyu Lan <tiala@microsoft.com>
--
Thanks
Tianyu Lan
^ permalink raw reply
* Re: [PATCH hyperv-next v4 09/16] Drivers: hv: Check message and event pages for non-NULL before iounmap()
From: Tianyu Lan @ 2025-07-25 11:14 UTC (permalink / raw)
To: Roman Kisel
Cc: alok.a.tiwari, arnd, bp, corbet, dave.hansen, decui, haiyangz,
hpa, kys, mhklinux, mingo, rdunlap, tglx, Tianyu.Lan, wei.liu,
linux-arch, linux-coco, linux-doc, linux-hyperv, linux-kernel,
x86, apais, benhill, bperkins, sunilmut
In-Reply-To: <20250714221545.5615-10-romank@linux.microsoft.com>
On Tue, Jul 15, 2025 at 6:16 AM Roman Kisel <romank@linux.microsoft.com> wrote:
>
> It might happen that some hyp SynIC pages aren't allocated.
>
> Check for that and only then call iounmap().
>
> Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
> ---
> drivers/hv/hv.c | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
> index 820711e954d1..a8669843c56e 100644
> --- a/drivers/hv/hv.c
> +++ b/drivers/hv/hv.c
> @@ -367,8 +367,10 @@ void hv_synic_disable_regs(unsigned int cpu)
> */
> simp.simp_enabled = 0;
> if (ms_hyperv.paravisor_present || hv_root_partition()) {
> - iounmap(hv_cpu->hyp_synic_message_page);
> - hv_cpu->hyp_synic_message_page = NULL;
> + if (hv_cpu->hyp_synic_message_page) {
> + iounmap(hv_cpu->hyp_synic_message_page);
> + hv_cpu->hyp_synic_message_page = NULL;
> + }
> } else {
> simp.base_simp_gpa = 0;
> }
> @@ -379,8 +381,10 @@ void hv_synic_disable_regs(unsigned int cpu)
> siefp.siefp_enabled = 0;
>
> if (ms_hyperv.paravisor_present || hv_root_partition()) {
> - iounmap(hv_cpu->hyp_synic_event_page);
> - hv_cpu->hyp_synic_event_page = NULL;
> + if (hv_cpu->hyp_synic_event_page) {
> + iounmap(hv_cpu->hyp_synic_event_page);
> + hv_cpu->hyp_synic_event_page = NULL;
> + }
> } else {
> siefp.base_siefp_gpa = 0;
> }
> --
> 2.43.0
>
>
Reviewed-by: Tianyu Lan <tiala@microsoft.com>
--
Thanks
Tianyu Lan
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox