* [PATCH 3/4] mshv: Handle insufficient contiguous memory hypervisor status
From: Stanislav Kinsburskii @ 2026-01-23 1:35 UTC (permalink / raw)
To: kys, haiyangz, wei.liu, decui, longli; +Cc: linux-hyperv, linux-kernel
In-Reply-To: <176913164914.89165.5792608454600292463.stgit@skinsburskii-cloud-desktop.internal.cloudapp.net>
The HV_STATUS_INSUFFICIENT_CONTIGUOUS_MEMORY status indicates that the
hypervisor lacks sufficient contiguous memory for its internal allocations.
When this status is encountered, allocate and deposit
HV_MAX_CONTIGUOUS_ALLOCATION_PAGES contiguous pages to the hypervisor.
HV_MAX_CONTIGUOUS_ALLOCATION_PAGES is defined in the hypervisor headers, a
deposit of this size will always satisfy the hypervisor's requirements.
Signed-off-by: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>
---
drivers/hv/hv_common.c | 1 +
drivers/hv/hv_proc.c | 4 ++++
include/hyperv/hvgdk_mini.h | 1 +
include/hyperv/hvhdk_mini.h | 2 ++
4 files changed, 8 insertions(+)
diff --git a/drivers/hv/hv_common.c b/drivers/hv/hv_common.c
index 0a3ab7efed46..c7f63c9de503 100644
--- a/drivers/hv/hv_common.c
+++ b/drivers/hv/hv_common.c
@@ -791,6 +791,7 @@ static const struct hv_status_info hv_status_infos[] = {
_STATUS_INFO(HV_STATUS_UNKNOWN_PROPERTY, -EIO),
_STATUS_INFO(HV_STATUS_PROPERTY_VALUE_OUT_OF_RANGE, -EIO),
_STATUS_INFO(HV_STATUS_INSUFFICIENT_MEMORY, -ENOMEM),
+ _STATUS_INFO(HV_STATUS_INSUFFICIENT_CONTIGUOUS_MEMORY, -ENOMEM),
_STATUS_INFO(HV_STATUS_INVALID_PARTITION_ID, -EINVAL),
_STATUS_INFO(HV_STATUS_INVALID_VP_INDEX, -EINVAL),
_STATUS_INFO(HV_STATUS_NOT_FOUND, -EIO),
diff --git a/drivers/hv/hv_proc.c b/drivers/hv/hv_proc.c
index c0c2bfc80d77..ac21e16f9348 100644
--- a/drivers/hv/hv_proc.c
+++ b/drivers/hv/hv_proc.c
@@ -119,6 +119,9 @@ int hv_deposit_memory_node(int node, u64 partition_id,
case HV_STATUS_INSUFFICIENT_MEMORY:
num_pages = 1;
break;
+ case HV_STATUS_INSUFFICIENT_CONTIGUOUS_MEMORY:
+ num_pages = HV_MAX_CONTIGUOUS_ALLOCATION_PAGES;
+ break;
default:
hv_status_err(hv_status, "Unexpected!\n");
return -ENOMEM;
@@ -131,6 +134,7 @@ bool hv_result_oom(u64 status)
{
switch (hv_result(status)) {
case HV_STATUS_INSUFFICIENT_MEMORY:
+ case HV_STATUS_INSUFFICIENT_CONTIGUOUS_MEMORY:
return true;
}
return false;
diff --git a/include/hyperv/hvgdk_mini.h b/include/hyperv/hvgdk_mini.h
index 04b18d0e37af..70f22ef44948 100644
--- a/include/hyperv/hvgdk_mini.h
+++ b/include/hyperv/hvgdk_mini.h
@@ -38,6 +38,7 @@ struct hv_u128 {
#define HV_STATUS_INVALID_LP_INDEX 0x41
#define HV_STATUS_INVALID_REGISTER_VALUE 0x50
#define HV_STATUS_OPERATION_FAILED 0x71
+#define HV_STATUS_INSUFFICIENT_CONTIGUOUS_MEMORY 0x75
#define HV_STATUS_TIME_OUT 0x78
#define HV_STATUS_CALL_PENDING 0x79
#define HV_STATUS_VTL_ALREADY_ENABLED 0x86
diff --git a/include/hyperv/hvhdk_mini.h b/include/hyperv/hvhdk_mini.h
index 0f7178fa88a8..c5cfe13fae57 100644
--- a/include/hyperv/hvhdk_mini.h
+++ b/include/hyperv/hvhdk_mini.h
@@ -7,6 +7,8 @@
#include "hvgdk_mini.h"
+#define HV_MAX_CONTIGUOUS_ALLOCATION_PAGES 8
+
/*
* Doorbell connection_info flags.
*/
^ permalink raw reply related
* [PATCH 2/4] mshv: Introduce hv_deposit_memory helper functions
From: Stanislav Kinsburskii @ 2026-01-23 1:35 UTC (permalink / raw)
To: kys, haiyangz, wei.liu, decui, longli; +Cc: linux-hyperv, linux-kernel
In-Reply-To: <176913164914.89165.5792608454600292463.stgit@skinsburskii-cloud-desktop.internal.cloudapp.net>
Introduce hv_deposit_memory_node() and hv_deposit_memory() helper
functions to handle memory deposition with proper error handling.
The new hv_deposit_memory_node() function takes the hypervisor status
as a parameter and validates it before depositing pages. It checks for
HV_STATUS_INSUFFICIENT_MEMORY specifically and returns an error for
unexpected status codes.
This is a precursor patch to new out-of-memory error codes support.
No functional changes intended.
Signed-off-by: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>
---
drivers/hv/hv_proc.c | 22 ++++++++++++++++++++--
drivers/hv/mshv_root_hv_call.c | 25 +++++++++----------------
drivers/hv/mshv_root_main.c | 3 +--
include/asm-generic/mshyperv.h | 10 ++++++++++
4 files changed, 40 insertions(+), 20 deletions(-)
diff --git a/drivers/hv/hv_proc.c b/drivers/hv/hv_proc.c
index 80c66d1c74d5..c0c2bfc80d77 100644
--- a/drivers/hv/hv_proc.c
+++ b/drivers/hv/hv_proc.c
@@ -110,6 +110,23 @@ int hv_call_deposit_pages(int node, u64 partition_id, u32 num_pages)
}
EXPORT_SYMBOL_GPL(hv_call_deposit_pages);
+int hv_deposit_memory_node(int node, u64 partition_id,
+ u64 hv_status)
+{
+ u32 num_pages;
+
+ switch (hv_result(hv_status)) {
+ case HV_STATUS_INSUFFICIENT_MEMORY:
+ num_pages = 1;
+ break;
+ default:
+ hv_status_err(hv_status, "Unexpected!\n");
+ return -ENOMEM;
+ }
+ return hv_call_deposit_pages(node, partition_id, num_pages);
+}
+EXPORT_SYMBOL_GPL(hv_deposit_memory_node);
+
bool hv_result_oom(u64 status)
{
switch (hv_result(status)) {
@@ -155,7 +172,8 @@ int hv_call_add_logical_proc(int node, u32 lp_index, u32 apic_id)
}
break;
}
- ret = hv_call_deposit_pages(node, hv_current_partition_id, 1);
+ ret = hv_deposit_memory_node(node, hv_current_partition_id,
+ status);
} while (!ret);
return ret;
@@ -197,7 +215,7 @@ int hv_call_create_vp(int node, u64 partition_id, u32 vp_index, u32 flags)
}
break;
}
- ret = hv_call_deposit_pages(node, partition_id, 1);
+ ret = hv_deposit_memory_node(node, partition_id, status);
} while (!ret);
diff --git a/drivers/hv/mshv_root_hv_call.c b/drivers/hv/mshv_root_hv_call.c
index 58c5cbf2e567..06f2bac8039d 100644
--- a/drivers/hv/mshv_root_hv_call.c
+++ b/drivers/hv/mshv_root_hv_call.c
@@ -123,8 +123,7 @@ int hv_call_create_partition(u64 flags,
break;
}
local_irq_restore(irq_flags);
- ret = hv_call_deposit_pages(NUMA_NO_NODE,
- hv_current_partition_id, 1);
+ ret = hv_deposit_memory(hv_current_partition_id, status);
} while (!ret);
return ret;
@@ -151,7 +150,7 @@ int hv_call_initialize_partition(u64 partition_id)
ret = hv_result_to_errno(status);
break;
}
- ret = hv_call_deposit_pages(NUMA_NO_NODE, partition_id, 1);
+ ret = hv_deposit_memory(partition_id, status);
} while (!ret);
return ret;
@@ -465,8 +464,7 @@ int hv_call_get_vp_state(u32 vp_index, u64 partition_id,
}
local_irq_restore(flags);
- ret = hv_call_deposit_pages(NUMA_NO_NODE,
- partition_id, 1);
+ ret = hv_deposit_memory(partition_id, status);
} while (!ret);
return ret;
@@ -525,8 +523,7 @@ int hv_call_set_vp_state(u32 vp_index, u64 partition_id,
}
local_irq_restore(flags);
- ret = hv_call_deposit_pages(NUMA_NO_NODE,
- partition_id, 1);
+ ret = hv_deposit_memory(partition_id, status);
} while (!ret);
return ret;
@@ -573,7 +570,7 @@ static int hv_call_map_vp_state_page(u64 partition_id, u32 vp_index, u32 type,
local_irq_restore(flags);
- ret = hv_call_deposit_pages(NUMA_NO_NODE, partition_id, 1);
+ ret = hv_deposit_memory(partition_id, status);
} while (!ret);
return ret;
@@ -722,8 +719,7 @@ hv_call_create_port(u64 port_partition_id, union hv_port_id port_id,
ret = hv_result_to_errno(status);
break;
}
- ret = hv_call_deposit_pages(NUMA_NO_NODE, port_partition_id, 1);
-
+ ret = hv_deposit_memory(port_partition_id, status);
} while (!ret);
return ret;
@@ -776,8 +772,7 @@ hv_call_connect_port(u64 port_partition_id, union hv_port_id port_id,
ret = hv_result_to_errno(status);
break;
}
- ret = hv_call_deposit_pages(NUMA_NO_NODE,
- connection_partition_id, 1);
+ ret = hv_deposit_memory(connection_partition_id, status);
} while (!ret);
return ret;
@@ -848,8 +843,7 @@ static int hv_call_map_stats_page2(enum hv_stats_object_type type,
break;
}
- ret = hv_call_deposit_pages(NUMA_NO_NODE,
- hv_current_partition_id, 1);
+ ret = hv_deposit_memory(hv_current_partition_id, status);
} while (!ret);
return ret;
@@ -885,8 +879,7 @@ static int hv_call_map_stats_page(enum hv_stats_object_type type,
return ret;
}
- ret = hv_call_deposit_pages(NUMA_NO_NODE,
- hv_current_partition_id, 1);
+ ret = hv_deposit_memory(hv_current_partition_id, status);
if (ret)
return ret;
} while (!ret);
diff --git a/drivers/hv/mshv_root_main.c b/drivers/hv/mshv_root_main.c
index f4697497f83e..5fc572e31cd7 100644
--- a/drivers/hv/mshv_root_main.c
+++ b/drivers/hv/mshv_root_main.c
@@ -264,8 +264,7 @@ static int mshv_ioctl_passthru_hvcall(struct mshv_partition *partition,
if (!hv_result_oom(status))
ret = hv_result_to_errno(status);
else
- ret = hv_call_deposit_pages(NUMA_NO_NODE,
- pt_id, 1);
+ ret = hv_deposit_memory(pt_id, status);
} while (!ret);
args.status = hv_result(status);
diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyperv.h
index b73352a7fc9e..c8e8976839f8 100644
--- a/include/asm-generic/mshyperv.h
+++ b/include/asm-generic/mshyperv.h
@@ -344,6 +344,7 @@ static inline bool hv_parent_partition(void)
}
bool hv_result_oom(u64 status);
+int hv_deposit_memory_node(int node, u64 partition_id, u64 status);
int hv_call_deposit_pages(int node, u64 partition_id, u32 num_pages);
int hv_call_add_logical_proc(int node, u32 lp_index, u32 acpi_id);
int hv_call_create_vp(int node, u64 partition_id, u32 vp_index, u32 flags);
@@ -353,6 +354,10 @@ static inline bool hv_root_partition(void) { return false; }
static inline bool hv_l1vh_partition(void) { return false; }
static inline bool hv_parent_partition(void) { return false; }
static inline bool hv_result_oom(u64 status) { return false; }
+static inline int hv_deposit_memory_node(int node, u64 partition_id, u64 status)
+{
+ return -EOPNOTSUPP;
+}
static inline int hv_call_deposit_pages(int node, u64 partition_id, u32 num_pages)
{
return -EOPNOTSUPP;
@@ -367,6 +372,11 @@ static inline int hv_call_create_vp(int node, u64 partition_id, u32 vp_index, u3
}
#endif /* CONFIG_MSHV_ROOT */
+static inline int hv_deposit_memory(u64 partition_id, u64 status)
+{
+ return hv_deposit_memory_node(NUMA_NO_NODE, partition_id, status);
+}
+
#if IS_ENABLED(CONFIG_HYPERV_VTL_MODE)
u8 __init get_vtl(void);
#else
^ permalink raw reply related
* [PATCH 1/4] mshv: Introduce hv_result_oom() helper function
From: Stanislav Kinsburskii @ 2026-01-23 1:35 UTC (permalink / raw)
To: kys, haiyangz, wei.liu, decui, longli; +Cc: linux-hyperv, linux-kernel
In-Reply-To: <176913164914.89165.5792608454600292463.stgit@skinsburskii-cloud-desktop.internal.cloudapp.net>
Replace direct comparisons of hv_result(status) against
HV_STATUS_INSUFFICIENT_MEMORY with a new hv_result_oom() helper function.
This improves code readability and provides a consistent and extendable
interface for checking out-of-memory conditions in hypercall results.
No functional changes intended.
Signed-off-by: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>
---
drivers/hv/hv_proc.c | 14 ++++++++++++--
drivers/hv/mshv_root_hv_call.c | 20 ++++++++++----------
drivers/hv/mshv_root_main.c | 2 +-
include/asm-generic/mshyperv.h | 3 +++
4 files changed, 26 insertions(+), 13 deletions(-)
diff --git a/drivers/hv/hv_proc.c b/drivers/hv/hv_proc.c
index fbb4eb3901bb..80c66d1c74d5 100644
--- a/drivers/hv/hv_proc.c
+++ b/drivers/hv/hv_proc.c
@@ -110,6 +110,16 @@ int hv_call_deposit_pages(int node, u64 partition_id, u32 num_pages)
}
EXPORT_SYMBOL_GPL(hv_call_deposit_pages);
+bool hv_result_oom(u64 status)
+{
+ switch (hv_result(status)) {
+ case HV_STATUS_INSUFFICIENT_MEMORY:
+ return true;
+ }
+ return false;
+}
+EXPORT_SYMBOL_GPL(hv_result_oom);
+
int hv_call_add_logical_proc(int node, u32 lp_index, u32 apic_id)
{
struct hv_input_add_logical_processor *input;
@@ -137,7 +147,7 @@ int hv_call_add_logical_proc(int node, u32 lp_index, u32 apic_id)
input, output);
local_irq_restore(flags);
- if (hv_result(status) != HV_STATUS_INSUFFICIENT_MEMORY) {
+ if (!hv_result_oom(status)) {
if (!hv_result_success(status)) {
hv_status_err(status, "cpu %u apic ID: %u\n",
lp_index, apic_id);
@@ -179,7 +189,7 @@ int hv_call_create_vp(int node, u64 partition_id, u32 vp_index, u32 flags)
status = hv_do_hypercall(HVCALL_CREATE_VP, input, NULL);
local_irq_restore(irq_flags);
- if (hv_result(status) != HV_STATUS_INSUFFICIENT_MEMORY) {
+ if (!hv_result_oom(status)) {
if (!hv_result_success(status)) {
hv_status_err(status, "vcpu: %u, lp: %u\n",
vp_index, flags);
diff --git a/drivers/hv/mshv_root_hv_call.c b/drivers/hv/mshv_root_hv_call.c
index 598eaff4ff29..58c5cbf2e567 100644
--- a/drivers/hv/mshv_root_hv_call.c
+++ b/drivers/hv/mshv_root_hv_call.c
@@ -115,7 +115,7 @@ int hv_call_create_partition(u64 flags,
status = hv_do_hypercall(HVCALL_CREATE_PARTITION,
input, output);
- if (hv_result(status) != HV_STATUS_INSUFFICIENT_MEMORY) {
+ if (!hv_result_oom(status)) {
if (hv_result_success(status))
*partition_id = output->partition_id;
local_irq_restore(irq_flags);
@@ -147,7 +147,7 @@ int hv_call_initialize_partition(u64 partition_id)
status = hv_do_fast_hypercall8(HVCALL_INITIALIZE_PARTITION,
*(u64 *)&input);
- if (hv_result(status) != HV_STATUS_INSUFFICIENT_MEMORY) {
+ if (!hv_result_oom(status)) {
ret = hv_result_to_errno(status);
break;
}
@@ -239,7 +239,7 @@ static int hv_do_map_gpa_hcall(u64 partition_id, u64 gfn, u64 page_struct_count,
completed = hv_repcomp(status);
- if (hv_result(status) == HV_STATUS_INSUFFICIENT_MEMORY) {
+ if (hv_result_oom(status)) {
ret = hv_call_deposit_pages(NUMA_NO_NODE, partition_id,
HV_MAP_GPA_DEPOSIT_PAGES);
if (ret)
@@ -455,7 +455,7 @@ int hv_call_get_vp_state(u32 vp_index, u64 partition_id,
status = hv_do_hypercall(control, input, output);
- if (hv_result(status) != HV_STATUS_INSUFFICIENT_MEMORY) {
+ if (!hv_result_oom(status)) {
if (hv_result_success(status) && ret_output)
memcpy(ret_output, output, sizeof(*output));
@@ -518,7 +518,7 @@ int hv_call_set_vp_state(u32 vp_index, u64 partition_id,
status = hv_do_hypercall(control, input, NULL);
- if (hv_result(status) != HV_STATUS_INSUFFICIENT_MEMORY) {
+ if (!hv_result_oom(status)) {
local_irq_restore(flags);
ret = hv_result_to_errno(status);
break;
@@ -563,7 +563,7 @@ static int hv_call_map_vp_state_page(u64 partition_id, u32 vp_index, u32 type,
status = hv_do_hypercall(HVCALL_MAP_VP_STATE_PAGE, input,
output);
- if (hv_result(status) != HV_STATUS_INSUFFICIENT_MEMORY) {
+ if (!hv_result_oom(status)) {
if (hv_result_success(status))
*state_page = pfn_to_page(output->map_location);
local_irq_restore(flags);
@@ -718,7 +718,7 @@ hv_call_create_port(u64 port_partition_id, union hv_port_id port_id,
if (hv_result_success(status))
break;
- if (hv_result(status) != HV_STATUS_INSUFFICIENT_MEMORY) {
+ if (!hv_result_oom(status)) {
ret = hv_result_to_errno(status);
break;
}
@@ -772,7 +772,7 @@ hv_call_connect_port(u64 port_partition_id, union hv_port_id port_id,
if (hv_result_success(status))
break;
- if (hv_result(status) != HV_STATUS_INSUFFICIENT_MEMORY) {
+ if (!hv_result_oom(status)) {
ret = hv_result_to_errno(status);
break;
}
@@ -843,7 +843,7 @@ static int hv_call_map_stats_page2(enum hv_stats_object_type type,
if (!ret)
break;
- if (hv_result(status) != HV_STATUS_INSUFFICIENT_MEMORY) {
+ if (!hv_result_oom(status)) {
hv_status_debug(status, "\n");
break;
}
@@ -878,7 +878,7 @@ static int hv_call_map_stats_page(enum hv_stats_object_type type,
pfn = output->map_location;
local_irq_restore(flags);
- if (hv_result(status) != HV_STATUS_INSUFFICIENT_MEMORY) {
+ if (!hv_result_oom(status)) {
ret = hv_result_to_errno(status);
if (hv_result_success(status))
break;
diff --git a/drivers/hv/mshv_root_main.c b/drivers/hv/mshv_root_main.c
index 7a36297feea7..f4697497f83e 100644
--- a/drivers/hv/mshv_root_main.c
+++ b/drivers/hv/mshv_root_main.c
@@ -261,7 +261,7 @@ static int mshv_ioctl_passthru_hvcall(struct mshv_partition *partition,
if (hv_result_success(status))
break;
- if (hv_result(status) != HV_STATUS_INSUFFICIENT_MEMORY)
+ if (!hv_result_oom(status))
ret = hv_result_to_errno(status);
else
ret = hv_call_deposit_pages(NUMA_NO_NODE,
diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyperv.h
index ecedab554c80..b73352a7fc9e 100644
--- a/include/asm-generic/mshyperv.h
+++ b/include/asm-generic/mshyperv.h
@@ -342,6 +342,8 @@ static inline bool hv_parent_partition(void)
{
return hv_root_partition() || hv_l1vh_partition();
}
+
+bool hv_result_oom(u64 status);
int hv_call_deposit_pages(int node, u64 partition_id, u32 num_pages);
int hv_call_add_logical_proc(int node, u32 lp_index, u32 acpi_id);
int hv_call_create_vp(int node, u64 partition_id, u32 vp_index, u32 flags);
@@ -350,6 +352,7 @@ int hv_call_create_vp(int node, u64 partition_id, u32 vp_index, u32 flags);
static inline bool hv_root_partition(void) { return false; }
static inline bool hv_l1vh_partition(void) { return false; }
static inline bool hv_parent_partition(void) { return false; }
+static inline bool hv_result_oom(u64 status) { return false; }
static inline int hv_call_deposit_pages(int node, u64 partition_id, u32 num_pages)
{
return -EOPNOTSUPP;
^ permalink raw reply related
* [PATCH 0/4] Improve Hyper-V memory deposit error handling
From: Stanislav Kinsburskii @ 2026-01-23 1:35 UTC (permalink / raw)
To: kys, haiyangz, wei.liu, decui, longli; +Cc: linux-hyperv, linux-kernel
This series extends the MSHV driver to properly handle additional
memory-related error codes from the Microsofot Hypervisor by depositing
memory pages when needed.
Currently, when the hypervisor returns HV_STATUS_INSUFFICIENT_MEMORY
during partition creation, the driver calls hv_call_deposit_pages() to
provide the necessary memory. However, there are other memory-related
error codes that indicate the hypervisor needs additional memory
resources, but the driver does not attempt to deposit pages for these
cases.
This series introduces the hv_result_oom() helper function macro to
identify all memory-related error codes (HV_STATUS_INSUFFICIENT_MEMORY,
HV_STATUS_INSUFFICIENT_BUFFERS, HV_STATUS_INSUFFICIENT_DEVICE_DOMAINS, and
HV_STATUS_INSUFFICIENT_ROOT_MEMORY) and ensures the driver attempts to
deposit pages for all of them via new hv_deposit_memory() helper.
With these changes, partition creation becomes more robust by handling
all scenarios where the hypervisor requires additional memory deposits.
---
Stanislav Kinsburskii (4):
mshv: Introduce hv_result_oom() helper function
mshv: Introduce hv_deposit_memory helper functions
mshv: Handle insufficient contiguous memory hypervisor status
mshv: Handle insufficient root memory hypervisor status
drivers/hv/hv_common.c | 3 ++
drivers/hv/hv_proc.c | 54 +++++++++++++++++++++++++++++++++++---
drivers/hv/mshv_root_hv_call.c | 45 +++++++++++++-------------------
drivers/hv/mshv_root_main.c | 5 +---
include/asm-generic/mshyperv.h | 13 +++++++++
include/hyperv/hvgdk_mini.h | 57 +++++++++++++++++++++-------------------
include/hyperv/hvhdk_mini.h | 2 +
7 files changed, 119 insertions(+), 60 deletions(-)
^ permalink raw reply
* RE: [PATCH] PCI: hv: Allocate MMIO from above 4GB for the config window
From: Michael Kelley @ 2026-01-22 20:22 UTC (permalink / raw)
To: Long Li, Dexuan Cui, KY Srinivasan, Haiyang Zhang,
wei.liu@kernel.org, lpieralisi@kernel.org, kwilczynski@kernel.org,
mani@kernel.org, robh@kernel.org, bhelgaas@google.com,
Jake Oshins, linux-hyperv@vger.kernel.org,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org
In-Reply-To: <DS3PR21MB5735C620871D15F75A9B7BAFCE97A@DS3PR21MB5735.namprd21.prod.outlook.com>
From: Long Li <longli@microsoft.com> Sent: Thursday, January 22, 2026 11:14 AM
>
> > From: Dexuan Cui <decui@microsoft.com> Sent: Wednesday, January 21, 2026 6:04 PM
> > >
> > > There has been a longstanding MMIO conflict between the pci_hyperv
> > > driver's config_window (see hv_allocate_config_window()) and the
> > > hyperv_drm (or hyperv_fb) driver (see hyperv_setup_vram()): typically
> > > both get MMIO from the low MMIO range below 4GB; this is not an issue
> > > in the normal kernel since the VMBus driver reserves the framebuffer
> > > MMIO in vmbus_reserve_fb(), so the drm driver's hyperv_setup_vram()
> > > can always get the reserved framebuffer MMIO; however, a Gen2 VM's
> > > kdump kernel fails to reserve the framebuffer MMIO in
> > > vmbus_reserve_fb() because the screen_info.lfb_base is zero in the
> > > kdump kernel: the screen_info is not initialized at all in the kdump
> > > kernel, because the EFI stub code, which initializes screen_info, doesn't run in
> > the case of kdump.
> >
> > I don't think this is correct. Yes, the EFI stub doesn't run, but screen_info should
> > be initialized in the kdump kernel by the code that loads the kdump kernel into
> > the reserved crash memory. See discussion in the commit message for commit
> > 304386373007.
>
> On AMD64 the screen_info is passed through kexec system call. But this is not the case
> for ARM64, it relies on EFI to get screen_info.
Hmmm. So does the problem described here only happen on arm64? If so, that
might be worth noting in the commit message.
I found my notes from working on commit 304386373007. I don't remember
testing on arm64, and my notes don't mention it. So I'm wondering if the problem
fixed by that commit could happen on arm64. That's potentially a separate issue
from this one. I'll do some experiments to verify.
>
> However, Hyper-v guarantees the framebuffer MMIO is below 4GB. So, the patch works
> by allocating PCI MMIO separately from that of the framebuffer.
Yes, that seems right. But there's still something nagging at me about this,
though I can't immediately identify a problem. I'll follow up if something
comes to me. :-)
Michael
>
> Long
>
> >
> > I wonder if commit a41e0ab394e4 broke the initialization of screen_info in the
> > kdump kernel. Or perhaps there is now a rev-lock between the kernel with this
> > commit and a new version of the user space kexec command.
> >
> > There's a parameter to the kexec() command that governs whether it uses the
> > kexec_file_load() system call or the kexec_load() system call.
> > I wonder if that parameter makes a difference in the problem described for this
> > patch.
> >
> > I can't immediately remember if, when I was working on commit 304386373007, I
> > tested kdump in a Gen 2 VM with an NVMe OS disk to ensure that MMIO space
> > was properly allocated to the frame buffer driver (either hyperv_fb or
> > hyperv_drm). I'm thinking I did, but tomorrow I'll check for any definitive notes on
> > that.
> >
> > Michael
> >
> > >
> > > When vmbus_reserve_fb() fails to reserve the framebuffer MMIO in the
> > > kdump kernel, if pci_hyperv in the kdump kernel loads before
> > > hyperv_drm loads, pci_hyperv's vmbus_allocate_mmio() gets the
> > > framebuffer MMIO and tries to use it, but since the host thinks that
> > > the MMIO range is still in use by hyperv_drm, the host refuses to
> > > accept the MMIO range as the config window, and pci_hyperv's
> > hv_pci_enter_d0() errors out:
> > > "PCI Pass-through VSP failed D0 Entry with status c0370048".
> > >
> > > This PCI error in the kdump kernel was not fatal in the past because
> > > the kdump kernel normally doesn't reply on pci_hyperv, and the root
> > > file system is on a VMBus SCSI device.
> > >
> > > Now, a VM on Azure can boot from NVMe, i.e. the root FS can be on a
> > > NVMe device, which depends on pci_hyperv. When the PCI error occurs,
> > > the kdump kernel fails to boot up since no root FS is detected.
> > >
> > > Fix the MMIO conflict by allocating MMIO above 4GB for the
> > > config_window.
> > >
> > > Note: we still need to figure out how to address the possible MMIO
> > > conflict between hyperv_drm and pci_hyperv in the case of 32-bit PCI
> > > MMIO BARs, but that's of low priority because all PCI devices
> > > available to a Linux VM on Azure should use 64-bit BARs and should not
> > > use 32-bit BARs -- I checked Mellanox VFs, MANA VFs, NVMe devices, and
> > > GPUs in Linux VMs on Azure, and found no 32-bit BARs.
> > >
> > > Fixes: 4daace0d8ce8 ("PCI: hv: Add paravirtual PCI front-end for
> > > Microsoft Hyper-V VMs")
> > > Signed-off-by: Dexuan Cui <decui@microsoft.com>
> > > Cc: stable@vger.kernel.org
> > > ---
> > > drivers/pci/controller/pci-hyperv.c | 8 ++++++--
> > > 1 file changed, 6 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/pci/controller/pci-hyperv.c
> > > b/drivers/pci/controller/pci-hyperv.c
> > > index 1e237d3538f9..a6aecb1b5cab 100644
> > > --- a/drivers/pci/controller/pci-hyperv.c
> > > +++ b/drivers/pci/controller/pci-hyperv.c
> > > @@ -3406,9 +3406,13 @@ static int hv_allocate_config_window(struct
> > > hv_pcibus_device *hbus)
> > >
> > > /*
> > > * Set up a region of MMIO space to use for accessing configuration
> > > - * space.
> > > + * space. Use the high MMIO range to not conflict with the hyperv_drm
> > > + * driver (which normally gets MMIO from the low MMIO range) in the
> > > + * kdump kernel of a Gen2 VM, which fails to reserve the framebuffer
> > > + * MMIO range in vmbus_reserve_fb() due to screen_info.lfb_base being
> > > + * zero in the kdump kernel.
> > > */
> > > - ret = vmbus_allocate_mmio(&hbus->mem_config, hbus->hdev, 0, -1,
> > > + ret = vmbus_allocate_mmio(&hbus->mem_config, hbus->hdev, SZ_4G, -1,
> > > PCI_CONFIG_MMIO_LENGTH, 0x1000, false);
> > > if (ret)
> > > return ret;
> > > --
> > > 2.43.0
^ permalink raw reply
* RE: [PATCH] PCI: hv: Allocate MMIO from above 4GB for the config window
From: Long Li @ 2026-01-22 19:14 UTC (permalink / raw)
To: Michael Kelley, Dexuan Cui, KY Srinivasan, Haiyang Zhang,
wei.liu@kernel.org, lpieralisi@kernel.org, kwilczynski@kernel.org,
mani@kernel.org, robh@kernel.org, bhelgaas@google.com,
Jake Oshins, linux-hyperv@vger.kernel.org,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org
In-Reply-To: <BN7PR02MB41486A6DBF839D5BC5D5BC2ED497A@BN7PR02MB4148.namprd02.prod.outlook.com>
> From: Dexuan Cui <decui@microsoft.com> Sent: Wednesday, January 21, 2026
> 6:04 PM
> >
> > There has been a longstanding MMIO conflict between the pci_hyperv
> > driver's config_window (see hv_allocate_config_window()) and the
> > hyperv_drm (or hyperv_fb) driver (see hyperv_setup_vram()): typically
> > both get MMIO from the low MMIO range below 4GB; this is not an issue
> > in the normal kernel since the VMBus driver reserves the framebuffer
> > MMIO in vmbus_reserve_fb(), so the drm driver's hyperv_setup_vram()
> > can always get the reserved framebuffer MMIO; however, a Gen2 VM's
> > kdump kernel fails to reserve the framebuffer MMIO in
> > vmbus_reserve_fb() because the screen_info.lfb_base is zero in the
> > kdump kernel: the screen_info is not initialized at all in the kdump
> > kernel, because the EFI stub code, which initializes screen_info, doesn't run in
> the case of kdump.
>
> I don't think this is correct. Yes, the EFI stub doesn't run, but screen_info should
> be initialized in the kdump kernel by the code that loads the kdump kernel into
> the reserved crash memory. See discussion in the commit message for commit
> 304386373007.
On AMD64 the screen_info is passed through kexec system call. But this is not the case for ARM64, it relies on EFI to get screen_info.
However, Hyper-v guarantees the framebuffer MMIO is below 4GB. So, the patch works by allocating PCI MMIO separately from that of the framebuffer.
Long
>
> I wonder if commit a41e0ab394e4 broke the initialization of screen_info in the
> kdump kernel. Or perhaps there is now a rev-lock between the kernel with this
> commit and a new version of the user space kexec command.
>
> There's a parameter to the kexec() command that governs whether it uses the
> kexec_file_load() system call or the kexec_load() system call.
> I wonder if that parameter makes a difference in the problem described for this
> patch.
>
> I can't immediately remember if, when I was working on commit 304386373007, I
> tested kdump in a Gen 2 VM with an NVMe OS disk to ensure that MMIO space
> was properly allocated to the frame buffer driver (either hyperv_fb or
> hyperv_drm). I'm thinking I did, but tomorrow I'll check for any definitive notes on
> that.
>
> Michael
>
> >
> > When vmbus_reserve_fb() fails to reserve the framebuffer MMIO in the
> > kdump kernel, if pci_hyperv in the kdump kernel loads before
> > hyperv_drm loads, pci_hyperv's vmbus_allocate_mmio() gets the
> > framebuffer MMIO and tries to use it, but since the host thinks that
> > the MMIO range is still in use by hyperv_drm, the host refuses to
> > accept the MMIO range as the config window, and pci_hyperv's
> hv_pci_enter_d0() errors out:
> > "PCI Pass-through VSP failed D0 Entry with status c0370048".
> >
> > This PCI error in the kdump kernel was not fatal in the past because
> > the kdump kernel normally doesn't reply on pci_hyperv, and the root
> > file system is on a VMBus SCSI device.
> >
> > Now, a VM on Azure can boot from NVMe, i.e. the root FS can be on a
> > NVMe device, which depends on pci_hyperv. When the PCI error occurs,
> > the kdump kernel fails to boot up since no root FS is detected.
> >
> > Fix the MMIO conflict by allocating MMIO above 4GB for the
> > config_window.
> >
> > Note: we still need to figure out how to address the possible MMIO
> > conflict between hyperv_drm and pci_hyperv in the case of 32-bit PCI
> > MMIO BARs, but that's of low priority because all PCI devices
> > available to a Linux VM on Azure should use 64-bit BARs and should not
> > use 32-bit BARs -- I checked Mellanox VFs, MANA VFs, NVMe devices, and
> > GPUs in Linux VMs on Azure, and found no 32-bit BARs.
> >
> > Fixes: 4daace0d8ce8 ("PCI: hv: Add paravirtual PCI front-end for
> > Microsoft Hyper-V VMs")
> > Signed-off-by: Dexuan Cui <decui@microsoft.com>
> > Cc: stable@vger.kernel.org
> > ---
> > drivers/pci/controller/pci-hyperv.c | 8 ++++++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/controller/pci-hyperv.c
> > b/drivers/pci/controller/pci-hyperv.c
> > index 1e237d3538f9..a6aecb1b5cab 100644
> > --- a/drivers/pci/controller/pci-hyperv.c
> > +++ b/drivers/pci/controller/pci-hyperv.c
> > @@ -3406,9 +3406,13 @@ static int hv_allocate_config_window(struct
> > hv_pcibus_device *hbus)
> >
> > /*
> > * Set up a region of MMIO space to use for accessing configuration
> > - * space.
> > + * space. Use the high MMIO range to not conflict with the hyperv_drm
> > + * driver (which normally gets MMIO from the low MMIO range) in the
> > + * kdump kernel of a Gen2 VM, which fails to reserve the framebuffer
> > + * MMIO range in vmbus_reserve_fb() due to screen_info.lfb_base being
> > + * zero in the kdump kernel.
> > */
> > - ret = vmbus_allocate_mmio(&hbus->mem_config, hbus->hdev, 0, -1,
> > + ret = vmbus_allocate_mmio(&hbus->mem_config, hbus->hdev, SZ_4G, -1,
> > PCI_CONFIG_MMIO_LENGTH, 0x1000, false);
> > if (ret)
> > return ret;
> > --
> > 2.43.0
^ permalink raw reply
* RE: [PATCH v4 6/7] mshv: Add data for printing stats page counters
From: Michael Kelley @ 2026-01-22 18:52 UTC (permalink / raw)
To: Nuno Das Neves, Stanislav Kinsburskii
Cc: linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org,
kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org,
decui@microsoft.com, longli@microsoft.com,
prapal@linux.microsoft.com, mrathor@linux.microsoft.com,
paekkaladevi@linux.microsoft.com
In-Reply-To: <3ecdc642-75de-4622-a010-dc6edc78137c@linux.microsoft.com>
From: Nuno Das Neves <nunodasneves@linux.microsoft.com> Sent: Thursday, January 22, 2026 10:21 AM
>
> On 1/21/2026 5:18 PM, Stanislav Kinsburskii wrote:
> > On Wed, Jan 21, 2026 at 01:46:22PM -0800, Nuno Das Neves wrote:
> >> Introduce hv_counters.c, containing static data corresponding to
> >> HV_*_COUNTER enums in the hypervisor source. Defining the enum
> >> members as an array instead makes more sense, since it will be
> >> iterated over to print counter information to debugfs.
> >>
> >> Include hypervisor, logical processor, partition, and virtual
> >> processor counters.
> >>
> >> Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
> >> ---
> >> drivers/hv/hv_counters.c | 488 +++++++++++++++++++++++++++++++++++++++
> >> 1 file changed, 488 insertions(+)
> >> create mode 100644 drivers/hv/hv_counters.c
> >>
> >> diff --git a/drivers/hv/hv_counters.c b/drivers/hv/hv_counters.c
> >> new file mode 100644
> >> index 000000000000..a8e07e72cc29
> >> --- /dev/null
> >> +++ b/drivers/hv/hv_counters.c
> >> @@ -0,0 +1,488 @@
> >> +// SPDX-License-Identifier: GPL-2.0-only
> >> +/*
> >> + * Copyright (c) 2026, Microsoft Corporation.
> >> + *
> >> + * Data for printing stats page counters via debugfs.
> >> + *
> >> + * Authors: Microsoft Linux virtualization team
> >> + */
> >> +
> >> +struct hv_counter_entry {
> >> + char *name;
> >> + int idx;
> >> +};
> >
> > This structure looks redundant to me mostly because of the "idx".
> > It looks what you need here is an arry of pointers to strings, like
> > below:
> >
> > static const char *hv_hypervisor_counters[] = {
> > NULL, /* 0 is unused */
> > "HvLogicalProcessors",
> > "HvPartitions",
> > "HvTotalPages",
> > "HvVirtualProcessors",
> > "HvMonitoredNotifications",
> > "HvModernStandbyEntries",
> > "HvPlatformIdleTransitions",
> > "HvHypervisorStartupCost",
> > NULL, /* 9 is unused */
> > "HvIOSpacePages",
> > ...
> > };
> >
> > which can be iterated like this:
> >
> > for (idx = 0; idx < ARRAY_SIZE(hv_hypervisor_counters); idx++) {
> > const char *name = hv_hypervisor_counters[idx];
> > if (!name)
> > continue;
> > /* print */
> > ...
> > }
> >
> > What do you think?
>
> It's an elegant option, given the values are almost uniformly
> tightly packed. It also saves a fair bit of space - around 2.5Kb.
>
> For my taste, I do like being able to visually verify the
> correctness of any given member. That way whenever I look at it, I
> don't have to blindly trust that the list was previously set up
> correctly, or count the lines to check if a given value is correct.
> Not a big deal, but it does introduce some friction.
>
> We could also use a designated initializer list:
>
> static const char *hv_hypervisor_counters[] = {
> [1] = "HvLogicalProcessors",
> [2] = "HvPartitions",
> [3] = "HvTotalPages",
> [4] = "HvVirtualProcessors",
> [5] = "HvMonitoredNotifications",
> [6] = "HvModernStandbyEntries",
> [7] = "HvPlatformIdleTransitions",
> [8] = "HvHypervisorStartupCost",
>
> [10] = "HvIOSpacePages",
> ...
> };
>
> The indices are explicit, so it's easy to visually verify that any
> particular part of the list is correct. It's functionally identical
> to your approach, so it saves the same amount of space, and the
> explicit NULLs are unnecessary so it's more straightforward to
> transform from the Windows source in case of any gaps that are
> harder to notice later on in the list.
>
> How does that sound?
>
> Nuno
That's pretty nice and checks all the boxes. +1 for me.
FYI, I have some additional comments coming for the overall
series -- hope to have those posted tomorrow at the latest.
Michael
>
> >
> > Thanks,
> > Stanislav
> >
> >> +
> >> +/* HV_HYPERVISOR_COUNTER */
> >> +static struct hv_counter_entry hv_hypervisor_counters[] = {
> >> + { "HvLogicalProcessors", 1 },
> >> + { "HvPartitions", 2 },
> >> + { "HvTotalPages", 3 },
> >> + { "HvVirtualProcessors", 4 },
> >> + { "HvMonitoredNotifications", 5 },
> >> + { "HvModernStandbyEntries", 6 },
> >> + { "HvPlatformIdleTransitions", 7 },
> >> + { "HvHypervisorStartupCost", 8 },
> >> +
> >> + { "HvIOSpacePages", 10 },
> >> + { "HvNonEssentialPagesForDump", 11 },
> >> + { "HvSubsumedPages", 12 },
> >> +};
> >> +
> >> +/* HV_CPU_COUNTER */
> >> +static struct hv_counter_entry hv_lp_counters[] = {
> >> + { "LpGlobalTime", 1 },
> >> + { "LpTotalRunTime", 2 },
> >> + { "LpHypervisorRunTime", 3 },
> >> + { "LpHardwareInterrupts", 4 },
> >> + { "LpContextSwitches", 5 },
> >> + { "LpInterProcessorInterrupts", 6 },
> >> + { "LpSchedulerInterrupts", 7 },
> >> + { "LpTimerInterrupts", 8 },
> >> + { "LpInterProcessorInterruptsSent", 9 },
> >> + { "LpProcessorHalts", 10 },
> >> + { "LpMonitorTransitionCost", 11 },
> >> + { "LpContextSwitchTime", 12 },
> >> + { "LpC1TransitionsCount", 13 },
> >> + { "LpC1RunTime", 14 },
> >> + { "LpC2TransitionsCount", 15 },
> >> + { "LpC2RunTime", 16 },
> >> + { "LpC3TransitionsCount", 17 },
> >> + { "LpC3RunTime", 18 },
> >> + { "LpRootVpIndex", 19 },
> >> + { "LpIdleSequenceNumber", 20 },
> >> + { "LpGlobalTscCount", 21 },
> >> + { "LpActiveTscCount", 22 },
> >> + { "LpIdleAccumulation", 23 },
> >> + { "LpReferenceCycleCount0", 24 },
> >> + { "LpActualCycleCount0", 25 },
> >> + { "LpReferenceCycleCount1", 26 },
> >> + { "LpActualCycleCount1", 27 },
> >> + { "LpProximityDomainId", 28 },
> >> + { "LpPostedInterruptNotifications", 29 },
> >> + { "LpBranchPredictorFlushes", 30 },
> >> +#if IS_ENABLED(CONFIG_X86_64)
> >> + { "LpL1DataCacheFlushes", 31 },
> >> + { "LpImmediateL1DataCacheFlushes", 32 },
> >> + { "LpMbFlushes", 33 },
> >> + { "LpCounterRefreshSequenceNumber", 34 },
> >> + { "LpCounterRefreshReferenceTime", 35 },
> >> + { "LpIdleAccumulationSnapshot", 36 },
> >> + { "LpActiveTscCountSnapshot", 37 },
> >> + { "LpHwpRequestContextSwitches", 38 },
> >> + { "LpPlaceholder1", 39 },
> >> + { "LpPlaceholder2", 40 },
> >> + { "LpPlaceholder3", 41 },
> >> + { "LpPlaceholder4", 42 },
> >> + { "LpPlaceholder5", 43 },
> >> + { "LpPlaceholder6", 44 },
> >> + { "LpPlaceholder7", 45 },
> >> + { "LpPlaceholder8", 46 },
> >> + { "LpPlaceholder9", 47 },
> >> + { "LpSchLocalRunListSize", 48 },
> >> + { "LpReserveGroupId", 49 },
> >> + { "LpRunningPriority", 50 },
> >> + { "LpPerfmonInterruptCount", 51 },
> >> +#elif IS_ENABLED(CONFIG_ARM64)
> >> + { "LpCounterRefreshSequenceNumber", 31 },
> >> + { "LpCounterRefreshReferenceTime", 32 },
> >> + { "LpIdleAccumulationSnapshot", 33 },
> >> + { "LpActiveTscCountSnapshot", 34 },
> >> + { "LpHwpRequestContextSwitches", 35 },
> >> + { "LpPlaceholder2", 36 },
> >> + { "LpPlaceholder3", 37 },
> >> + { "LpPlaceholder4", 38 },
> >> + { "LpPlaceholder5", 39 },
> >> + { "LpPlaceholder6", 40 },
> >> + { "LpPlaceholder7", 41 },
> >> + { "LpPlaceholder8", 42 },
> >> + { "LpPlaceholder9", 43 },
> >> + { "LpSchLocalRunListSize", 44 },
> >> + { "LpReserveGroupId", 45 },
> >> + { "LpRunningPriority", 46 },
> >> +#endif
> >> +};
> >> +
> >> +/* HV_PROCESS_COUNTER */
> >> +static struct hv_counter_entry hv_partition_counters[] = {
> >> + { "PtVirtualProcessors", 1 },
> >> +
> >> + { "PtTlbSize", 3 },
> >> + { "PtAddressSpaces", 4 },
> >> + { "PtDepositedPages", 5 },
> >> + { "PtGpaPages", 6 },
> >> + { "PtGpaSpaceModifications", 7 },
> >> + { "PtVirtualTlbFlushEntires", 8 },
> >> + { "PtRecommendedTlbSize", 9 },
> >> + { "PtGpaPages4K", 10 },
> >> + { "PtGpaPages2M", 11 },
> >> + { "PtGpaPages1G", 12 },
> >> + { "PtGpaPages512G", 13 },
> >> + { "PtDevicePages4K", 14 },
> >> + { "PtDevicePages2M", 15 },
> >> + { "PtDevicePages1G", 16 },
> >> + { "PtDevicePages512G", 17 },
> >> + { "PtAttachedDevices", 18 },
> >> + { "PtDeviceInterruptMappings", 19 },
> >> + { "PtIoTlbFlushes", 20 },
> >> + { "PtIoTlbFlushCost", 21 },
> >> + { "PtDeviceInterruptErrors", 22 },
> >> + { "PtDeviceDmaErrors", 23 },
> >> + { "PtDeviceInterruptThrottleEvents", 24 },
> >> + { "PtSkippedTimerTicks", 25 },
> >> + { "PtPartitionId", 26 },
> >> +#if IS_ENABLED(CONFIG_X86_64)
> >> + { "PtNestedTlbSize", 27 },
> >> + { "PtRecommendedNestedTlbSize", 28 },
> >> + { "PtNestedTlbFreeListSize", 29 },
> >> + { "PtNestedTlbTrimmedPages", 30 },
> >> + { "PtPagesShattered", 31 },
> >> + { "PtPagesRecombined", 32 },
> >> + { "PtHwpRequestValue", 33 },
> >> + { "PtAutoSuspendEnableTime", 34 },
> >> + { "PtAutoSuspendTriggerTime", 35 },
> >> + { "PtAutoSuspendDisableTime", 36 },
> >> + { "PtPlaceholder1", 37 },
> >> + { "PtPlaceholder2", 38 },
> >> + { "PtPlaceholder3", 39 },
> >> + { "PtPlaceholder4", 40 },
> >> + { "PtPlaceholder5", 41 },
> >> + { "PtPlaceholder6", 42 },
> >> + { "PtPlaceholder7", 43 },
> >> + { "PtPlaceholder8", 44 },
> >> + { "PtHypervisorStateTransferGeneration", 45 },
> >> + { "PtNumberofActiveChildPartitions", 46 },
> >> +#elif IS_ENABLED(CONFIG_ARM64)
> >> + { "PtHwpRequestValue", 27 },
> >> + { "PtAutoSuspendEnableTime", 28 },
> >> + { "PtAutoSuspendTriggerTime", 29 },
> >> + { "PtAutoSuspendDisableTime", 30 },
> >> + { "PtPlaceholder1", 31 },
> >> + { "PtPlaceholder2", 32 },
> >> + { "PtPlaceholder3", 33 },
> >> + { "PtPlaceholder4", 34 },
> >> + { "PtPlaceholder5", 35 },
> >> + { "PtPlaceholder6", 36 },
> >> + { "PtPlaceholder7", 37 },
> >> + { "PtPlaceholder8", 38 },
> >> + { "PtHypervisorStateTransferGeneration", 39 },
> >> + { "PtNumberofActiveChildPartitions", 40 },
> >> +#endif
> >> +};
> >> +
> >> +/* HV_THREAD_COUNTER */
> >> +static struct hv_counter_entry hv_vp_counters[] = {
> >> + { "VpTotalRunTime", 1 },
> >> + { "VpHypervisorRunTime", 2 },
> >> + { "VpRemoteNodeRunTime", 3 },
> >> + { "VpNormalizedRunTime", 4 },
> >> + { "VpIdealCpu", 5 },
> >> +
> >> + { "VpHypercallsCount", 7 },
> >> + { "VpHypercallsTime", 8 },
> >> +#if IS_ENABLED(CONFIG_X86_64)
> >> + { "VpPageInvalidationsCount", 9 },
> >> + { "VpPageInvalidationsTime", 10 },
> >> + { "VpControlRegisterAccessesCount", 11 },
> >> + { "VpControlRegisterAccessesTime", 12 },
> >> + { "VpIoInstructionsCount", 13 },
> >> + { "VpIoInstructionsTime", 14 },
> >> + { "VpHltInstructionsCount", 15 },
> >> + { "VpHltInstructionsTime", 16 },
> >> + { "VpMwaitInstructionsCount", 17 },
> >> + { "VpMwaitInstructionsTime", 18 },
> >> + { "VpCpuidInstructionsCount", 19 },
> >> + { "VpCpuidInstructionsTime", 20 },
> >> + { "VpMsrAccessesCount", 21 },
> >> + { "VpMsrAccessesTime", 22 },
> >> + { "VpOtherInterceptsCount", 23 },
> >> + { "VpOtherInterceptsTime", 24 },
> >> + { "VpExternalInterruptsCount", 25 },
> >> + { "VpExternalInterruptsTime", 26 },
> >> + { "VpPendingInterruptsCount", 27 },
> >> + { "VpPendingInterruptsTime", 28 },
> >> + { "VpEmulatedInstructionsCount", 29 },
> >> + { "VpEmulatedInstructionsTime", 30 },
> >> + { "VpDebugRegisterAccessesCount", 31 },
> >> + { "VpDebugRegisterAccessesTime", 32 },
> >> + { "VpPageFaultInterceptsCount", 33 },
> >> + { "VpPageFaultInterceptsTime", 34 },
> >> + { "VpGuestPageTableMaps", 35 },
> >> + { "VpLargePageTlbFills", 36 },
> >> + { "VpSmallPageTlbFills", 37 },
> >> + { "VpReflectedGuestPageFaults", 38 },
> >> + { "VpApicMmioAccesses", 39 },
> >> + { "VpIoInterceptMessages", 40 },
> >> + { "VpMemoryInterceptMessages", 41 },
> >> + { "VpApicEoiAccesses", 42 },
> >> + { "VpOtherMessages", 43 },
> >> + { "VpPageTableAllocations", 44 },
> >> + { "VpLogicalProcessorMigrations", 45 },
> >> + { "VpAddressSpaceEvictions", 46 },
> >> + { "VpAddressSpaceSwitches", 47 },
> >> + { "VpAddressDomainFlushes", 48 },
> >> + { "VpAddressSpaceFlushes", 49 },
> >> + { "VpGlobalGvaRangeFlushes", 50 },
> >> + { "VpLocalGvaRangeFlushes", 51 },
> >> + { "VpPageTableEvictions", 52 },
> >> + { "VpPageTableReclamations", 53 },
> >> + { "VpPageTableResets", 54 },
> >> + { "VpPageTableValidations", 55 },
> >> + { "VpApicTprAccesses", 56 },
> >> + { "VpPageTableWriteIntercepts", 57 },
> >> + { "VpSyntheticInterrupts", 58 },
> >> + { "VpVirtualInterrupts", 59 },
> >> + { "VpApicIpisSent", 60 },
> >> + { "VpApicSelfIpisSent", 61 },
> >> + { "VpGpaSpaceHypercalls", 62 },
> >> + { "VpLogicalProcessorHypercalls", 63 },
> >> + { "VpLongSpinWaitHypercalls", 64 },
> >> + { "VpOtherHypercalls", 65 },
> >> + { "VpSyntheticInterruptHypercalls", 66 },
> >> + { "VpVirtualInterruptHypercalls", 67 },
> >> + { "VpVirtualMmuHypercalls", 68 },
> >> + { "VpVirtualProcessorHypercalls", 69 },
> >> + { "VpHardwareInterrupts", 70 },
> >> + { "VpNestedPageFaultInterceptsCount", 71 },
> >> + { "VpNestedPageFaultInterceptsTime", 72 },
> >> + { "VpPageScans", 73 },
> >> + { "VpLogicalProcessorDispatches", 74 },
> >> + { "VpWaitingForCpuTime", 75 },
> >> + { "VpExtendedHypercalls", 76 },
> >> + { "VpExtendedHypercallInterceptMessages", 77 },
> >> + { "VpMbecNestedPageTableSwitches", 78 },
> >> + { "VpOtherReflectedGuestExceptions", 79 },
> >> + { "VpGlobalIoTlbFlushes", 80 },
> >> + { "VpGlobalIoTlbFlushCost", 81 },
> >> + { "VpLocalIoTlbFlushes", 82 },
> >> + { "VpLocalIoTlbFlushCost", 83 },
> >> + { "VpHypercallsForwardedCount", 84 },
> >> + { "VpHypercallsForwardingTime", 85 },
> >> + { "VpPageInvalidationsForwardedCount", 86 },
> >> + { "VpPageInvalidationsForwardingTime", 87 },
> >> + { "VpControlRegisterAccessesForwardedCount", 88 },
> >> + { "VpControlRegisterAccessesForwardingTime", 89 },
> >> + { "VpIoInstructionsForwardedCount", 90 },
> >> + { "VpIoInstructionsForwardingTime", 91 },
> >> + { "VpHltInstructionsForwardedCount", 92 },
> >> + { "VpHltInstructionsForwardingTime", 93 },
> >> + { "VpMwaitInstructionsForwardedCount", 94 },
> >> + { "VpMwaitInstructionsForwardingTime", 95 },
> >> + { "VpCpuidInstructionsForwardedCount", 96 },
> >> + { "VpCpuidInstructionsForwardingTime", 97 },
> >> + { "VpMsrAccessesForwardedCount", 98 },
> >> + { "VpMsrAccessesForwardingTime", 99 },
> >> + { "VpOtherInterceptsForwardedCount", 100 },
> >> + { "VpOtherInterceptsForwardingTime", 101 },
> >> + { "VpExternalInterruptsForwardedCount", 102 },
> >> + { "VpExternalInterruptsForwardingTime", 103 },
> >> + { "VpPendingInterruptsForwardedCount", 104 },
> >> + { "VpPendingInterruptsForwardingTime", 105 },
> >> + { "VpEmulatedInstructionsForwardedCount", 106 },
> >> + { "VpEmulatedInstructionsForwardingTime", 107 },
> >> + { "VpDebugRegisterAccessesForwardedCount", 108 },
> >> + { "VpDebugRegisterAccessesForwardingTime", 109 },
> >> + { "VpPageFaultInterceptsForwardedCount", 110 },
> >> + { "VpPageFaultInterceptsForwardingTime", 111 },
> >> + { "VpVmclearEmulationCount", 112 },
> >> + { "VpVmclearEmulationTime", 113 },
> >> + { "VpVmptrldEmulationCount", 114 },
> >> + { "VpVmptrldEmulationTime", 115 },
> >> + { "VpVmptrstEmulationCount", 116 },
> >> + { "VpVmptrstEmulationTime", 117 },
> >> + { "VpVmreadEmulationCount", 118 },
> >> + { "VpVmreadEmulationTime", 119 },
> >> + { "VpVmwriteEmulationCount", 120 },
> >> + { "VpVmwriteEmulationTime", 121 },
> >> + { "VpVmxoffEmulationCount", 122 },
> >> + { "VpVmxoffEmulationTime", 123 },
> >> + { "VpVmxonEmulationCount", 124 },
> >> + { "VpVmxonEmulationTime", 125 },
> >> + { "VpNestedVMEntriesCount", 126 },
> >> + { "VpNestedVMEntriesTime", 127 },
> >> + { "VpNestedSLATSoftPageFaultsCount", 128 },
> >> + { "VpNestedSLATSoftPageFaultsTime", 129 },
> >> + { "VpNestedSLATHardPageFaultsCount", 130 },
> >> + { "VpNestedSLATHardPageFaultsTime", 131 },
> >> + { "VpInvEptAllContextEmulationCount", 132 },
> >> + { "VpInvEptAllContextEmulationTime", 133 },
> >> + { "VpInvEptSingleContextEmulationCount", 134 },
> >> + { "VpInvEptSingleContextEmulationTime", 135 },
> >> + { "VpInvVpidAllContextEmulationCount", 136 },
> >> + { "VpInvVpidAllContextEmulationTime", 137 },
> >> + { "VpInvVpidSingleContextEmulationCount", 138 },
> >> + { "VpInvVpidSingleContextEmulationTime", 139 },
> >> + { "VpInvVpidSingleAddressEmulationCount", 140 },
> >> + { "VpInvVpidSingleAddressEmulationTime", 141 },
> >> + { "VpNestedTlbPageTableReclamations", 142 },
> >> + { "VpNestedTlbPageTableEvictions", 143 },
> >> + { "VpFlushGuestPhysicalAddressSpaceHypercalls", 144 },
> >> + { "VpFlushGuestPhysicalAddressListHypercalls", 145 },
> >> + { "VpPostedInterruptNotifications", 146 },
> >> + { "VpPostedInterruptScans", 147 },
> >> + { "VpTotalCoreRunTime", 148 },
> >> + { "VpMaximumRunTime", 149 },
> >> + { "VpHwpRequestContextSwitches", 150 },
> >> + { "VpWaitingForCpuTimeBucket0", 151 },
> >> + { "VpWaitingForCpuTimeBucket1", 152 },
> >> + { "VpWaitingForCpuTimeBucket2", 153 },
> >> + { "VpWaitingForCpuTimeBucket3", 154 },
> >> + { "VpWaitingForCpuTimeBucket4", 155 },
> >> + { "VpWaitingForCpuTimeBucket5", 156 },
> >> + { "VpWaitingForCpuTimeBucket6", 157 },
> >> + { "VpVmloadEmulationCount", 158 },
> >> + { "VpVmloadEmulationTime", 159 },
> >> + { "VpVmsaveEmulationCount", 160 },
> >> + { "VpVmsaveEmulationTime", 161 },
> >> + { "VpGifInstructionEmulationCount", 162 },
> >> + { "VpGifInstructionEmulationTime", 163 },
> >> + { "VpEmulatedErrataSvmInstructions", 164 },
> >> + { "VpPlaceholder1", 165 },
> >> + { "VpPlaceholder2", 166 },
> >> + { "VpPlaceholder3", 167 },
> >> + { "VpPlaceholder4", 168 },
> >> + { "VpPlaceholder5", 169 },
> >> + { "VpPlaceholder6", 170 },
> >> + { "VpPlaceholder7", 171 },
> >> + { "VpPlaceholder8", 172 },
> >> + { "VpContentionTime", 173 },
> >> + { "VpWakeUpTime", 174 },
> >> + { "VpSchedulingPriority", 175 },
> >> + { "VpRdpmcInstructionsCount", 176 },
> >> + { "VpRdpmcInstructionsTime", 177 },
> >> + { "VpPerfmonPmuMsrAccessesCount", 178 },
> >> + { "VpPerfmonLbrMsrAccessesCount", 179 },
> >> + { "VpPerfmonIptMsrAccessesCount", 180 },
> >> + { "VpPerfmonInterruptCount", 181 },
> >> + { "VpVtl1DispatchCount", 182 },
> >> + { "VpVtl2DispatchCount", 183 },
> >> + { "VpVtl2DispatchBucket0", 184 },
> >> + { "VpVtl2DispatchBucket1", 185 },
> >> + { "VpVtl2DispatchBucket2", 186 },
> >> + { "VpVtl2DispatchBucket3", 187 },
> >> + { "VpVtl2DispatchBucket4", 188 },
> >> + { "VpVtl2DispatchBucket5", 189 },
> >> + { "VpVtl2DispatchBucket6", 190 },
> >> + { "VpVtl1RunTime", 191 },
> >> + { "VpVtl2RunTime", 192 },
> >> + { "VpIommuHypercalls", 193 },
> >> + { "VpCpuGroupHypercalls", 194 },
> >> + { "VpVsmHypercalls", 195 },
> >> + { "VpEventLogHypercalls", 196 },
> >> + { "VpDeviceDomainHypercalls", 197 },
> >> + { "VpDepositHypercalls", 198 },
> >> + { "VpSvmHypercalls", 199 },
> >> + { "VpBusLockAcquisitionCount", 200 },
> >> + { "VpLoadAvg", 201 },
> >> + { "VpRootDispatchThreadBlocked", 202 },
> >> + { "VpIdleCpuTime", 203 },
> >> + { "VpWaitingForCpuTimeBucket7", 204 },
> >> + { "VpWaitingForCpuTimeBucket8", 205 },
> >> + { "VpWaitingForCpuTimeBucket9", 206 },
> >> + { "VpWaitingForCpuTimeBucket10", 207 },
> >> + { "VpWaitingForCpuTimeBucket11", 208 },
> >> + { "VpWaitingForCpuTimeBucket12", 209 },
> >> + { "VpHierarchicalSuspendTime", 210 },
> >> + { "VpExpressSchedulingAttempts", 211 },
> >> + { "VpExpressSchedulingCount", 212 },
> >> + { "VpBusLockAcquisitionTime", 213 },
> >> +#elif IS_ENABLED(CONFIG_ARM64)
> >> + { "VpSysRegAccessesCount", 9 },
> >> + { "VpSysRegAccessesTime", 10 },
> >> + { "VpSmcInstructionsCount", 11 },
> >> + { "VpSmcInstructionsTime", 12 },
> >> + { "VpOtherInterceptsCount", 13 },
> >> + { "VpOtherInterceptsTime", 14 },
> >> + { "VpExternalInterruptsCount", 15 },
> >> + { "VpExternalInterruptsTime", 16 },
> >> + { "VpPendingInterruptsCount", 17 },
> >> + { "VpPendingInterruptsTime", 18 },
> >> + { "VpGuestPageTableMaps", 19 },
> >> + { "VpLargePageTlbFills", 20 },
> >> + { "VpSmallPageTlbFills", 21 },
> >> + { "VpReflectedGuestPageFaults", 22 },
> >> + { "VpMemoryInterceptMessages", 23 },
> >> + { "VpOtherMessages", 24 },
> >> + { "VpLogicalProcessorMigrations", 25 },
> >> + { "VpAddressDomainFlushes", 26 },
> >> + { "VpAddressSpaceFlushes", 27 },
> >> + { "VpSyntheticInterrupts", 28 },
> >> + { "VpVirtualInterrupts", 29 },
> >> + { "VpApicSelfIpisSent", 30 },
> >> + { "VpGpaSpaceHypercalls", 31 },
> >> + { "VpLogicalProcessorHypercalls", 32 },
> >> + { "VpLongSpinWaitHypercalls", 33 },
> >> + { "VpOtherHypercalls", 34 },
> >> + { "VpSyntheticInterruptHypercalls", 35 },
> >> + { "VpVirtualInterruptHypercalls", 36 },
> >> + { "VpVirtualMmuHypercalls", 37 },
> >> + { "VpVirtualProcessorHypercalls", 38 },
> >> + { "VpHardwareInterrupts", 39 },
> >> + { "VpNestedPageFaultInterceptsCount", 40 },
> >> + { "VpNestedPageFaultInterceptsTime", 41 },
> >> + { "VpLogicalProcessorDispatches", 42 },
> >> + { "VpWaitingForCpuTime", 43 },
> >> + { "VpExtendedHypercalls", 44 },
> >> + { "VpExtendedHypercallInterceptMessages", 45 },
> >> + { "VpMbecNestedPageTableSwitches", 46 },
> >> + { "VpOtherReflectedGuestExceptions", 47 },
> >> + { "VpGlobalIoTlbFlushes", 48 },
> >> + { "VpGlobalIoTlbFlushCost", 49 },
> >> + { "VpLocalIoTlbFlushes", 50 },
> >> + { "VpLocalIoTlbFlushCost", 51 },
> >> + { "VpFlushGuestPhysicalAddressSpaceHypercalls", 52 },
> >> + { "VpFlushGuestPhysicalAddressListHypercalls", 53 },
> >> + { "VpPostedInterruptNotifications", 54 },
> >> + { "VpPostedInterruptScans", 55 },
> >> + { "VpTotalCoreRunTime", 56 },
> >> + { "VpMaximumRunTime", 57 },
> >> + { "VpWaitingForCpuTimeBucket0", 58 },
> >> + { "VpWaitingForCpuTimeBucket1", 59 },
> >> + { "VpWaitingForCpuTimeBucket2", 60 },
> >> + { "VpWaitingForCpuTimeBucket3", 61 },
> >> + { "VpWaitingForCpuTimeBucket4", 62 },
> >> + { "VpWaitingForCpuTimeBucket5", 63 },
> >> + { "VpWaitingForCpuTimeBucket6", 64 },
> >> + { "VpHwpRequestContextSwitches", 65 },
> >> + { "VpPlaceholder2", 66 },
> >> + { "VpPlaceholder3", 67 },
> >> + { "VpPlaceholder4", 68 },
> >> + { "VpPlaceholder5", 69 },
> >> + { "VpPlaceholder6", 70 },
> >> + { "VpPlaceholder7", 71 },
> >> + { "VpPlaceholder8", 72 },
> >> + { "VpContentionTime", 73 },
> >> + { "VpWakeUpTime", 74 },
> >> + { "VpSchedulingPriority", 75 },
> >> + { "VpVtl1DispatchCount", 76 },
> >> + { "VpVtl2DispatchCount", 77 },
> >> + { "VpVtl2DispatchBucket0", 78 },
> >> + { "VpVtl2DispatchBucket1", 79 },
> >> + { "VpVtl2DispatchBucket2", 80 },
> >> + { "VpVtl2DispatchBucket3", 81 },
> >> + { "VpVtl2DispatchBucket4", 82 },
> >> + { "VpVtl2DispatchBucket5", 83 },
> >> + { "VpVtl2DispatchBucket6", 84 },
> >> + { "VpVtl1RunTime", 85 },
> >> + { "VpVtl2RunTime", 86 },
> >> + { "VpIommuHypercalls", 87 },
> >> + { "VpCpuGroupHypercalls", 88 },
> >> + { "VpVsmHypercalls", 89 },
> >> + { "VpEventLogHypercalls", 90 },
> >> + { "VpDeviceDomainHypercalls", 91 },
> >> + { "VpDepositHypercalls", 92 },
> >> + { "VpSvmHypercalls", 93 },
> >> + { "VpLoadAvg", 94 },
> >> + { "VpRootDispatchThreadBlocked", 95 },
> >> + { "VpIdleCpuTime", 96 },
> >> + { "VpWaitingForCpuTimeBucket7", 97 },
> >> + { "VpWaitingForCpuTimeBucket8", 98 },
> >> + { "VpWaitingForCpuTimeBucket9", 99 },
> >> + { "VpWaitingForCpuTimeBucket10", 100 },
> >> + { "VpWaitingForCpuTimeBucket11", 101 },
> >> + { "VpWaitingForCpuTimeBucket12", 102 },
> >> + { "VpHierarchicalSuspendTime", 103 },
> >> + { "VpExpressSchedulingAttempts", 104 },
> >> + { "VpExpressSchedulingCount", 105 },
> >> +#endif
> >> +};
> >> +
> >> --
> >> 2.34.1
^ permalink raw reply
* Re: [PATCH net-next v2 0/9] net: convert drivers to .get_rx_ring_count (last part)
From: Creeley, Brett @ 2026-01-22 18:50 UTC (permalink / raw)
To: Breno Leitao, Ajit Khaparde, Sriharsha Basavapatna, Somnath Kotur,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Igor Russkikh, Simon Horman, K. Y. Srinivasan,
Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li, Alexander Duyck,
kernel-team, Edward Cree, Brett Creeley
Cc: netdev, linux-kernel, oss-drivers, linux-hyperv,
linux-net-drivers, Subbaraya Sundeep
In-Reply-To: <20260122-grxring_big_v4-v2-0-94dbe4dcaa10@debian.org>
On 1/22/2026 10:40 AM, Breno Leitao wrote:
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
>
>
> Commit 84eaf4359c36 ("net: ethtool: add get_rx_ring_count callback to
> optimize RX ring queries") added specific support for GRXRINGS callback,
> simplifying .get_rxnfc.
>
> Remove the handling of GRXRINGS in .get_rxnfc() by moving it to the new
> .get_rx_ring_count().
>
> This simplifies the RX ring count retrieval and aligns the following
> drivers with the new ethtool API for querying RX ring parameters.
>
> * sfc
> * ionic
> * sfc/siena
> * sfc/ef100
> * fbnic
> * mana
> * nfp
> * atlantic
> * benet (this is v2 in fact, where v1 had some discussions that
> required a v2). See link [0]
>
> Link: https://lore.kernel.org/all/20260119094514.5b12a097@kernel.org/ [0]
>
> This is covering the last drivers, and as soon as this lands, I will
> change the ethtool framework to avoid calling .get_rx_ring_count for
> ETHTOOL_GRXRINGS, simplifying the ethtool core framework.
>
> Part 1 is already merged in net-next and can be seen in
> https://lore.kernel.org/all/20260109-grxring_big_v1-v1-0-a0f77f732006@debian.org/
>
> Part 2 is already merged in net-next except benet driver, which is now included
> in here
> https://lore.kernel.org/all/20260115-grxring_big_v2-v1-0-b3e1b58bced5@debian.org/
>
> PS: all of these change were compile-tested only.
>
> Signed-off-by: Breno Leitao <leitao@debian.org>
> ---
> Changes in v2:
> - Respect reverse xmas tree in Atlantic driver (Brett Creeley)
> - Link to v1: https://patch.msgid.link/20260121-grxring_big_v4-v1-0-07655be56bcf@debian.org
>
> ---
> Breno Leitao (9):
> net: benet: convert to use .get_rx_ring_count
> net: atlantic: convert to use .get_rx_ring_count
> net: nfp: convert to use .get_rx_ring_count
> net: mana: convert to use .get_rx_ring_count
> net: fbnic: convert to use .get_rx_ring_count
> net: ionic: convert to use .get_rx_ring_count
> net: sfc: efx: convert to use .get_rx_ring_count
> net: sfc: siena: convert to use .get_rx_ring_count
> net: sfc: falcon: convert to use .get_rx_ring_count
>
> .../net/ethernet/aquantia/atlantic/aq_ethtool.c | 18 +++++++----
> drivers/net/ethernet/emulex/benet/be_ethtool.c | 37 ++++++++--------------
> drivers/net/ethernet/meta/fbnic/fbnic_ethtool.c | 12 ++++---
> drivers/net/ethernet/microsoft/mana/mana_ethtool.c | 13 ++------
> .../net/ethernet/netronome/nfp/nfp_net_ethtool.c | 11 +++++--
> .../net/ethernet/pensando/ionic/ionic_ethtool.c | 18 ++---------
> drivers/net/ethernet/sfc/ef100_ethtool.c | 1 +
> drivers/net/ethernet/sfc/ethtool.c | 1 +
> drivers/net/ethernet/sfc/ethtool_common.c | 11 ++++---
> drivers/net/ethernet/sfc/ethtool_common.h | 1 +
> drivers/net/ethernet/sfc/falcon/ethtool.c | 12 ++++---
> drivers/net/ethernet/sfc/siena/ethtool.c | 1 +
> drivers/net/ethernet/sfc/siena/ethtool_common.c | 11 ++++---
> drivers/net/ethernet/sfc/siena/ethtool_common.h | 1 +
> 14 files changed, 75 insertions(+), 73 deletions(-)
> ---
> base-commit: d8f87aa5fa0a4276491fa8ef436cd22605a3f9ba
> change-id: 20260121-grxring_big_v4-55037f9e001e
>
> Best regards,
> --
> Breno Leitao <leitao@debian.org>
Entire series LGTM.
Reviewed-by: Brett Creeley <brett.creeley@amd.com>
>
^ permalink raw reply
* [PATCH net-next v2 9/9] net: sfc: falcon: convert to use .get_rx_ring_count
From: Breno Leitao @ 2026-01-22 18:40 UTC (permalink / raw)
To: Ajit Khaparde, Sriharsha Basavapatna, Somnath Kotur, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Igor Russkikh, Simon Horman, K. Y. Srinivasan, Haiyang Zhang,
Wei Liu, Dexuan Cui, Long Li, Alexander Duyck, kernel-team,
Edward Cree, Brett Creeley
Cc: netdev, linux-kernel, oss-drivers, linux-hyperv,
linux-net-drivers, Breno Leitao
In-Reply-To: <20260122-grxring_big_v4-v2-0-94dbe4dcaa10@debian.org>
Use the newly introduced .get_rx_ring_count ethtool ops callback instead
of handling ETHTOOL_GRXRINGS directly in .get_rxnfc().
Signed-off-by: Breno Leitao <leitao@debian.org>
---
drivers/net/ethernet/sfc/falcon/ethtool.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/sfc/falcon/ethtool.c b/drivers/net/ethernet/sfc/falcon/ethtool.c
index 27d1cd6f24ca1..0493640315454 100644
--- a/drivers/net/ethernet/sfc/falcon/ethtool.c
+++ b/drivers/net/ethernet/sfc/falcon/ethtool.c
@@ -974,6 +974,13 @@ ef4_ethtool_get_rxfh_fields(struct net_device *net_dev,
return 0;
}
+static u32 ef4_ethtool_get_rx_ring_count(struct net_device *net_dev)
+{
+ struct ef4_nic *efx = netdev_priv(net_dev);
+
+ return efx->n_rx_channels;
+}
+
static int
ef4_ethtool_get_rxnfc(struct net_device *net_dev,
struct ethtool_rxnfc *info, u32 *rule_locs)
@@ -981,10 +988,6 @@ ef4_ethtool_get_rxnfc(struct net_device *net_dev,
struct ef4_nic *efx = netdev_priv(net_dev);
switch (info->cmd) {
- case ETHTOOL_GRXRINGS:
- info->data = efx->n_rx_channels;
- return 0;
-
case ETHTOOL_GRXCLSRLCNT:
info->data = ef4_filter_get_rx_id_limit(efx);
if (info->data == 0)
@@ -1348,6 +1351,7 @@ const struct ethtool_ops ef4_ethtool_ops = {
.reset = ef4_ethtool_reset,
.get_rxnfc = ef4_ethtool_get_rxnfc,
.set_rxnfc = ef4_ethtool_set_rxnfc,
+ .get_rx_ring_count = ef4_ethtool_get_rx_ring_count,
.get_rxfh_indir_size = ef4_ethtool_get_rxfh_indir_size,
.get_rxfh = ef4_ethtool_get_rxfh,
.set_rxfh = ef4_ethtool_set_rxfh,
--
2.47.3
^ permalink raw reply related
* [PATCH net-next v2 8/9] net: sfc: siena: convert to use .get_rx_ring_count
From: Breno Leitao @ 2026-01-22 18:40 UTC (permalink / raw)
To: Ajit Khaparde, Sriharsha Basavapatna, Somnath Kotur, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Igor Russkikh, Simon Horman, K. Y. Srinivasan, Haiyang Zhang,
Wei Liu, Dexuan Cui, Long Li, Alexander Duyck, kernel-team,
Edward Cree, Brett Creeley
Cc: netdev, linux-kernel, oss-drivers, linux-hyperv,
linux-net-drivers, Breno Leitao
In-Reply-To: <20260122-grxring_big_v4-v2-0-94dbe4dcaa10@debian.org>
Use the newly introduced .get_rx_ring_count ethtool ops callback instead
of handling ETHTOOL_GRXRINGS directly in .get_rxnfc().
Signed-off-by: Breno Leitao <leitao@debian.org>
---
drivers/net/ethernet/sfc/siena/ethtool.c | 1 +
drivers/net/ethernet/sfc/siena/ethtool_common.c | 11 +++++++----
drivers/net/ethernet/sfc/siena/ethtool_common.h | 1 +
3 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/sfc/siena/ethtool.c b/drivers/net/ethernet/sfc/siena/ethtool.c
index 8c3ebd0617fb1..36feedffe4444 100644
--- a/drivers/net/ethernet/sfc/siena/ethtool.c
+++ b/drivers/net/ethernet/sfc/siena/ethtool.c
@@ -261,6 +261,7 @@ const struct ethtool_ops efx_siena_ethtool_ops = {
.reset = efx_siena_ethtool_reset,
.get_rxnfc = efx_siena_ethtool_get_rxnfc,
.set_rxnfc = efx_siena_ethtool_set_rxnfc,
+ .get_rx_ring_count = efx_siena_ethtool_get_rx_ring_count,
.get_rxfh_indir_size = efx_siena_ethtool_get_rxfh_indir_size,
.get_rxfh_key_size = efx_siena_ethtool_get_rxfh_key_size,
.get_rxfh = efx_siena_ethtool_get_rxfh,
diff --git a/drivers/net/ethernet/sfc/siena/ethtool_common.c b/drivers/net/ethernet/sfc/siena/ethtool_common.c
index 47cd16a113cf1..c56e0b54d8541 100644
--- a/drivers/net/ethernet/sfc/siena/ethtool_common.c
+++ b/drivers/net/ethernet/sfc/siena/ethtool_common.c
@@ -841,6 +841,13 @@ int efx_siena_ethtool_get_rxfh_fields(struct net_device *net_dev,
return 0;
}
+u32 efx_siena_ethtool_get_rx_ring_count(struct net_device *net_dev)
+{
+ struct efx_nic *efx = netdev_priv(net_dev);
+
+ return efx->n_rx_channels;
+}
+
int efx_siena_ethtool_get_rxnfc(struct net_device *net_dev,
struct ethtool_rxnfc *info, u32 *rule_locs)
{
@@ -849,10 +856,6 @@ int efx_siena_ethtool_get_rxnfc(struct net_device *net_dev,
s32 rc = 0;
switch (info->cmd) {
- case ETHTOOL_GRXRINGS:
- info->data = efx->n_rx_channels;
- return 0;
-
case ETHTOOL_GRXCLSRLCNT:
info->data = efx_filter_get_rx_id_limit(efx);
if (info->data == 0)
diff --git a/drivers/net/ethernet/sfc/siena/ethtool_common.h b/drivers/net/ethernet/sfc/siena/ethtool_common.h
index 278d69e920d9f..7b445b0ba38aa 100644
--- a/drivers/net/ethernet/sfc/siena/ethtool_common.h
+++ b/drivers/net/ethernet/sfc/siena/ethtool_common.h
@@ -37,6 +37,7 @@ int efx_siena_ethtool_set_fecparam(struct net_device *net_dev,
struct ethtool_fecparam *fecparam);
int efx_siena_ethtool_get_rxnfc(struct net_device *net_dev,
struct ethtool_rxnfc *info, u32 *rule_locs);
+u32 efx_siena_ethtool_get_rx_ring_count(struct net_device *net_dev);
int efx_siena_ethtool_set_rxnfc(struct net_device *net_dev,
struct ethtool_rxnfc *info);
u32 efx_siena_ethtool_get_rxfh_indir_size(struct net_device *net_dev);
--
2.47.3
^ permalink raw reply related
* [PATCH net-next v2 7/9] net: sfc: efx: convert to use .get_rx_ring_count
From: Breno Leitao @ 2026-01-22 18:40 UTC (permalink / raw)
To: Ajit Khaparde, Sriharsha Basavapatna, Somnath Kotur, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Igor Russkikh, Simon Horman, K. Y. Srinivasan, Haiyang Zhang,
Wei Liu, Dexuan Cui, Long Li, Alexander Duyck, kernel-team,
Edward Cree, Brett Creeley
Cc: netdev, linux-kernel, oss-drivers, linux-hyperv,
linux-net-drivers, Breno Leitao
In-Reply-To: <20260122-grxring_big_v4-v2-0-94dbe4dcaa10@debian.org>
Use the newly introduced .get_rx_ring_count ethtool ops callback instead
of handling ETHTOOL_GRXRINGS directly in .get_rxnfc().
Signed-off-by: Breno Leitao <leitao@debian.org>
---
drivers/net/ethernet/sfc/ef100_ethtool.c | 1 +
drivers/net/ethernet/sfc/ethtool.c | 1 +
drivers/net/ethernet/sfc/ethtool_common.c | 11 +++++++----
drivers/net/ethernet/sfc/ethtool_common.h | 1 +
4 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/sfc/ef100_ethtool.c b/drivers/net/ethernet/sfc/ef100_ethtool.c
index 6c3b74000d3b6..05dc7b10c8855 100644
--- a/drivers/net/ethernet/sfc/ef100_ethtool.c
+++ b/drivers/net/ethernet/sfc/ef100_ethtool.c
@@ -54,6 +54,7 @@ const struct ethtool_ops ef100_ethtool_ops = {
.get_ethtool_stats = efx_ethtool_get_stats,
.get_rxnfc = efx_ethtool_get_rxnfc,
.set_rxnfc = efx_ethtool_set_rxnfc,
+ .get_rx_ring_count = efx_ethtool_get_rx_ring_count,
.reset = efx_ethtool_reset,
.get_rxfh_indir_size = efx_ethtool_get_rxfh_indir_size,
diff --git a/drivers/net/ethernet/sfc/ethtool.c b/drivers/net/ethernet/sfc/ethtool.c
index 18fe5850a9786..362388754a292 100644
--- a/drivers/net/ethernet/sfc/ethtool.c
+++ b/drivers/net/ethernet/sfc/ethtool.c
@@ -261,6 +261,7 @@ const struct ethtool_ops efx_ethtool_ops = {
.reset = efx_ethtool_reset,
.get_rxnfc = efx_ethtool_get_rxnfc,
.set_rxnfc = efx_ethtool_set_rxnfc,
+ .get_rx_ring_count = efx_ethtool_get_rx_ring_count,
.get_rxfh_indir_size = efx_ethtool_get_rxfh_indir_size,
.get_rxfh_key_size = efx_ethtool_get_rxfh_key_size,
.rxfh_per_ctx_fields = true,
diff --git a/drivers/net/ethernet/sfc/ethtool_common.c b/drivers/net/ethernet/sfc/ethtool_common.c
index fa303e171d98b..2fc42b1a2bfb7 100644
--- a/drivers/net/ethernet/sfc/ethtool_common.c
+++ b/drivers/net/ethernet/sfc/ethtool_common.c
@@ -850,6 +850,13 @@ int efx_ethtool_get_rxfh_fields(struct net_device *net_dev,
return rc;
}
+u32 efx_ethtool_get_rx_ring_count(struct net_device *net_dev)
+{
+ struct efx_nic *efx = efx_netdev_priv(net_dev);
+
+ return efx->n_rx_channels;
+}
+
int efx_ethtool_get_rxnfc(struct net_device *net_dev,
struct ethtool_rxnfc *info, u32 *rule_locs)
{
@@ -858,10 +865,6 @@ int efx_ethtool_get_rxnfc(struct net_device *net_dev,
s32 rc = 0;
switch (info->cmd) {
- case ETHTOOL_GRXRINGS:
- info->data = efx->n_rx_channels;
- return 0;
-
case ETHTOOL_GRXCLSRLCNT:
info->data = efx_filter_get_rx_id_limit(efx);
if (info->data == 0)
diff --git a/drivers/net/ethernet/sfc/ethtool_common.h b/drivers/net/ethernet/sfc/ethtool_common.h
index 24db4fccbe78a..f96db42534546 100644
--- a/drivers/net/ethernet/sfc/ethtool_common.h
+++ b/drivers/net/ethernet/sfc/ethtool_common.h
@@ -40,6 +40,7 @@ int efx_ethtool_set_fecparam(struct net_device *net_dev,
struct ethtool_fecparam *fecparam);
int efx_ethtool_get_rxnfc(struct net_device *net_dev,
struct ethtool_rxnfc *info, u32 *rule_locs);
+u32 efx_ethtool_get_rx_ring_count(struct net_device *net_dev);
int efx_ethtool_set_rxnfc(struct net_device *net_dev,
struct ethtool_rxnfc *info);
u32 efx_ethtool_get_rxfh_indir_size(struct net_device *net_dev);
--
2.47.3
^ permalink raw reply related
* [PATCH net-next v2 6/9] net: ionic: convert to use .get_rx_ring_count
From: Breno Leitao @ 2026-01-22 18:40 UTC (permalink / raw)
To: Ajit Khaparde, Sriharsha Basavapatna, Somnath Kotur, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Igor Russkikh, Simon Horman, K. Y. Srinivasan, Haiyang Zhang,
Wei Liu, Dexuan Cui, Long Li, Alexander Duyck, kernel-team,
Edward Cree, Brett Creeley
Cc: netdev, linux-kernel, oss-drivers, linux-hyperv,
linux-net-drivers, Breno Leitao
In-Reply-To: <20260122-grxring_big_v4-v2-0-94dbe4dcaa10@debian.org>
Use the newly introduced .get_rx_ring_count ethtool ops callback instead
of handling ETHTOOL_GRXRINGS directly in .get_rxnfc().
Since ETHTOOL_GRXRINGS was the only command handled by ionic_get_rxnfc(),
remove the function entirely.
Reviewed-by: Brett Creeley <brett.creeley@amd.com>
Signed-off-by: Breno Leitao <leitao@debian.org>
---
drivers/net/ethernet/pensando/ionic/ionic_ethtool.c | 18 +++---------------
1 file changed, 3 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/pensando/ionic/ionic_ethtool.c b/drivers/net/ethernet/pensando/ionic/ionic_ethtool.c
index 2d9efadb5d2ae..b0a459eeaa640 100644
--- a/drivers/net/ethernet/pensando/ionic/ionic_ethtool.c
+++ b/drivers/net/ethernet/pensando/ionic/ionic_ethtool.c
@@ -843,23 +843,11 @@ static int ionic_set_channels(struct net_device *netdev,
return err;
}
-static int ionic_get_rxnfc(struct net_device *netdev,
- struct ethtool_rxnfc *info, u32 *rules)
+static u32 ionic_get_rx_ring_count(struct net_device *netdev)
{
struct ionic_lif *lif = netdev_priv(netdev);
- int err = 0;
-
- switch (info->cmd) {
- case ETHTOOL_GRXRINGS:
- info->data = lif->nxqs;
- break;
- default:
- netdev_dbg(netdev, "Command parameter %d is not supported\n",
- info->cmd);
- err = -EOPNOTSUPP;
- }
- return err;
+ return lif->nxqs;
}
static u32 ionic_get_rxfh_indir_size(struct net_device *netdev)
@@ -1152,7 +1140,7 @@ static const struct ethtool_ops ionic_ethtool_ops = {
.get_strings = ionic_get_strings,
.get_ethtool_stats = ionic_get_stats,
.get_sset_count = ionic_get_sset_count,
- .get_rxnfc = ionic_get_rxnfc,
+ .get_rx_ring_count = ionic_get_rx_ring_count,
.get_rxfh_indir_size = ionic_get_rxfh_indir_size,
.get_rxfh_key_size = ionic_get_rxfh_key_size,
.get_rxfh = ionic_get_rxfh,
--
2.47.3
^ permalink raw reply related
* [PATCH net-next v2 5/9] net: fbnic: convert to use .get_rx_ring_count
From: Breno Leitao @ 2026-01-22 18:40 UTC (permalink / raw)
To: Ajit Khaparde, Sriharsha Basavapatna, Somnath Kotur, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Igor Russkikh, Simon Horman, K. Y. Srinivasan, Haiyang Zhang,
Wei Liu, Dexuan Cui, Long Li, Alexander Duyck, kernel-team,
Edward Cree, Brett Creeley
Cc: netdev, linux-kernel, oss-drivers, linux-hyperv,
linux-net-drivers, Breno Leitao
In-Reply-To: <20260122-grxring_big_v4-v2-0-94dbe4dcaa10@debian.org>
Use the newly introduced .get_rx_ring_count ethtool ops callback instead
of handling ETHTOOL_GRXRINGS directly in .get_rxnfc().
Signed-off-by: Breno Leitao <leitao@debian.org>
---
drivers/net/ethernet/meta/fbnic/fbnic_ethtool.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/meta/fbnic/fbnic_ethtool.c b/drivers/net/ethernet/meta/fbnic/fbnic_ethtool.c
index 61b8005a0db5f..11745a2d8a443 100644
--- a/drivers/net/ethernet/meta/fbnic/fbnic_ethtool.c
+++ b/drivers/net/ethernet/meta/fbnic/fbnic_ethtool.c
@@ -825,6 +825,13 @@ static int fbnic_get_cls_rule(struct fbnic_net *fbn, struct ethtool_rxnfc *cmd)
return 0;
}
+static u32 fbnic_get_rx_ring_count(struct net_device *netdev)
+{
+ struct fbnic_net *fbn = netdev_priv(netdev);
+
+ return fbn->num_rx_queues;
+}
+
static int fbnic_get_rxnfc(struct net_device *netdev,
struct ethtool_rxnfc *cmd, u32 *rule_locs)
{
@@ -833,10 +840,6 @@ static int fbnic_get_rxnfc(struct net_device *netdev,
u32 special = 0;
switch (cmd->cmd) {
- case ETHTOOL_GRXRINGS:
- cmd->data = fbn->num_rx_queues;
- ret = 0;
- break;
case ETHTOOL_GRXCLSRULE:
ret = fbnic_get_cls_rule(fbn, cmd);
break;
@@ -1895,6 +1898,7 @@ static const struct ethtool_ops fbnic_ethtool_ops = {
.get_sset_count = fbnic_get_sset_count,
.get_rxnfc = fbnic_get_rxnfc,
.set_rxnfc = fbnic_set_rxnfc,
+ .get_rx_ring_count = fbnic_get_rx_ring_count,
.get_rxfh_key_size = fbnic_get_rxfh_key_size,
.get_rxfh_indir_size = fbnic_get_rxfh_indir_size,
.get_rxfh = fbnic_get_rxfh,
--
2.47.3
^ permalink raw reply related
* [PATCH net-next v2 4/9] net: mana: convert to use .get_rx_ring_count
From: Breno Leitao @ 2026-01-22 18:40 UTC (permalink / raw)
To: Ajit Khaparde, Sriharsha Basavapatna, Somnath Kotur, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Igor Russkikh, Simon Horman, K. Y. Srinivasan, Haiyang Zhang,
Wei Liu, Dexuan Cui, Long Li, Alexander Duyck, kernel-team,
Edward Cree, Brett Creeley
Cc: netdev, linux-kernel, oss-drivers, linux-hyperv,
linux-net-drivers, Breno Leitao, Subbaraya Sundeep
In-Reply-To: <20260122-grxring_big_v4-v2-0-94dbe4dcaa10@debian.org>
Use the newly introduced .get_rx_ring_count ethtool ops callback instead
of handling ETHTOOL_GRXRINGS directly in .get_rxnfc().
Since ETHTOOL_GRXRINGS was the only command handled by mana_get_rxnfc(),
remove the function entirely.
Reviewed-by: Subbaraya Sundeep <sbhatta@marvell.com>
Signed-off-by: Breno Leitao <leitao@debian.org>
---
drivers/net/ethernet/microsoft/mana/mana_ethtool.c | 13 +++----------
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/microsoft/mana/mana_ethtool.c b/drivers/net/ethernet/microsoft/mana/mana_ethtool.c
index 0e2f4343ac67f..f2d220b371b5d 100644
--- a/drivers/net/ethernet/microsoft/mana/mana_ethtool.c
+++ b/drivers/net/ethernet/microsoft/mana/mana_ethtool.c
@@ -282,18 +282,11 @@ static void mana_get_ethtool_stats(struct net_device *ndev,
}
}
-static int mana_get_rxnfc(struct net_device *ndev, struct ethtool_rxnfc *cmd,
- u32 *rules)
+static u32 mana_get_rx_ring_count(struct net_device *ndev)
{
struct mana_port_context *apc = netdev_priv(ndev);
- switch (cmd->cmd) {
- case ETHTOOL_GRXRINGS:
- cmd->data = apc->num_queues;
- return 0;
- }
-
- return -EOPNOTSUPP;
+ return apc->num_queues;
}
static u32 mana_get_rxfh_key_size(struct net_device *ndev)
@@ -520,7 +513,7 @@ const struct ethtool_ops mana_ethtool_ops = {
.get_ethtool_stats = mana_get_ethtool_stats,
.get_sset_count = mana_get_sset_count,
.get_strings = mana_get_strings,
- .get_rxnfc = mana_get_rxnfc,
+ .get_rx_ring_count = mana_get_rx_ring_count,
.get_rxfh_key_size = mana_get_rxfh_key_size,
.get_rxfh_indir_size = mana_rss_indir_size,
.get_rxfh = mana_get_rxfh,
--
2.47.3
^ permalink raw reply related
* [PATCH net-next v2 3/9] net: nfp: convert to use .get_rx_ring_count
From: Breno Leitao @ 2026-01-22 18:40 UTC (permalink / raw)
To: Ajit Khaparde, Sriharsha Basavapatna, Somnath Kotur, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Igor Russkikh, Simon Horman, K. Y. Srinivasan, Haiyang Zhang,
Wei Liu, Dexuan Cui, Long Li, Alexander Duyck, kernel-team,
Edward Cree, Brett Creeley
Cc: netdev, linux-kernel, oss-drivers, linux-hyperv,
linux-net-drivers, Breno Leitao, Subbaraya Sundeep
In-Reply-To: <20260122-grxring_big_v4-v2-0-94dbe4dcaa10@debian.org>
Use the newly introduced .get_rx_ring_count ethtool ops callback instead
of handling ETHTOOL_GRXRINGS directly in .get_rxnfc().
Reviewed-by: Subbaraya Sundeep <sbhatta@marvell.com>
Signed-off-by: Breno Leitao <leitao@debian.org>
---
drivers/net/ethernet/netronome/nfp/nfp_net_ethtool.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_ethtool.c b/drivers/net/ethernet/netronome/nfp/nfp_net_ethtool.c
index 16c828dd5c1a3..e88b1c4732a57 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net_ethtool.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_ethtool.c
@@ -1435,15 +1435,19 @@ static int nfp_net_get_fs_loc(struct nfp_net *nn, u32 *rule_locs)
return 0;
}
+static u32 nfp_net_get_rx_ring_count(struct net_device *netdev)
+{
+ struct nfp_net *nn = netdev_priv(netdev);
+
+ return nn->dp.num_rx_rings;
+}
+
static int nfp_net_get_rxnfc(struct net_device *netdev,
struct ethtool_rxnfc *cmd, u32 *rule_locs)
{
struct nfp_net *nn = netdev_priv(netdev);
switch (cmd->cmd) {
- case ETHTOOL_GRXRINGS:
- cmd->data = nn->dp.num_rx_rings;
- return 0;
case ETHTOOL_GRXCLSRLCNT:
cmd->rule_cnt = nn->fs.count;
return 0;
@@ -2501,6 +2505,7 @@ static const struct ethtool_ops nfp_net_ethtool_ops = {
.get_sset_count = nfp_net_get_sset_count,
.get_rxnfc = nfp_net_get_rxnfc,
.set_rxnfc = nfp_net_set_rxnfc,
+ .get_rx_ring_count = nfp_net_get_rx_ring_count,
.get_rxfh_indir_size = nfp_net_get_rxfh_indir_size,
.get_rxfh_key_size = nfp_net_get_rxfh_key_size,
.get_rxfh = nfp_net_get_rxfh,
--
2.47.3
^ permalink raw reply related
* [PATCH net-next v2 2/9] net: atlantic: convert to use .get_rx_ring_count
From: Breno Leitao @ 2026-01-22 18:40 UTC (permalink / raw)
To: Ajit Khaparde, Sriharsha Basavapatna, Somnath Kotur, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Igor Russkikh, Simon Horman, K. Y. Srinivasan, Haiyang Zhang,
Wei Liu, Dexuan Cui, Long Li, Alexander Duyck, kernel-team,
Edward Cree, Brett Creeley
Cc: netdev, linux-kernel, oss-drivers, linux-hyperv,
linux-net-drivers, Breno Leitao
In-Reply-To: <20260122-grxring_big_v4-v2-0-94dbe4dcaa10@debian.org>
Use the newly introduced .get_rx_ring_count ethtool ops callback instead
of handling ETHTOOL_GRXRINGS directly in .get_rxnfc().
Signed-off-by: Breno Leitao <leitao@debian.org>
---
drivers/net/ethernet/aquantia/atlantic/aq_ethtool.c | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/aquantia/atlantic/aq_ethtool.c b/drivers/net/ethernet/aquantia/atlantic/aq_ethtool.c
index 6fef47ba0a59b..a6e1826dd5d7e 100644
--- a/drivers/net/ethernet/aquantia/atlantic/aq_ethtool.c
+++ b/drivers/net/ethernet/aquantia/atlantic/aq_ethtool.c
@@ -500,20 +500,25 @@ static int aq_ethtool_set_rss(struct net_device *netdev,
return err;
}
+static u32 aq_ethtool_get_rx_ring_count(struct net_device *ndev)
+{
+ struct aq_nic_cfg_s *cfg;
+ struct aq_nic_s *aq_nic;
+
+ aq_nic = netdev_priv(ndev);
+ cfg = aq_nic_get_cfg(aq_nic);
+
+ return cfg->vecs;
+}
+
static int aq_ethtool_get_rxnfc(struct net_device *ndev,
struct ethtool_rxnfc *cmd,
u32 *rule_locs)
{
struct aq_nic_s *aq_nic = netdev_priv(ndev);
- struct aq_nic_cfg_s *cfg;
int err = 0;
- cfg = aq_nic_get_cfg(aq_nic);
-
switch (cmd->cmd) {
- case ETHTOOL_GRXRINGS:
- cmd->data = cfg->vecs;
- break;
case ETHTOOL_GRXCLSRLCNT:
cmd->rule_cnt = aq_get_rxnfc_count_all_rules(aq_nic);
break;
@@ -1072,6 +1077,7 @@ const struct ethtool_ops aq_ethtool_ops = {
.set_rxfh = aq_ethtool_set_rss,
.get_rxnfc = aq_ethtool_get_rxnfc,
.set_rxnfc = aq_ethtool_set_rxnfc,
+ .get_rx_ring_count = aq_ethtool_get_rx_ring_count,
.get_msglevel = aq_get_msg_level,
.set_msglevel = aq_set_msg_level,
.get_sset_count = aq_ethtool_get_sset_count,
--
2.47.3
^ permalink raw reply related
* [PATCH net-next v2 1/9] net: benet: convert to use .get_rx_ring_count
From: Breno Leitao @ 2026-01-22 18:40 UTC (permalink / raw)
To: Ajit Khaparde, Sriharsha Basavapatna, Somnath Kotur, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Igor Russkikh, Simon Horman, K. Y. Srinivasan, Haiyang Zhang,
Wei Liu, Dexuan Cui, Long Li, Alexander Duyck, kernel-team,
Edward Cree, Brett Creeley
Cc: netdev, linux-kernel, oss-drivers, linux-hyperv,
linux-net-drivers, Breno Leitao
In-Reply-To: <20260122-grxring_big_v4-v2-0-94dbe4dcaa10@debian.org>
Use the newly introduced .get_rx_ring_count ethtool ops callback instead
of handling ETHTOOL_GRXRINGS directly in .get_rxnfc().
Since ETHTOOL_GRXRINGS was the only command handled by be_get_rxnfc(),
remove the function entirely.
Since the be_multi_rxq() check in be_get_rxnfc() previously blocked RSS
configuration on single-queue setups (via ethtool core validation), add
an equivalent check to be_set_rxfh() to preserve this behavior, as
suggested by Jakub.
Signed-off-by: Breno Leitao <leitao@debian.org>
---
drivers/net/ethernet/emulex/benet/be_ethtool.c | 37 ++++++++++----------------
1 file changed, 14 insertions(+), 23 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_ethtool.c b/drivers/net/ethernet/emulex/benet/be_ethtool.c
index f55f1fd5d90fd..87dbbd5b7f4e6 100644
--- a/drivers/net/ethernet/emulex/benet/be_ethtool.c
+++ b/drivers/net/ethernet/emulex/benet/be_ethtool.c
@@ -1073,6 +1073,13 @@ static void be_set_msg_level(struct net_device *netdev, u32 level)
adapter->msg_enable = level;
}
+static u32 be_get_rx_ring_count(struct net_device *netdev)
+{
+ struct be_adapter *adapter = netdev_priv(netdev);
+
+ return adapter->num_rx_qs;
+}
+
static int be_get_rxfh_fields(struct net_device *netdev,
struct ethtool_rxfh_fields *cmd)
{
@@ -1117,28 +1124,6 @@ static int be_get_rxfh_fields(struct net_device *netdev,
return 0;
}
-static int be_get_rxnfc(struct net_device *netdev, struct ethtool_rxnfc *cmd,
- u32 *rule_locs)
-{
- struct be_adapter *adapter = netdev_priv(netdev);
-
- if (!be_multi_rxq(adapter)) {
- dev_info(&adapter->pdev->dev,
- "ethtool::get_rxnfc: RX flow hashing is disabled\n");
- return -EINVAL;
- }
-
- switch (cmd->cmd) {
- case ETHTOOL_GRXRINGS:
- cmd->data = adapter->num_rx_qs;
- break;
- default:
- return -EINVAL;
- }
-
- return 0;
-}
-
static int be_set_rxfh_fields(struct net_device *netdev,
const struct ethtool_rxfh_fields *cmd,
struct netlink_ext_ack *extack)
@@ -1293,6 +1278,12 @@ static int be_set_rxfh(struct net_device *netdev,
u8 *hkey = rxfh->key;
u8 rsstable[RSS_INDIR_TABLE_LEN];
+ if (!be_multi_rxq(adapter)) {
+ dev_info(&adapter->pdev->dev,
+ "ethtool::set_rxfh: RX flow hashing is disabled\n");
+ return -EINVAL;
+ }
+
/* We do not allow change in unsupported parameters */
if (rxfh->hfunc != ETH_RSS_HASH_NO_CHANGE &&
rxfh->hfunc != ETH_RSS_HASH_TOP)
@@ -1441,7 +1432,7 @@ const struct ethtool_ops be_ethtool_ops = {
.get_ethtool_stats = be_get_ethtool_stats,
.flash_device = be_do_flash,
.self_test = be_self_test,
- .get_rxnfc = be_get_rxnfc,
+ .get_rx_ring_count = be_get_rx_ring_count,
.get_rxfh_fields = be_get_rxfh_fields,
.set_rxfh_fields = be_set_rxfh_fields,
.get_rxfh_indir_size = be_get_rxfh_indir_size,
--
2.47.3
^ permalink raw reply related
* [PATCH net-next v2 0/9] net: convert drivers to .get_rx_ring_count (last part)
From: Breno Leitao @ 2026-01-22 18:40 UTC (permalink / raw)
To: Ajit Khaparde, Sriharsha Basavapatna, Somnath Kotur, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Igor Russkikh, Simon Horman, K. Y. Srinivasan, Haiyang Zhang,
Wei Liu, Dexuan Cui, Long Li, Alexander Duyck, kernel-team,
Edward Cree, Brett Creeley
Cc: netdev, linux-kernel, oss-drivers, linux-hyperv,
linux-net-drivers, Breno Leitao, Subbaraya Sundeep
Commit 84eaf4359c36 ("net: ethtool: add get_rx_ring_count callback to
optimize RX ring queries") added specific support for GRXRINGS callback,
simplifying .get_rxnfc.
Remove the handling of GRXRINGS in .get_rxnfc() by moving it to the new
.get_rx_ring_count().
This simplifies the RX ring count retrieval and aligns the following
drivers with the new ethtool API for querying RX ring parameters.
* sfc
* ionic
* sfc/siena
* sfc/ef100
* fbnic
* mana
* nfp
* atlantic
* benet (this is v2 in fact, where v1 had some discussions that
required a v2). See link [0]
Link: https://lore.kernel.org/all/20260119094514.5b12a097@kernel.org/ [0]
This is covering the last drivers, and as soon as this lands, I will
change the ethtool framework to avoid calling .get_rx_ring_count for
ETHTOOL_GRXRINGS, simplifying the ethtool core framework.
Part 1 is already merged in net-next and can be seen in
https://lore.kernel.org/all/20260109-grxring_big_v1-v1-0-a0f77f732006@debian.org/
Part 2 is already merged in net-next except benet driver, which is now included
in here
https://lore.kernel.org/all/20260115-grxring_big_v2-v1-0-b3e1b58bced5@debian.org/
PS: all of these change were compile-tested only.
Signed-off-by: Breno Leitao <leitao@debian.org>
---
Changes in v2:
- Respect reverse xmas tree in Atlantic driver (Brett Creeley)
- Link to v1: https://patch.msgid.link/20260121-grxring_big_v4-v1-0-07655be56bcf@debian.org
---
Breno Leitao (9):
net: benet: convert to use .get_rx_ring_count
net: atlantic: convert to use .get_rx_ring_count
net: nfp: convert to use .get_rx_ring_count
net: mana: convert to use .get_rx_ring_count
net: fbnic: convert to use .get_rx_ring_count
net: ionic: convert to use .get_rx_ring_count
net: sfc: efx: convert to use .get_rx_ring_count
net: sfc: siena: convert to use .get_rx_ring_count
net: sfc: falcon: convert to use .get_rx_ring_count
.../net/ethernet/aquantia/atlantic/aq_ethtool.c | 18 +++++++----
drivers/net/ethernet/emulex/benet/be_ethtool.c | 37 ++++++++--------------
drivers/net/ethernet/meta/fbnic/fbnic_ethtool.c | 12 ++++---
drivers/net/ethernet/microsoft/mana/mana_ethtool.c | 13 ++------
.../net/ethernet/netronome/nfp/nfp_net_ethtool.c | 11 +++++--
.../net/ethernet/pensando/ionic/ionic_ethtool.c | 18 ++---------
drivers/net/ethernet/sfc/ef100_ethtool.c | 1 +
drivers/net/ethernet/sfc/ethtool.c | 1 +
drivers/net/ethernet/sfc/ethtool_common.c | 11 ++++---
drivers/net/ethernet/sfc/ethtool_common.h | 1 +
drivers/net/ethernet/sfc/falcon/ethtool.c | 12 ++++---
drivers/net/ethernet/sfc/siena/ethtool.c | 1 +
drivers/net/ethernet/sfc/siena/ethtool_common.c | 11 ++++---
drivers/net/ethernet/sfc/siena/ethtool_common.h | 1 +
14 files changed, 75 insertions(+), 73 deletions(-)
---
base-commit: d8f87aa5fa0a4276491fa8ef436cd22605a3f9ba
change-id: 20260121-grxring_big_v4-55037f9e001e
Best regards,
--
Breno Leitao <leitao@debian.org>
^ permalink raw reply
* Re: [PATCH v4 6/7] mshv: Add data for printing stats page counters
From: Nuno Das Neves @ 2026-01-22 18:21 UTC (permalink / raw)
To: Stanislav Kinsburskii
Cc: linux-hyperv, linux-kernel, mhklinux, kys, haiyangz, wei.liu,
decui, longli, prapal, mrathor, paekkaladevi
In-Reply-To: <aXF61f8meLJr9T0z@skinsburskii.localdomain>
On 1/21/2026 5:18 PM, Stanislav Kinsburskii wrote:
> On Wed, Jan 21, 2026 at 01:46:22PM -0800, Nuno Das Neves wrote:
>> Introduce hv_counters.c, containing static data corresponding to
>> HV_*_COUNTER enums in the hypervisor source. Defining the enum
>> members as an array instead makes more sense, since it will be
>> iterated over to print counter information to debugfs.
>>
>> Include hypervisor, logical processor, partition, and virtual
>> processor counters.
>>
>> Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
>> ---
>> drivers/hv/hv_counters.c | 488 +++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 488 insertions(+)
>> create mode 100644 drivers/hv/hv_counters.c
>>
>> diff --git a/drivers/hv/hv_counters.c b/drivers/hv/hv_counters.c
>> new file mode 100644
>> index 000000000000..a8e07e72cc29
>> --- /dev/null
>> +++ b/drivers/hv/hv_counters.c
>> @@ -0,0 +1,488 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Copyright (c) 2026, Microsoft Corporation.
>> + *
>> + * Data for printing stats page counters via debugfs.
>> + *
>> + * Authors: Microsoft Linux virtualization team
>> + */
>> +
>> +struct hv_counter_entry {
>> + char *name;
>> + int idx;
>> +};
>
> This structure looks redundant to me mostly because of the "idx".
> It looks what you need here is an arry of pointers to strings, like
> below:
>
> static const char *hv_hypervisor_counters[] = {
> NULL, /* 0 is unused */
> "HvLogicalProcessors",
> "HvPartitions",
> "HvTotalPages",
> "HvVirtualProcessors",
> "HvMonitoredNotifications",
> "HvModernStandbyEntries",
> "HvPlatformIdleTransitions",
> "HvHypervisorStartupCost",
> NULL, /* 9 is unused */
> "HvIOSpacePages",
> ...
> };
>
> which can be iterated like this:
>
> for (idx = 0; idx < ARRAY_SIZE(hv_hypervisor_counters); idx++) {
> const char *name = hv_hypervisor_counters[idx];
> if (!name)
> continue;
> /* print */
> ...
> }
>
> What do you think?
It's an elegant option, given the values are almost uniformly
tightly packed. It also saves a fair bit of space - around 2.5Kb.
For my taste, I do like being able to visually verify the
correctness of any given member. That way whenever I look at it, I
don't have to blindly trust that the list was previously set up
correctly, or count the lines to check if a given value is correct.
Not a big deal, but it does introduce some friction.
We could also use a designated initializer list:
static const char *hv_hypervisor_counters[] = {
[1] = "HvLogicalProcessors",
[2] = "HvPartitions",
[3] = "HvTotalPages",
[4] = "HvVirtualProcessors",
[5] = "HvMonitoredNotifications",
[6] = "HvModernStandbyEntries",
[7] = "HvPlatformIdleTransitions",
[8] = "HvHypervisorStartupCost",
[10] = "HvIOSpacePages",
...
};
The indices are explicit, so it's easy to visually verify that any
particular part of the list is correct. It's functionally identical
to your approach, so it saves the same amount of space, and the
explicit NULLs are unnecessary so it's more straightforward to
transform from the Windows source in case of any gaps that are
harder to notice later on in the list.
How does that sound?
Nuno
>
> Thanks,
> Stanislav
>
>> +
>> +/* HV_HYPERVISOR_COUNTER */
>> +static struct hv_counter_entry hv_hypervisor_counters[] = {
>> + { "HvLogicalProcessors", 1 },
>> + { "HvPartitions", 2 },
>> + { "HvTotalPages", 3 },
>> + { "HvVirtualProcessors", 4 },
>> + { "HvMonitoredNotifications", 5 },
>> + { "HvModernStandbyEntries", 6 },
>> + { "HvPlatformIdleTransitions", 7 },
>> + { "HvHypervisorStartupCost", 8 },
>> +
>> + { "HvIOSpacePages", 10 },
>> + { "HvNonEssentialPagesForDump", 11 },
>> + { "HvSubsumedPages", 12 },
>> +};
>> +
>> +/* HV_CPU_COUNTER */
>> +static struct hv_counter_entry hv_lp_counters[] = {
>> + { "LpGlobalTime", 1 },
>> + { "LpTotalRunTime", 2 },
>> + { "LpHypervisorRunTime", 3 },
>> + { "LpHardwareInterrupts", 4 },
>> + { "LpContextSwitches", 5 },
>> + { "LpInterProcessorInterrupts", 6 },
>> + { "LpSchedulerInterrupts", 7 },
>> + { "LpTimerInterrupts", 8 },
>> + { "LpInterProcessorInterruptsSent", 9 },
>> + { "LpProcessorHalts", 10 },
>> + { "LpMonitorTransitionCost", 11 },
>> + { "LpContextSwitchTime", 12 },
>> + { "LpC1TransitionsCount", 13 },
>> + { "LpC1RunTime", 14 },
>> + { "LpC2TransitionsCount", 15 },
>> + { "LpC2RunTime", 16 },
>> + { "LpC3TransitionsCount", 17 },
>> + { "LpC3RunTime", 18 },
>> + { "LpRootVpIndex", 19 },
>> + { "LpIdleSequenceNumber", 20 },
>> + { "LpGlobalTscCount", 21 },
>> + { "LpActiveTscCount", 22 },
>> + { "LpIdleAccumulation", 23 },
>> + { "LpReferenceCycleCount0", 24 },
>> + { "LpActualCycleCount0", 25 },
>> + { "LpReferenceCycleCount1", 26 },
>> + { "LpActualCycleCount1", 27 },
>> + { "LpProximityDomainId", 28 },
>> + { "LpPostedInterruptNotifications", 29 },
>> + { "LpBranchPredictorFlushes", 30 },
>> +#if IS_ENABLED(CONFIG_X86_64)
>> + { "LpL1DataCacheFlushes", 31 },
>> + { "LpImmediateL1DataCacheFlushes", 32 },
>> + { "LpMbFlushes", 33 },
>> + { "LpCounterRefreshSequenceNumber", 34 },
>> + { "LpCounterRefreshReferenceTime", 35 },
>> + { "LpIdleAccumulationSnapshot", 36 },
>> + { "LpActiveTscCountSnapshot", 37 },
>> + { "LpHwpRequestContextSwitches", 38 },
>> + { "LpPlaceholder1", 39 },
>> + { "LpPlaceholder2", 40 },
>> + { "LpPlaceholder3", 41 },
>> + { "LpPlaceholder4", 42 },
>> + { "LpPlaceholder5", 43 },
>> + { "LpPlaceholder6", 44 },
>> + { "LpPlaceholder7", 45 },
>> + { "LpPlaceholder8", 46 },
>> + { "LpPlaceholder9", 47 },
>> + { "LpSchLocalRunListSize", 48 },
>> + { "LpReserveGroupId", 49 },
>> + { "LpRunningPriority", 50 },
>> + { "LpPerfmonInterruptCount", 51 },
>> +#elif IS_ENABLED(CONFIG_ARM64)
>> + { "LpCounterRefreshSequenceNumber", 31 },
>> + { "LpCounterRefreshReferenceTime", 32 },
>> + { "LpIdleAccumulationSnapshot", 33 },
>> + { "LpActiveTscCountSnapshot", 34 },
>> + { "LpHwpRequestContextSwitches", 35 },
>> + { "LpPlaceholder2", 36 },
>> + { "LpPlaceholder3", 37 },
>> + { "LpPlaceholder4", 38 },
>> + { "LpPlaceholder5", 39 },
>> + { "LpPlaceholder6", 40 },
>> + { "LpPlaceholder7", 41 },
>> + { "LpPlaceholder8", 42 },
>> + { "LpPlaceholder9", 43 },
>> + { "LpSchLocalRunListSize", 44 },
>> + { "LpReserveGroupId", 45 },
>> + { "LpRunningPriority", 46 },
>> +#endif
>> +};
>> +
>> +/* HV_PROCESS_COUNTER */
>> +static struct hv_counter_entry hv_partition_counters[] = {
>> + { "PtVirtualProcessors", 1 },
>> +
>> + { "PtTlbSize", 3 },
>> + { "PtAddressSpaces", 4 },
>> + { "PtDepositedPages", 5 },
>> + { "PtGpaPages", 6 },
>> + { "PtGpaSpaceModifications", 7 },
>> + { "PtVirtualTlbFlushEntires", 8 },
>> + { "PtRecommendedTlbSize", 9 },
>> + { "PtGpaPages4K", 10 },
>> + { "PtGpaPages2M", 11 },
>> + { "PtGpaPages1G", 12 },
>> + { "PtGpaPages512G", 13 },
>> + { "PtDevicePages4K", 14 },
>> + { "PtDevicePages2M", 15 },
>> + { "PtDevicePages1G", 16 },
>> + { "PtDevicePages512G", 17 },
>> + { "PtAttachedDevices", 18 },
>> + { "PtDeviceInterruptMappings", 19 },
>> + { "PtIoTlbFlushes", 20 },
>> + { "PtIoTlbFlushCost", 21 },
>> + { "PtDeviceInterruptErrors", 22 },
>> + { "PtDeviceDmaErrors", 23 },
>> + { "PtDeviceInterruptThrottleEvents", 24 },
>> + { "PtSkippedTimerTicks", 25 },
>> + { "PtPartitionId", 26 },
>> +#if IS_ENABLED(CONFIG_X86_64)
>> + { "PtNestedTlbSize", 27 },
>> + { "PtRecommendedNestedTlbSize", 28 },
>> + { "PtNestedTlbFreeListSize", 29 },
>> + { "PtNestedTlbTrimmedPages", 30 },
>> + { "PtPagesShattered", 31 },
>> + { "PtPagesRecombined", 32 },
>> + { "PtHwpRequestValue", 33 },
>> + { "PtAutoSuspendEnableTime", 34 },
>> + { "PtAutoSuspendTriggerTime", 35 },
>> + { "PtAutoSuspendDisableTime", 36 },
>> + { "PtPlaceholder1", 37 },
>> + { "PtPlaceholder2", 38 },
>> + { "PtPlaceholder3", 39 },
>> + { "PtPlaceholder4", 40 },
>> + { "PtPlaceholder5", 41 },
>> + { "PtPlaceholder6", 42 },
>> + { "PtPlaceholder7", 43 },
>> + { "PtPlaceholder8", 44 },
>> + { "PtHypervisorStateTransferGeneration", 45 },
>> + { "PtNumberofActiveChildPartitions", 46 },
>> +#elif IS_ENABLED(CONFIG_ARM64)
>> + { "PtHwpRequestValue", 27 },
>> + { "PtAutoSuspendEnableTime", 28 },
>> + { "PtAutoSuspendTriggerTime", 29 },
>> + { "PtAutoSuspendDisableTime", 30 },
>> + { "PtPlaceholder1", 31 },
>> + { "PtPlaceholder2", 32 },
>> + { "PtPlaceholder3", 33 },
>> + { "PtPlaceholder4", 34 },
>> + { "PtPlaceholder5", 35 },
>> + { "PtPlaceholder6", 36 },
>> + { "PtPlaceholder7", 37 },
>> + { "PtPlaceholder8", 38 },
>> + { "PtHypervisorStateTransferGeneration", 39 },
>> + { "PtNumberofActiveChildPartitions", 40 },
>> +#endif
>> +};
>> +
>> +/* HV_THREAD_COUNTER */
>> +static struct hv_counter_entry hv_vp_counters[] = {
>> + { "VpTotalRunTime", 1 },
>> + { "VpHypervisorRunTime", 2 },
>> + { "VpRemoteNodeRunTime", 3 },
>> + { "VpNormalizedRunTime", 4 },
>> + { "VpIdealCpu", 5 },
>> +
>> + { "VpHypercallsCount", 7 },
>> + { "VpHypercallsTime", 8 },
>> +#if IS_ENABLED(CONFIG_X86_64)
>> + { "VpPageInvalidationsCount", 9 },
>> + { "VpPageInvalidationsTime", 10 },
>> + { "VpControlRegisterAccessesCount", 11 },
>> + { "VpControlRegisterAccessesTime", 12 },
>> + { "VpIoInstructionsCount", 13 },
>> + { "VpIoInstructionsTime", 14 },
>> + { "VpHltInstructionsCount", 15 },
>> + { "VpHltInstructionsTime", 16 },
>> + { "VpMwaitInstructionsCount", 17 },
>> + { "VpMwaitInstructionsTime", 18 },
>> + { "VpCpuidInstructionsCount", 19 },
>> + { "VpCpuidInstructionsTime", 20 },
>> + { "VpMsrAccessesCount", 21 },
>> + { "VpMsrAccessesTime", 22 },
>> + { "VpOtherInterceptsCount", 23 },
>> + { "VpOtherInterceptsTime", 24 },
>> + { "VpExternalInterruptsCount", 25 },
>> + { "VpExternalInterruptsTime", 26 },
>> + { "VpPendingInterruptsCount", 27 },
>> + { "VpPendingInterruptsTime", 28 },
>> + { "VpEmulatedInstructionsCount", 29 },
>> + { "VpEmulatedInstructionsTime", 30 },
>> + { "VpDebugRegisterAccessesCount", 31 },
>> + { "VpDebugRegisterAccessesTime", 32 },
>> + { "VpPageFaultInterceptsCount", 33 },
>> + { "VpPageFaultInterceptsTime", 34 },
>> + { "VpGuestPageTableMaps", 35 },
>> + { "VpLargePageTlbFills", 36 },
>> + { "VpSmallPageTlbFills", 37 },
>> + { "VpReflectedGuestPageFaults", 38 },
>> + { "VpApicMmioAccesses", 39 },
>> + { "VpIoInterceptMessages", 40 },
>> + { "VpMemoryInterceptMessages", 41 },
>> + { "VpApicEoiAccesses", 42 },
>> + { "VpOtherMessages", 43 },
>> + { "VpPageTableAllocations", 44 },
>> + { "VpLogicalProcessorMigrations", 45 },
>> + { "VpAddressSpaceEvictions", 46 },
>> + { "VpAddressSpaceSwitches", 47 },
>> + { "VpAddressDomainFlushes", 48 },
>> + { "VpAddressSpaceFlushes", 49 },
>> + { "VpGlobalGvaRangeFlushes", 50 },
>> + { "VpLocalGvaRangeFlushes", 51 },
>> + { "VpPageTableEvictions", 52 },
>> + { "VpPageTableReclamations", 53 },
>> + { "VpPageTableResets", 54 },
>> + { "VpPageTableValidations", 55 },
>> + { "VpApicTprAccesses", 56 },
>> + { "VpPageTableWriteIntercepts", 57 },
>> + { "VpSyntheticInterrupts", 58 },
>> + { "VpVirtualInterrupts", 59 },
>> + { "VpApicIpisSent", 60 },
>> + { "VpApicSelfIpisSent", 61 },
>> + { "VpGpaSpaceHypercalls", 62 },
>> + { "VpLogicalProcessorHypercalls", 63 },
>> + { "VpLongSpinWaitHypercalls", 64 },
>> + { "VpOtherHypercalls", 65 },
>> + { "VpSyntheticInterruptHypercalls", 66 },
>> + { "VpVirtualInterruptHypercalls", 67 },
>> + { "VpVirtualMmuHypercalls", 68 },
>> + { "VpVirtualProcessorHypercalls", 69 },
>> + { "VpHardwareInterrupts", 70 },
>> + { "VpNestedPageFaultInterceptsCount", 71 },
>> + { "VpNestedPageFaultInterceptsTime", 72 },
>> + { "VpPageScans", 73 },
>> + { "VpLogicalProcessorDispatches", 74 },
>> + { "VpWaitingForCpuTime", 75 },
>> + { "VpExtendedHypercalls", 76 },
>> + { "VpExtendedHypercallInterceptMessages", 77 },
>> + { "VpMbecNestedPageTableSwitches", 78 },
>> + { "VpOtherReflectedGuestExceptions", 79 },
>> + { "VpGlobalIoTlbFlushes", 80 },
>> + { "VpGlobalIoTlbFlushCost", 81 },
>> + { "VpLocalIoTlbFlushes", 82 },
>> + { "VpLocalIoTlbFlushCost", 83 },
>> + { "VpHypercallsForwardedCount", 84 },
>> + { "VpHypercallsForwardingTime", 85 },
>> + { "VpPageInvalidationsForwardedCount", 86 },
>> + { "VpPageInvalidationsForwardingTime", 87 },
>> + { "VpControlRegisterAccessesForwardedCount", 88 },
>> + { "VpControlRegisterAccessesForwardingTime", 89 },
>> + { "VpIoInstructionsForwardedCount", 90 },
>> + { "VpIoInstructionsForwardingTime", 91 },
>> + { "VpHltInstructionsForwardedCount", 92 },
>> + { "VpHltInstructionsForwardingTime", 93 },
>> + { "VpMwaitInstructionsForwardedCount", 94 },
>> + { "VpMwaitInstructionsForwardingTime", 95 },
>> + { "VpCpuidInstructionsForwardedCount", 96 },
>> + { "VpCpuidInstructionsForwardingTime", 97 },
>> + { "VpMsrAccessesForwardedCount", 98 },
>> + { "VpMsrAccessesForwardingTime", 99 },
>> + { "VpOtherInterceptsForwardedCount", 100 },
>> + { "VpOtherInterceptsForwardingTime", 101 },
>> + { "VpExternalInterruptsForwardedCount", 102 },
>> + { "VpExternalInterruptsForwardingTime", 103 },
>> + { "VpPendingInterruptsForwardedCount", 104 },
>> + { "VpPendingInterruptsForwardingTime", 105 },
>> + { "VpEmulatedInstructionsForwardedCount", 106 },
>> + { "VpEmulatedInstructionsForwardingTime", 107 },
>> + { "VpDebugRegisterAccessesForwardedCount", 108 },
>> + { "VpDebugRegisterAccessesForwardingTime", 109 },
>> + { "VpPageFaultInterceptsForwardedCount", 110 },
>> + { "VpPageFaultInterceptsForwardingTime", 111 },
>> + { "VpVmclearEmulationCount", 112 },
>> + { "VpVmclearEmulationTime", 113 },
>> + { "VpVmptrldEmulationCount", 114 },
>> + { "VpVmptrldEmulationTime", 115 },
>> + { "VpVmptrstEmulationCount", 116 },
>> + { "VpVmptrstEmulationTime", 117 },
>> + { "VpVmreadEmulationCount", 118 },
>> + { "VpVmreadEmulationTime", 119 },
>> + { "VpVmwriteEmulationCount", 120 },
>> + { "VpVmwriteEmulationTime", 121 },
>> + { "VpVmxoffEmulationCount", 122 },
>> + { "VpVmxoffEmulationTime", 123 },
>> + { "VpVmxonEmulationCount", 124 },
>> + { "VpVmxonEmulationTime", 125 },
>> + { "VpNestedVMEntriesCount", 126 },
>> + { "VpNestedVMEntriesTime", 127 },
>> + { "VpNestedSLATSoftPageFaultsCount", 128 },
>> + { "VpNestedSLATSoftPageFaultsTime", 129 },
>> + { "VpNestedSLATHardPageFaultsCount", 130 },
>> + { "VpNestedSLATHardPageFaultsTime", 131 },
>> + { "VpInvEptAllContextEmulationCount", 132 },
>> + { "VpInvEptAllContextEmulationTime", 133 },
>> + { "VpInvEptSingleContextEmulationCount", 134 },
>> + { "VpInvEptSingleContextEmulationTime", 135 },
>> + { "VpInvVpidAllContextEmulationCount", 136 },
>> + { "VpInvVpidAllContextEmulationTime", 137 },
>> + { "VpInvVpidSingleContextEmulationCount", 138 },
>> + { "VpInvVpidSingleContextEmulationTime", 139 },
>> + { "VpInvVpidSingleAddressEmulationCount", 140 },
>> + { "VpInvVpidSingleAddressEmulationTime", 141 },
>> + { "VpNestedTlbPageTableReclamations", 142 },
>> + { "VpNestedTlbPageTableEvictions", 143 },
>> + { "VpFlushGuestPhysicalAddressSpaceHypercalls", 144 },
>> + { "VpFlushGuestPhysicalAddressListHypercalls", 145 },
>> + { "VpPostedInterruptNotifications", 146 },
>> + { "VpPostedInterruptScans", 147 },
>> + { "VpTotalCoreRunTime", 148 },
>> + { "VpMaximumRunTime", 149 },
>> + { "VpHwpRequestContextSwitches", 150 },
>> + { "VpWaitingForCpuTimeBucket0", 151 },
>> + { "VpWaitingForCpuTimeBucket1", 152 },
>> + { "VpWaitingForCpuTimeBucket2", 153 },
>> + { "VpWaitingForCpuTimeBucket3", 154 },
>> + { "VpWaitingForCpuTimeBucket4", 155 },
>> + { "VpWaitingForCpuTimeBucket5", 156 },
>> + { "VpWaitingForCpuTimeBucket6", 157 },
>> + { "VpVmloadEmulationCount", 158 },
>> + { "VpVmloadEmulationTime", 159 },
>> + { "VpVmsaveEmulationCount", 160 },
>> + { "VpVmsaveEmulationTime", 161 },
>> + { "VpGifInstructionEmulationCount", 162 },
>> + { "VpGifInstructionEmulationTime", 163 },
>> + { "VpEmulatedErrataSvmInstructions", 164 },
>> + { "VpPlaceholder1", 165 },
>> + { "VpPlaceholder2", 166 },
>> + { "VpPlaceholder3", 167 },
>> + { "VpPlaceholder4", 168 },
>> + { "VpPlaceholder5", 169 },
>> + { "VpPlaceholder6", 170 },
>> + { "VpPlaceholder7", 171 },
>> + { "VpPlaceholder8", 172 },
>> + { "VpContentionTime", 173 },
>> + { "VpWakeUpTime", 174 },
>> + { "VpSchedulingPriority", 175 },
>> + { "VpRdpmcInstructionsCount", 176 },
>> + { "VpRdpmcInstructionsTime", 177 },
>> + { "VpPerfmonPmuMsrAccessesCount", 178 },
>> + { "VpPerfmonLbrMsrAccessesCount", 179 },
>> + { "VpPerfmonIptMsrAccessesCount", 180 },
>> + { "VpPerfmonInterruptCount", 181 },
>> + { "VpVtl1DispatchCount", 182 },
>> + { "VpVtl2DispatchCount", 183 },
>> + { "VpVtl2DispatchBucket0", 184 },
>> + { "VpVtl2DispatchBucket1", 185 },
>> + { "VpVtl2DispatchBucket2", 186 },
>> + { "VpVtl2DispatchBucket3", 187 },
>> + { "VpVtl2DispatchBucket4", 188 },
>> + { "VpVtl2DispatchBucket5", 189 },
>> + { "VpVtl2DispatchBucket6", 190 },
>> + { "VpVtl1RunTime", 191 },
>> + { "VpVtl2RunTime", 192 },
>> + { "VpIommuHypercalls", 193 },
>> + { "VpCpuGroupHypercalls", 194 },
>> + { "VpVsmHypercalls", 195 },
>> + { "VpEventLogHypercalls", 196 },
>> + { "VpDeviceDomainHypercalls", 197 },
>> + { "VpDepositHypercalls", 198 },
>> + { "VpSvmHypercalls", 199 },
>> + { "VpBusLockAcquisitionCount", 200 },
>> + { "VpLoadAvg", 201 },
>> + { "VpRootDispatchThreadBlocked", 202 },
>> + { "VpIdleCpuTime", 203 },
>> + { "VpWaitingForCpuTimeBucket7", 204 },
>> + { "VpWaitingForCpuTimeBucket8", 205 },
>> + { "VpWaitingForCpuTimeBucket9", 206 },
>> + { "VpWaitingForCpuTimeBucket10", 207 },
>> + { "VpWaitingForCpuTimeBucket11", 208 },
>> + { "VpWaitingForCpuTimeBucket12", 209 },
>> + { "VpHierarchicalSuspendTime", 210 },
>> + { "VpExpressSchedulingAttempts", 211 },
>> + { "VpExpressSchedulingCount", 212 },
>> + { "VpBusLockAcquisitionTime", 213 },
>> +#elif IS_ENABLED(CONFIG_ARM64)
>> + { "VpSysRegAccessesCount", 9 },
>> + { "VpSysRegAccessesTime", 10 },
>> + { "VpSmcInstructionsCount", 11 },
>> + { "VpSmcInstructionsTime", 12 },
>> + { "VpOtherInterceptsCount", 13 },
>> + { "VpOtherInterceptsTime", 14 },
>> + { "VpExternalInterruptsCount", 15 },
>> + { "VpExternalInterruptsTime", 16 },
>> + { "VpPendingInterruptsCount", 17 },
>> + { "VpPendingInterruptsTime", 18 },
>> + { "VpGuestPageTableMaps", 19 },
>> + { "VpLargePageTlbFills", 20 },
>> + { "VpSmallPageTlbFills", 21 },
>> + { "VpReflectedGuestPageFaults", 22 },
>> + { "VpMemoryInterceptMessages", 23 },
>> + { "VpOtherMessages", 24 },
>> + { "VpLogicalProcessorMigrations", 25 },
>> + { "VpAddressDomainFlushes", 26 },
>> + { "VpAddressSpaceFlushes", 27 },
>> + { "VpSyntheticInterrupts", 28 },
>> + { "VpVirtualInterrupts", 29 },
>> + { "VpApicSelfIpisSent", 30 },
>> + { "VpGpaSpaceHypercalls", 31 },
>> + { "VpLogicalProcessorHypercalls", 32 },
>> + { "VpLongSpinWaitHypercalls", 33 },
>> + { "VpOtherHypercalls", 34 },
>> + { "VpSyntheticInterruptHypercalls", 35 },
>> + { "VpVirtualInterruptHypercalls", 36 },
>> + { "VpVirtualMmuHypercalls", 37 },
>> + { "VpVirtualProcessorHypercalls", 38 },
>> + { "VpHardwareInterrupts", 39 },
>> + { "VpNestedPageFaultInterceptsCount", 40 },
>> + { "VpNestedPageFaultInterceptsTime", 41 },
>> + { "VpLogicalProcessorDispatches", 42 },
>> + { "VpWaitingForCpuTime", 43 },
>> + { "VpExtendedHypercalls", 44 },
>> + { "VpExtendedHypercallInterceptMessages", 45 },
>> + { "VpMbecNestedPageTableSwitches", 46 },
>> + { "VpOtherReflectedGuestExceptions", 47 },
>> + { "VpGlobalIoTlbFlushes", 48 },
>> + { "VpGlobalIoTlbFlushCost", 49 },
>> + { "VpLocalIoTlbFlushes", 50 },
>> + { "VpLocalIoTlbFlushCost", 51 },
>> + { "VpFlushGuestPhysicalAddressSpaceHypercalls", 52 },
>> + { "VpFlushGuestPhysicalAddressListHypercalls", 53 },
>> + { "VpPostedInterruptNotifications", 54 },
>> + { "VpPostedInterruptScans", 55 },
>> + { "VpTotalCoreRunTime", 56 },
>> + { "VpMaximumRunTime", 57 },
>> + { "VpWaitingForCpuTimeBucket0", 58 },
>> + { "VpWaitingForCpuTimeBucket1", 59 },
>> + { "VpWaitingForCpuTimeBucket2", 60 },
>> + { "VpWaitingForCpuTimeBucket3", 61 },
>> + { "VpWaitingForCpuTimeBucket4", 62 },
>> + { "VpWaitingForCpuTimeBucket5", 63 },
>> + { "VpWaitingForCpuTimeBucket6", 64 },
>> + { "VpHwpRequestContextSwitches", 65 },
>> + { "VpPlaceholder2", 66 },
>> + { "VpPlaceholder3", 67 },
>> + { "VpPlaceholder4", 68 },
>> + { "VpPlaceholder5", 69 },
>> + { "VpPlaceholder6", 70 },
>> + { "VpPlaceholder7", 71 },
>> + { "VpPlaceholder8", 72 },
>> + { "VpContentionTime", 73 },
>> + { "VpWakeUpTime", 74 },
>> + { "VpSchedulingPriority", 75 },
>> + { "VpVtl1DispatchCount", 76 },
>> + { "VpVtl2DispatchCount", 77 },
>> + { "VpVtl2DispatchBucket0", 78 },
>> + { "VpVtl2DispatchBucket1", 79 },
>> + { "VpVtl2DispatchBucket2", 80 },
>> + { "VpVtl2DispatchBucket3", 81 },
>> + { "VpVtl2DispatchBucket4", 82 },
>> + { "VpVtl2DispatchBucket5", 83 },
>> + { "VpVtl2DispatchBucket6", 84 },
>> + { "VpVtl1RunTime", 85 },
>> + { "VpVtl2RunTime", 86 },
>> + { "VpIommuHypercalls", 87 },
>> + { "VpCpuGroupHypercalls", 88 },
>> + { "VpVsmHypercalls", 89 },
>> + { "VpEventLogHypercalls", 90 },
>> + { "VpDeviceDomainHypercalls", 91 },
>> + { "VpDepositHypercalls", 92 },
>> + { "VpSvmHypercalls", 93 },
>> + { "VpLoadAvg", 94 },
>> + { "VpRootDispatchThreadBlocked", 95 },
>> + { "VpIdleCpuTime", 96 },
>> + { "VpWaitingForCpuTimeBucket7", 97 },
>> + { "VpWaitingForCpuTimeBucket8", 98 },
>> + { "VpWaitingForCpuTimeBucket9", 99 },
>> + { "VpWaitingForCpuTimeBucket10", 100 },
>> + { "VpWaitingForCpuTimeBucket11", 101 },
>> + { "VpWaitingForCpuTimeBucket12", 102 },
>> + { "VpHierarchicalSuspendTime", 103 },
>> + { "VpExpressSchedulingAttempts", 104 },
>> + { "VpExpressSchedulingCount", 105 },
>> +#endif
>> +};
>> +
>> --
>> 2.34.1
^ permalink raw reply
* Re: [PATCH net-next v2] net: mana: Improve diagnostic logging for better debuggability
From: Erni Sri Satya Vennela @ 2026-01-22 17:43 UTC (permalink / raw)
To: Jakub Kicinski
Cc: kys, haiyangz, wei.liu, decui, longli, andrew+netdev, davem,
edumazet, pabeni, leon, kotaranov, shradhagupta, yury.norov,
dipayanroy, shirazsaleem, ssengar, gargaditya, linux-hyperv,
netdev, linux-kernel
In-Reply-To: <20260121201412.179f9b37@kernel.org>
On Wed, Jan 21, 2026 at 08:14:12PM -0800, Jakub Kicinski wrote:
> On Tue, 20 Jan 2026 22:56:55 -0800 Erni Sri Satya Vennela wrote:
> > Enhance MANA driver logging to provide better visibility into
> > hardware configuration and error states during driver initialization
> > and runtime operations.
>
> > + dev_info(gc->dev, "Max Resources: msix_usable=%u max_queues=%u\n",
> > + gc->num_msix_usable, gc->max_num_queues);
>
> > + dev_info(dev, "Device Config: max_vports=%u adapter_mtu=%u bm_hostmode=%u\n",
> > + *max_num_vports, gc->adapter_mtu, *bm_hostmode);
>
> IIUC in networking we try to follow the mantra that if the system is
> functioning correctly there should be no logs. You can expose the debug
> info via ethtool, devlink, debugfs etc. Take your pick.
We discussed this internally and noted that customers often cannot
reliably reproduce the VM issue. In such cases, the only evidence
available is the dmesg logs captured during the incident. Asking them to
re-enable debug options later is not practical, since the problem may
not occur again. Similarly, exposing the information via ethtool,
devlink, or debugfs is less effective because the data is transient and
lost after a reboot. As these messages are printed only once during
initialization, and not repeated during runtime or driver load/unload,
we decided to keep them at info level to aid troubleshooting without
adding noise.
- Vennela
^ permalink raw reply
* Re: [PATCH net-next v16 00/12] vsock: add namespace support to vhost-vsock and loopback
From: Michael S. Tsirkin @ 2026-01-22 16:23 UTC (permalink / raw)
To: Bobby Eshleman
Cc: Stefano Garzarella, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Stefan Hajnoczi, Jason Wang,
Eugenio Pérez, Xuan Zhuo, K. Y. Srinivasan, Haiyang Zhang,
Wei Liu, Dexuan Cui, Bryan Tan, Vishnu Dasa,
Broadcom internal kernel review list, Shuah Khan, Long Li,
Jonathan Corbet, linux-kernel, virtualization, netdev, kvm,
linux-hyperv, linux-kselftest, berrange, Sargun Dhillon,
linux-doc, Bobby Eshleman
In-Reply-To: <20260121-vsock-vmtest-v16-0-2859a7512097@meta.com>
On Wed, Jan 21, 2026 at 02:11:40PM -0800, Bobby Eshleman wrote:
> This series adds namespace support to vhost-vsock and loopback. It does
> not add namespaces to any of the other guest transports (virtio-vsock,
> hyperv, or vmci).
>
> The current revision supports two modes: local and global. Local
> mode is complete isolation of namespaces, while global mode is complete
> sharing between namespaces of CIDs (the original behavior).
>
> The mode is set using the parent namespace's
> /proc/sys/net/vsock/child_ns_mode and inherited when a new namespace is
> created. The mode of the current namespace can be queried by reading
> /proc/sys/net/vsock/ns_mode. The mode can not change after the namespace
> has been created.
>
> Modes are per-netns. This allows a system to configure namespaces
> independently (some may share CIDs, others are completely isolated).
> This also supports future possible mixed use cases, where there may be
> namespaces in global mode spinning up VMs while there are mixed mode
> namespaces that provide services to the VMs, but are not allowed to
> allocate from the global CID pool (this mode is not implemented in this
> series).
>
> Additionally, added tests for the new namespace features:
>
> tools/testing/selftests/vsock/vmtest.sh
> 1..25
> ok 1 vm_server_host_client
> ok 2 vm_client_host_server
> ok 3 vm_loopback
> ok 4 ns_host_vsock_ns_mode_ok
> ok 5 ns_host_vsock_child_ns_mode_ok
> ok 6 ns_global_same_cid_fails
> ok 7 ns_local_same_cid_ok
> ok 8 ns_global_local_same_cid_ok
> ok 9 ns_local_global_same_cid_ok
> ok 10 ns_diff_global_host_connect_to_global_vm_ok
> ok 11 ns_diff_global_host_connect_to_local_vm_fails
> ok 12 ns_diff_global_vm_connect_to_global_host_ok
> ok 13 ns_diff_global_vm_connect_to_local_host_fails
> ok 14 ns_diff_local_host_connect_to_local_vm_fails
> ok 15 ns_diff_local_vm_connect_to_local_host_fails
> ok 16 ns_diff_global_to_local_loopback_local_fails
> ok 17 ns_diff_local_to_global_loopback_fails
> ok 18 ns_diff_local_to_local_loopback_fails
> ok 19 ns_diff_global_to_global_loopback_ok
> ok 20 ns_same_local_loopback_ok
> ok 21 ns_same_local_host_connect_to_local_vm_ok
> ok 22 ns_same_local_vm_connect_to_local_host_ok
> ok 23 ns_delete_vm_ok
> ok 24 ns_delete_host_ok
> ok 25 ns_delete_both_ok
> SUMMARY: PASS=25 SKIP=0 FAIL=0
>
> Thanks again for everyone's help and reviews!
>
> Suggested-by: Sargun Dhillon <sargun@sargun.me>
> Signed-off-by: Bobby Eshleman <bobbyeshleman@gmail.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
>
> Changes in v16:
> - updated comments/docs/commit msg (vsock_find_* funcs, init net
> mode, why change random port alloc)
> - removed init ns mode cmdline
> - fixed the missing ${ns} arg for vm_ssh in vmtest.sh
> - Link to v15: https://lore.kernel.org/r/20260116-vsock-vmtest-v15-0-bbfd1a668548@meta.com
>
> Changes in v15:
> - see per-patch change notes in 'vsock: add netns to vsock core'
> - Link to v14: https://lore.kernel.org/r/20260112-vsock-vmtest-v14-0-a5c332db3e2b@meta.com
>
> Changes in v14:
> - squashed 'vsock: add per-net vsock NS mode state' into 'vsock: add
> netns to vsock core' (MST)
> - remove RFC tag
> - fixed base-commit (still had b4 configured to depend on old vmtest.sh
> series)
> - Link to v13: https://lore.kernel.org/all/20251223-vsock-vmtest-v13-0-9d6db8e7c80b@meta.com/
>
> Changes in v13:
> - add support for immutable sysfs ns_mode and inheritance from sysfs child_ns_mode
> - remove passing around of net_mode, can be accessed now via
> vsock_net_mode(net) since it is immutable
> - update tests for new uAPI
> - add one patch to extend the kselftest timeout (it was starting to
> fail with the new tests added)
> - Link to v12: https://lore.kernel.org/r/20251126-vsock-vmtest-v12-0-257ee21cd5de@meta.com
>
> Changes in v12:
> - add ns mode checking to _allow() callbacks to reject local mode for
> incompatible transports (Stefano)
> - flip vhost/loopback to return true for stream_allow() and
> seqpacket_allow() in "vsock: add netns support to virtio transports"
> (Stefano)
> - add VMADDR_CID_ANY + local mode documentation in af_vsock.c (Stefano)
> - change "selftests/vsock: add tests for host <-> vm connectivity with
> namespaces" to skip test 29 in vsock_test for namespace local
> vsock_test calls in a host local-mode namespace. There is a
> false-positive edge case for that test encountered with the
> ->stream_allow() approach. More details in that patch.
> - updated cover letter with new test output
> - Link to v11: https://lore.kernel.org/r/20251120-vsock-vmtest-v11-0-55cbc80249a7@meta.com
>
> Changes in v11:
> - vmtest: add a patch to use ss in wait_for_listener functions and
> support vsock, tcp, and unix. Change all patches to use the new
> functions.
> - vmtest: add a patch to re-use vm dmesg / warn counting functions
> - Link to v10: https://lore.kernel.org/r/20251117-vsock-vmtest-v10-0-df08f165bf3e@meta.com
>
> Changes in v10:
> - Combine virtio common patches into one (Stefano)
> - Resolve vsock_loopback virtio_transport_reset_no_sock() issue
> with info->vsk setting. This eliminates the need for skb->cb,
> so remove skb->cb patches.
> - many line width 80 fixes
> - Link to v9: https://lore.kernel.org/all/20251111-vsock-vmtest-v9-0-852787a37bed@meta.com
>
> Changes in v9:
> - reorder loopback patch after patch for virtio transport common code
> - remove module ordering tests patch because loopback no longer depends
> on pernet ops
> - major simplifications in vsock_loopback
> - added a new patch for blocking local mode for guests, added test case
> to check
> - add net ref tracking to vsock_loopback patch
> - Link to v8: https://lore.kernel.org/r/20251023-vsock-vmtest-v8-0-dea984d02bb0@meta.com
>
> Changes in v8:
> - Break generic cleanup/refactoring patches into standalone series,
> remove those from this series
> - Link to dependency: https://lore.kernel.org/all/20251022-vsock-selftests-fixes-and-improvements-v1-0-edeb179d6463@meta.com/
> - Link to v7: https://lore.kernel.org/r/20251021-vsock-vmtest-v7-0-0661b7b6f081@meta.com
>
> Changes in v7:
> - fix hv_sock build
> - break out vmtest patches into distinct, more well-scoped patches
> - change `orig_net_mode` to `net_mode`
> - many fixes and style changes in per-patch change sets (see individual
> patches for specific changes)
> - optimize `virtio_vsock_skb_cb` layout
> - update commit messages with more useful descriptions
> - vsock_loopback: use orig_net_mode instead of current net mode
> - add tests for edge cases (ns deletion, mode changing, loopback module
> load ordering)
> - Link to v6: https://lore.kernel.org/r/20250916-vsock-vmtest-v6-0-064d2eb0c89d@meta.com
>
> Changes in v6:
> - define behavior when mode changes to local while socket/VM is alive
> - af_vsock: clarify description of CID behavior
> - af_vsock: use stronger langauge around CID rules (dont use "may")
> - af_vsock: improve naming of buf/buffer
> - af_vsock: improve string length checking on proc writes
> - vsock_loopback: add space in struct to clarify lock protection
> - vsock_loopback: do proper cleanup/unregister on vsock_loopback_exit()
> - vsock_loopback: use virtio_vsock_skb_net() instead of sock_net()
> - vsock_loopback: set loopback to NULL after kfree()
> - vsock_loopback: use pernet_operations and remove callback mechanism
> - vsock_loopback: add macros for "global" and "local"
> - vsock_loopback: fix length checking
> - vmtest.sh: check for namespace support in vmtest.sh
> - Link to v5: https://lore.kernel.org/r/20250827-vsock-vmtest-v5-0-0ba580bede5b@meta.com
>
> Changes in v5:
> - /proc/net/vsock_ns_mode -> /proc/sys/net/vsock/ns_mode
> - vsock_global_net -> vsock_global_dummy_net
> - fix netns lookup in vhost_vsock to respect pid namespaces
> - add callbacks for vsock_loopback to avoid circular dependency
> - vmtest.sh loads vsock_loopback module
> - remove vsock_net_mode_can_set()
> - change vsock_net_write_mode() to return true/false based on success
> - make vsock_net_mode enum instead of u8
> - Link to v4: https://lore.kernel.org/r/20250805-vsock-vmtest-v4-0-059ec51ab111@meta.com
>
> Changes in v4:
> - removed RFC tag
> - implemented loopback support
> - renamed new tests to better reflect behavior
> - completed suite of tests with permutations of ns modes and vsock_test
> as guest/host
> - simplified socat bridging with unix socket instead of tcp + veth
> - only use vsock_test for success case, socat for failure case (context
> in commit message)
> - lots of cleanup
>
> Changes in v3:
> - add notion of "modes"
> - add procfs /proc/net/vsock_ns_mode
> - local and global modes only
> - no /dev/vhost-vsock-netns
> - vmtest.sh already merged, so new patch just adds new tests for NS
> - Link to v2:
> https://lore.kernel.org/kvm/20250312-vsock-netns-v2-0-84bffa1aa97a@gmail.com
>
> Changes in v2:
> - only support vhost-vsock namespaces
> - all g2h namespaces retain old behavior, only common API changes
> impacted by vhost-vsock changes
> - add /dev/vhost-vsock-netns for "opt-in"
> - leave /dev/vhost-vsock to old behavior
> - removed netns module param
> - Link to v1:
> https://lore.kernel.org/r/20200116172428.311437-1-sgarzare@redhat.com
>
> Changes in v1:
> - added 'netns' module param to vsock.ko to enable the
> network namespace support (disabled by default)
> - added 'vsock_net_eq()' to check the "net" assigned to a socket
> only when 'netns' support is enabled
> - Link to RFC: https://patchwork.ozlabs.org/cover/1202235/
>
> ---
> Bobby Eshleman (12):
> vsock: add netns to vsock core
> virtio: set skb owner of virtio_transport_reset_no_sock() reply
> vsock: add netns support to virtio transports
> selftests/vsock: increase timeout to 1200
> selftests/vsock: add namespace helpers to vmtest.sh
> selftests/vsock: prepare vm management helpers for namespaces
> selftests/vsock: add vm_dmesg_{warn,oops}_count() helpers
> selftests/vsock: use ss to wait for listeners instead of /proc/net
> selftests/vsock: add tests for proc sys vsock ns_mode
> selftests/vsock: add namespace tests for CID collisions
> selftests/vsock: add tests for host <-> vm connectivity with namespaces
> selftests/vsock: add tests for namespace deletion
>
> MAINTAINERS | 1 +
> drivers/vhost/vsock.c | 44 +-
> include/linux/virtio_vsock.h | 9 +-
> include/net/af_vsock.h | 61 +-
> include/net/net_namespace.h | 4 +
> include/net/netns/vsock.h | 21 +
> net/vmw_vsock/af_vsock.c | 335 +++++++++-
> net/vmw_vsock/hyperv_transport.c | 7 +-
> net/vmw_vsock/virtio_transport.c | 22 +-
> net/vmw_vsock/virtio_transport_common.c | 62 +-
> net/vmw_vsock/vmci_transport.c | 26 +-
> net/vmw_vsock/vsock_loopback.c | 22 +-
> tools/testing/selftests/vsock/settings | 2 +-
> tools/testing/selftests/vsock/vmtest.sh | 1055 +++++++++++++++++++++++++++++--
> 14 files changed, 1531 insertions(+), 140 deletions(-)
> ---
> base-commit: d8f87aa5fa0a4276491fa8ef436cd22605a3f9ba
> change-id: 20250325-vsock-vmtest-b3a21d2102c2
>
> Best regards,
> --
> Bobby Eshleman <bobbyeshleman@meta.com>
^ permalink raw reply
* Re: [PATCH net-next v16 00/12] vsock: add namespace support to vhost-vsock and loopback
From: Bobby Eshleman @ 2026-01-22 16:01 UTC (permalink / raw)
To: Stefano Garzarella
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Stefan Hajnoczi, Michael S. Tsirkin, Jason Wang,
Eugenio Pérez, Xuan Zhuo, K. Y. Srinivasan, Haiyang Zhang,
Wei Liu, Dexuan Cui, Bryan Tan, Vishnu Dasa,
Broadcom internal kernel review list, Shuah Khan, Long Li,
Jonathan Corbet, linux-kernel, virtualization, netdev, kvm,
linux-hyperv, linux-kselftest, berrange, Sargun Dhillon,
linux-doc, Bobby Eshleman
In-Reply-To: <aXH7YCgl0qI2dF1T@sgarzare-redhat>
On Thu, Jan 22, 2026 at 02:55:36PM +0100, Stefano Garzarella wrote:
> On Wed, Jan 21, 2026 at 02:11:40PM -0800, Bobby Eshleman wrote:
> > This series adds namespace support to vhost-vsock and loopback. It does
> > not add namespaces to any of the other guest transports (virtio-vsock,
> > hyperv, or vmci).
> >
> > The current revision supports two modes: local and global. Local
> > mode is complete isolation of namespaces, while global mode is complete
> > sharing between namespaces of CIDs (the original behavior).
> >
> > The mode is set using the parent namespace's
> > /proc/sys/net/vsock/child_ns_mode and inherited when a new namespace is
> > created. The mode of the current namespace can be queried by reading
> > /proc/sys/net/vsock/ns_mode. The mode can not change after the namespace
> > has been created.
> >
> > Modes are per-netns. This allows a system to configure namespaces
> > independently (some may share CIDs, others are completely isolated).
> > This also supports future possible mixed use cases, where there may be
> > namespaces in global mode spinning up VMs while there are mixed mode
> > namespaces that provide services to the VMs, but are not allowed to
> > allocate from the global CID pool (this mode is not implemented in this
> > series).
> >
> > Additionally, added tests for the new namespace features:
> >
> > tools/testing/selftests/vsock/vmtest.sh
> > 1..25
> > ok 1 vm_server_host_client
> > ok 2 vm_client_host_server
> > ok 3 vm_loopback
> > ok 4 ns_host_vsock_ns_mode_ok
> > ok 5 ns_host_vsock_child_ns_mode_ok
> > ok 6 ns_global_same_cid_fails
> > ok 7 ns_local_same_cid_ok
> > ok 8 ns_global_local_same_cid_ok
> > ok 9 ns_local_global_same_cid_ok
> > ok 10 ns_diff_global_host_connect_to_global_vm_ok
> > ok 11 ns_diff_global_host_connect_to_local_vm_fails
> > ok 12 ns_diff_global_vm_connect_to_global_host_ok
> > ok 13 ns_diff_global_vm_connect_to_local_host_fails
> > ok 14 ns_diff_local_host_connect_to_local_vm_fails
> > ok 15 ns_diff_local_vm_connect_to_local_host_fails
> > ok 16 ns_diff_global_to_local_loopback_local_fails
> > ok 17 ns_diff_local_to_global_loopback_fails
> > ok 18 ns_diff_local_to_local_loopback_fails
> > ok 19 ns_diff_global_to_global_loopback_ok
> > ok 20 ns_same_local_loopback_ok
> > ok 21 ns_same_local_host_connect_to_local_vm_ok
> > ok 22 ns_same_local_vm_connect_to_local_host_ok
> > ok 23 ns_delete_vm_ok
> > ok 24 ns_delete_host_ok
> > ok 25 ns_delete_both_ok
> > SUMMARY: PASS=25 SKIP=0 FAIL=0
> >
> > Thanks again for everyone's help and reviews!
>
> Thank you for your hard work and patience!
>
> I think we've come up with an excellent solution that's also not too
> invasive.
Thanks, and I appreciate all of the work you and other maintainers put
into this as well! I think we honed in on a great solution too.
>
> All the patches have my R-b, I've double-checked and tested this v16.
> Everything seems to be working fine (famous last words xD).
>
> So this series is good to go IMO!
>
> Next step should be to update the vsock(7) namespace.
Sounds good, I'll follow up with that and CC you + other reviewers that
participated here.
Thanks again,
Bobby
^ permalink raw reply
* Re: [PATCH net-next v16 00/12] vsock: add namespace support to vhost-vsock and loopback
From: Stefano Garzarella @ 2026-01-22 13:55 UTC (permalink / raw)
To: Bobby Eshleman
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Stefan Hajnoczi, Michael S. Tsirkin, Jason Wang,
Eugenio Pérez, Xuan Zhuo, K. Y. Srinivasan, Haiyang Zhang,
Wei Liu, Dexuan Cui, Bryan Tan, Vishnu Dasa,
Broadcom internal kernel review list, Shuah Khan, Long Li,
Jonathan Corbet, linux-kernel, virtualization, netdev, kvm,
linux-hyperv, linux-kselftest, berrange, Sargun Dhillon,
linux-doc, Bobby Eshleman
In-Reply-To: <20260121-vsock-vmtest-v16-0-2859a7512097@meta.com>
On Wed, Jan 21, 2026 at 02:11:40PM -0800, Bobby Eshleman wrote:
>This series adds namespace support to vhost-vsock and loopback. It does
>not add namespaces to any of the other guest transports (virtio-vsock,
>hyperv, or vmci).
>
>The current revision supports two modes: local and global. Local
>mode is complete isolation of namespaces, while global mode is complete
>sharing between namespaces of CIDs (the original behavior).
>
>The mode is set using the parent namespace's
>/proc/sys/net/vsock/child_ns_mode and inherited when a new namespace is
>created. The mode of the current namespace can be queried by reading
>/proc/sys/net/vsock/ns_mode. The mode can not change after the namespace
>has been created.
>
>Modes are per-netns. This allows a system to configure namespaces
>independently (some may share CIDs, others are completely isolated).
>This also supports future possible mixed use cases, where there may be
>namespaces in global mode spinning up VMs while there are mixed mode
>namespaces that provide services to the VMs, but are not allowed to
>allocate from the global CID pool (this mode is not implemented in this
>series).
>
>Additionally, added tests for the new namespace features:
>
>tools/testing/selftests/vsock/vmtest.sh
>1..25
>ok 1 vm_server_host_client
>ok 2 vm_client_host_server
>ok 3 vm_loopback
>ok 4 ns_host_vsock_ns_mode_ok
>ok 5 ns_host_vsock_child_ns_mode_ok
>ok 6 ns_global_same_cid_fails
>ok 7 ns_local_same_cid_ok
>ok 8 ns_global_local_same_cid_ok
>ok 9 ns_local_global_same_cid_ok
>ok 10 ns_diff_global_host_connect_to_global_vm_ok
>ok 11 ns_diff_global_host_connect_to_local_vm_fails
>ok 12 ns_diff_global_vm_connect_to_global_host_ok
>ok 13 ns_diff_global_vm_connect_to_local_host_fails
>ok 14 ns_diff_local_host_connect_to_local_vm_fails
>ok 15 ns_diff_local_vm_connect_to_local_host_fails
>ok 16 ns_diff_global_to_local_loopback_local_fails
>ok 17 ns_diff_local_to_global_loopback_fails
>ok 18 ns_diff_local_to_local_loopback_fails
>ok 19 ns_diff_global_to_global_loopback_ok
>ok 20 ns_same_local_loopback_ok
>ok 21 ns_same_local_host_connect_to_local_vm_ok
>ok 22 ns_same_local_vm_connect_to_local_host_ok
>ok 23 ns_delete_vm_ok
>ok 24 ns_delete_host_ok
>ok 25 ns_delete_both_ok
>SUMMARY: PASS=25 SKIP=0 FAIL=0
>
>Thanks again for everyone's help and reviews!
Thank you for your hard work and patience!
I think we've come up with an excellent solution that's also not too
invasive.
All the patches have my R-b, I've double-checked and tested this v16.
Everything seems to be working fine (famous last words xD).
So this series is good to go IMO!
Next step should be to update the vsock(7) namespace.
Thanks,
Stefano
^ permalink raw reply
* [PATCH] mshv: clear eventfd counter on irqfd shutdown
From: Carlos López @ 2026-01-22 11:41 UTC (permalink / raw)
To: linux-hyperv
Cc: Carlos López, K. Y. Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, open list
While unhooking from the irqfd waitqueue, clear the internal eventfd
counter by using eventfd_ctx_remove_wait_queue() instead of
remove_wait_queue(), preventing potential spurious interrupts. This
removes the need to store a pointer into the workqueue, as the eventfd
already keeps track of it.
This mimicks what other similar subsystems do on their equivalent paths
with their irqfds (KVM, Xen, ACRN support, etc).
Signed-off-by: Carlos López <clopez@suse.de>
---
drivers/hv/mshv_eventfd.c | 5 ++---
drivers/hv/mshv_eventfd.h | 1 -
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/hv/mshv_eventfd.c b/drivers/hv/mshv_eventfd.c
index d93a18f09c76..4432063e963d 100644
--- a/drivers/hv/mshv_eventfd.c
+++ b/drivers/hv/mshv_eventfd.c
@@ -247,12 +247,13 @@ static void mshv_irqfd_shutdown(struct work_struct *work)
{
struct mshv_irqfd *irqfd =
container_of(work, struct mshv_irqfd, irqfd_shutdown);
+ u64 cnt;
/*
* Synchronize with the wait-queue and unhook ourselves to prevent
* further events.
*/
- remove_wait_queue(irqfd->irqfd_wqh, &irqfd->irqfd_wait);
+ eventfd_ctx_remove_wait_queue(irqfd->irqfd_eventfd_ctx, &irqfd->irqfd_wait, &cnt);
if (irqfd->irqfd_resampler) {
mshv_irqfd_resampler_shutdown(irqfd);
@@ -371,8 +372,6 @@ static void mshv_irqfd_queue_proc(struct file *file, wait_queue_head_t *wqh,
struct mshv_irqfd *irqfd =
container_of(polltbl, struct mshv_irqfd, irqfd_polltbl);
- irqfd->irqfd_wqh = wqh;
-
/*
* TODO: Ensure there isn't already an exclusive, priority waiter, e.g.
* that the irqfd isn't already bound to another partition. Only the
diff --git a/drivers/hv/mshv_eventfd.h b/drivers/hv/mshv_eventfd.h
index 332e7670a344..464c6b81ab33 100644
--- a/drivers/hv/mshv_eventfd.h
+++ b/drivers/hv/mshv_eventfd.h
@@ -32,7 +32,6 @@ struct mshv_irqfd {
struct mshv_lapic_irq irqfd_lapic_irq;
struct hlist_node irqfd_hnode;
poll_table irqfd_polltbl;
- wait_queue_head_t *irqfd_wqh;
wait_queue_entry_t irqfd_wait;
struct work_struct irqfd_shutdown;
struct mshv_irqfd_resampler *irqfd_resampler;
base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
--
2.51.0
^ permalink raw reply related
* Re: [PATCH net-next 2/9] net: atlantic: convert to use .get_rx_ring_count
From: Breno Leitao @ 2026-01-22 10:43 UTC (permalink / raw)
To: Creeley, Brett
Cc: Ajit Khaparde, Sriharsha Basavapatna, Somnath Kotur, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Igor Russkikh, Simon Horman, K. Y. Srinivasan, Haiyang Zhang,
Wei Liu, Dexuan Cui, Long Li, Alexander Duyck, kernel-team,
Edward Cree, Brett Creeley, netdev, linux-kernel, oss-drivers,
linux-hyperv, linux-net-drivers
In-Reply-To: <4daf0901-20a6-4c9b-9b56-32efef24e5e5@amd.com>
Hello Brett,
On Wed, Jan 21, 2026 at 08:49:23AM -0800, Creeley, Brett wrote:
> On 1/21/2026 7:54 AM, Breno Leitao wrote:
> > Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
> >
> >
> > Use the newly introduced .get_rx_ring_count ethtool ops callback instead
> > of handling ETHTOOL_GRXRINGS directly in .get_rxnfc().
> >
> > Signed-off-by: Breno Leitao <leitao@debian.org>
> > ---
> > drivers/net/ethernet/aquantia/atlantic/aq_ethtool.c | 15 +++++++++------
> > 1 file changed, 9 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/aquantia/atlantic/aq_ethtool.c b/drivers/net/ethernet/aquantia/atlantic/aq_ethtool.c
> > index 6fef47ba0a59b..d8b5491c9cb2b 100644
> > --- a/drivers/net/ethernet/aquantia/atlantic/aq_ethtool.c
> > +++ b/drivers/net/ethernet/aquantia/atlantic/aq_ethtool.c
> > @@ -500,20 +500,22 @@ static int aq_ethtool_set_rss(struct net_device *netdev,
> > return err;
> > }
> >
> > +static u32 aq_ethtool_get_rx_ring_count(struct net_device *ndev)
> > +{
> > + struct aq_nic_s *aq_nic = netdev_priv(ndev);
> > + struct aq_nic_cfg_s *cfg = aq_nic_get_cfg(aq_nic);
> > +
> > + return cfg->vecs;
> > +}
> > +
>
> Tiny nit, but RCT ordering is not maintained.
Damn, I will re-spin. Thanks for catching it.
--breno
--
pw-bot: cr
^ 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