* Re: [PATCH] mshv: Extend create partition ioctl to support cpu features
From: kernel test robot @ 2025-10-29 15:34 UTC (permalink / raw)
To: Nuno Das Neves, linux-hyperv, linux-kernel, muislam
Cc: oe-kbuild-all, kys, haiyangz, wei.liu, decui, longli, mhklinux,
skinsburskii, romank, Jinank Jain, Nuno Das Neves
In-Reply-To: <1761685562-6272-1-git-send-email-nunodasneves@linux.microsoft.com>
Hi Nuno,
kernel test robot noticed the following build errors:
[auto build test ERROR on linus/master]
[also build test ERROR on v6.18-rc3 next-20251029]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Nuno-Das-Neves/mshv-Extend-create-partition-ioctl-to-support-cpu-features/20251029-050748
base: linus/master
patch link: https://lore.kernel.org/r/1761685562-6272-1-git-send-email-nunodasneves%40linux.microsoft.com
patch subject: [PATCH] mshv: Extend create partition ioctl to support cpu features
config: x86_64-rhel-9.4-ltp (https://download.01.org/0day-ci/archive/20251029/202510292330.LCHvPCLt-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251029/202510292330.LCHvPCLt-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202510292330.LCHvPCLt-lkp@intel.com/
All errors (new ones prefixed by >>):
>> error: include/uapi/linux/mshv.h: leak CONFIG_X86_64 to user-space
make[3]: *** [scripts/Makefile.headersinst:63: usr/include/linux/mshv.h] Error 1
make[3]: Target '__headers' not remade because of errors.
make[2]: *** [Makefile:1378: headers] Error 2
make[2]: Target 'prepare' not remade because of errors.
make[1]: *** [Makefile:248: __sub-make] Error 2
make[1]: Target 'prepare' not remade because of errors.
make: *** [Makefile:248: __sub-make] Error 2
make: Target 'prepare' not remade because of errors.
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [net-next,v4] net: mana: Support HW link state events
From: Haiyang Zhang @ 2025-10-29 20:43 UTC (permalink / raw)
To: linux-hyperv, netdev, K. Y. Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Long Li, Konstantin Taranov,
Simon Horman, Leon Romanovsky, Shradha Gupta, Maxim Levitsky,
Erni Sri Satya Vennela, Yury Norov, Dipayaan Roy, Shiraz Saleem,
Saurabh Sengar, linux-kernel, linux-rdma
Cc: paulros
From: Haiyang Zhang <haiyangz@microsoft.com>
Handle the NIC hardware link state events received from the HW
channel, then set the proper link state accordingly.
And, add a feature bit, GDMA_DRV_CAP_FLAG_1_HW_VPORT_LINK_AWARE,
to inform the NIC hardware this handler exists.
Our MANA NIC only sends out the link state down/up messages
when we need to let the VM rerun DHCP client and change IP
address. So, add netif_carrier_on() in the probe(), let the NIC
show the right initial state in /sys/class/net/ethX/operstate.
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
---
v4:
Remove the netif_carrier_ok(), and add READ/WRITE_ONCE. Also,
more details in the commit message as suggested by Jakub Kicinski.
v3:
Don't stop / start the queues, and use disable_work_sync() as
suggested by Jakub Kicinski.
v2:
Updated link up/down to be symmetric, and other minor changes based
on comments from Andrew Lunn.
---
.../net/ethernet/microsoft/mana/gdma_main.c | 1 +
.../net/ethernet/microsoft/mana/hw_channel.c | 12 +++++
drivers/net/ethernet/microsoft/mana/mana_en.c | 54 +++++++++++++++++--
include/net/mana/gdma.h | 4 +-
include/net/mana/hw_channel.h | 2 +
include/net/mana/mana.h | 4 ++
6 files changed, 71 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/microsoft/mana/gdma_main.c b/drivers/net/ethernet/microsoft/mana/gdma_main.c
index 43f034e180c4..effe0a2f207a 100644
--- a/drivers/net/ethernet/microsoft/mana/gdma_main.c
+++ b/drivers/net/ethernet/microsoft/mana/gdma_main.c
@@ -528,6 +528,7 @@ static void mana_gd_process_eqe(struct gdma_queue *eq)
case GDMA_EQE_HWC_INIT_DONE:
case GDMA_EQE_HWC_SOC_SERVICE:
case GDMA_EQE_RNIC_QP_FATAL:
+ case GDMA_EQE_HWC_SOC_RECONFIG_DATA:
if (!eq->eq.callback)
break;
diff --git a/drivers/net/ethernet/microsoft/mana/hw_channel.c b/drivers/net/ethernet/microsoft/mana/hw_channel.c
index ada6c78a2bef..aa4e2731e2ba 100644
--- a/drivers/net/ethernet/microsoft/mana/hw_channel.c
+++ b/drivers/net/ethernet/microsoft/mana/hw_channel.c
@@ -118,6 +118,7 @@ static void mana_hwc_init_event_handler(void *ctx, struct gdma_queue *q_self,
struct gdma_dev *gd = hwc->gdma_dev;
union hwc_init_type_data type_data;
union hwc_init_eq_id_db eq_db;
+ struct mana_context *ac;
u32 type, val;
int ret;
@@ -196,6 +197,17 @@ static void mana_hwc_init_event_handler(void *ctx, struct gdma_queue *q_self,
hwc->hwc_timeout = val;
break;
+ case HWC_DATA_HW_LINK_CONNECT:
+ case HWC_DATA_HW_LINK_DISCONNECT:
+ ac = gd->gdma_context->mana.driver_data;
+ if (!ac)
+ break;
+
+ WRITE_ONCE(ac->link_event, type);
+ schedule_work(&ac->link_change_work);
+
+ break;
+
default:
dev_warn(hwc->dev, "Received unknown reconfig type %u\n", type);
break;
diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c b/drivers/net/ethernet/microsoft/mana/mana_en.c
index 0142fd98392c..739087081dfd 100644
--- a/drivers/net/ethernet/microsoft/mana/mana_en.c
+++ b/drivers/net/ethernet/microsoft/mana/mana_en.c
@@ -20,6 +20,7 @@
#include <net/mana/mana.h>
#include <net/mana/mana_auxiliary.h>
+#include <net/mana/hw_channel.h>
static DEFINE_IDA(mana_adev_ida);
@@ -84,7 +85,6 @@ static int mana_open(struct net_device *ndev)
/* Ensure port state updated before txq state */
smp_wmb();
- netif_carrier_on(ndev);
netif_tx_wake_all_queues(ndev);
netdev_dbg(ndev, "%s successful\n", __func__);
return 0;
@@ -100,6 +100,46 @@ static int mana_close(struct net_device *ndev)
return mana_detach(ndev, true);
}
+static void mana_link_state_handle(struct work_struct *w)
+{
+ struct mana_context *ac;
+ struct net_device *ndev;
+ u32 link_event;
+ bool link_up;
+ int i;
+
+ ac = container_of(w, struct mana_context, link_change_work);
+
+ rtnl_lock();
+
+ link_event = READ_ONCE(ac->link_event);
+
+ if (link_event == HWC_DATA_HW_LINK_CONNECT)
+ link_up = true;
+ else if (link_event == HWC_DATA_HW_LINK_DISCONNECT)
+ link_up = false;
+ else
+ goto out;
+
+ /* Process all ports */
+ for (i = 0; i < ac->num_ports; i++) {
+ ndev = ac->ports[i];
+ if (!ndev)
+ continue;
+
+ if (link_up) {
+ netif_carrier_on(ndev);
+
+ __netdev_notify_peers(ndev);
+ } else {
+ netif_carrier_off(ndev);
+ }
+ }
+
+out:
+ rtnl_unlock();
+}
+
static bool mana_can_tx(struct gdma_queue *wq)
{
return mana_gd_wq_avail_space(wq) >= MAX_TX_WQE_SIZE;
@@ -3059,9 +3099,6 @@ int mana_attach(struct net_device *ndev)
/* Ensure port state updated before txq state */
smp_wmb();
- if (apc->port_is_up)
- netif_carrier_on(ndev);
-
netif_device_attach(ndev);
return 0;
@@ -3154,7 +3191,6 @@ int mana_detach(struct net_device *ndev, bool from_close)
smp_wmb();
netif_tx_disable(ndev);
- netif_carrier_off(ndev);
if (apc->port_st_save) {
err = mana_dealloc_queues(ndev);
@@ -3243,6 +3279,8 @@ static int mana_probe_port(struct mana_context *ac, int port_idx,
goto free_indir;
}
+ netif_carrier_on(ndev);
+
debugfs_create_u32("current_speed", 0400, apc->mana_port_debugfs, &apc->speed);
return 0;
@@ -3431,6 +3469,8 @@ int mana_probe(struct gdma_dev *gd, bool resuming)
if (!resuming) {
ac->num_ports = num_ports;
+
+ INIT_WORK(&ac->link_change_work, mana_link_state_handle);
} else {
if (ac->num_ports != num_ports) {
dev_err(dev, "The number of vPorts changed: %d->%d\n",
@@ -3438,6 +3478,8 @@ int mana_probe(struct gdma_dev *gd, bool resuming)
err = -EPROTO;
goto out;
}
+
+ enable_work(&ac->link_change_work);
}
if (ac->num_ports == 0)
@@ -3500,6 +3542,8 @@ void mana_remove(struct gdma_dev *gd, bool suspending)
int err;
int i;
+ disable_work_sync(&ac->link_change_work);
+
/* adev currently doesn't support suspending, always remove it */
if (gd->adev)
remove_adev(gd);
diff --git a/include/net/mana/gdma.h b/include/net/mana/gdma.h
index 57df78cfbf82..637f42485dba 100644
--- a/include/net/mana/gdma.h
+++ b/include/net/mana/gdma.h
@@ -590,6 +590,7 @@ enum {
/* Driver can self reset on FPGA Reconfig EQE notification */
#define GDMA_DRV_CAP_FLAG_1_HANDLE_RECONFIG_EQE BIT(17)
+#define GDMA_DRV_CAP_FLAG_1_HW_VPORT_LINK_AWARE BIT(6)
#define GDMA_DRV_CAP_FLAGS1 \
(GDMA_DRV_CAP_FLAG_1_EQ_SHARING_MULTI_VPORT | \
@@ -599,7 +600,8 @@ enum {
GDMA_DRV_CAP_FLAG_1_DEV_LIST_HOLES_SUP | \
GDMA_DRV_CAP_FLAG_1_DYNAMIC_IRQ_ALLOC_SUPPORT | \
GDMA_DRV_CAP_FLAG_1_SELF_RESET_ON_EQE | \
- GDMA_DRV_CAP_FLAG_1_HANDLE_RECONFIG_EQE)
+ GDMA_DRV_CAP_FLAG_1_HANDLE_RECONFIG_EQE | \
+ GDMA_DRV_CAP_FLAG_1_HW_VPORT_LINK_AWARE)
#define GDMA_DRV_CAP_FLAGS2 0
diff --git a/include/net/mana/hw_channel.h b/include/net/mana/hw_channel.h
index 83cf93338eb3..16feb39616c1 100644
--- a/include/net/mana/hw_channel.h
+++ b/include/net/mana/hw_channel.h
@@ -24,6 +24,8 @@
#define HWC_INIT_DATA_PF_DEST_CQ_ID 11
#define HWC_DATA_CFG_HWC_TIMEOUT 1
+#define HWC_DATA_HW_LINK_CONNECT 2
+#define HWC_DATA_HW_LINK_DISCONNECT 3
#define HW_CHANNEL_WAIT_RESOURCE_TIMEOUT_MS 30000
diff --git a/include/net/mana/mana.h b/include/net/mana/mana.h
index 0921485565c0..8906901535f5 100644
--- a/include/net/mana/mana.h
+++ b/include/net/mana/mana.h
@@ -477,6 +477,10 @@ struct mana_context {
struct dentry *mana_eqs_debugfs;
struct net_device *ports[MAX_PORTS_IN_MANA_DEV];
+
+ /* Link state change work */
+ struct work_struct link_change_work;
+ u32 link_event;
};
struct mana_port_context {
--
2.34.1
^ permalink raw reply related
* Re: [RFC] Making vma_to_pfn() public (due to vm_pgoff change)
From: Jason Gunthorpe @ 2025-10-29 20:44 UTC (permalink / raw)
To: Mukesh R
Cc: alex.williamson, joe, kvm, linux-kernel@vger.kernel.org,
linux-hyperv@vger.kernel.org, wei.liu@kernel.org
In-Reply-To: <a9b8a3ee-b35b-5c45-5042-2466607abcd0@linux.microsoft.com>
On Mon, Oct 27, 2025 at 02:21:56PM -0700, Mukesh R wrote:
> Hi Alex,
>
> This regards vfio passthru support on hyperv running linux as dom0 aka
> root. At a high level, cloud hypervisor uses vfio for set up as usual,
> then maps the mmio ranges via the hyperv linux driver ioctls.
>
> Over a year ago, when working on this I had used vm_pgoff to get the pfn
> for the mmio, that was 5.15 and early 6.x kernels. Now that I am porting
> to 6.18 for upstreaming, I noticed:
>
> commit aac6db75a9fc
> Author: Alex Williamson <alex.williamson@redhat.com>
> vfio/pci: Use unmap_mapping_range()
>
> changed the behavior and vm_pgoff is no longer holding the pfn. In light
> of that, I wondered if the following minor change, making vma_to_pfn()
> public (after renaming it), would be acceptable to you.
No way, no driver should be looking into VMAs like this - it is
already a known security problem.
Is this "hyperv linux driver ioctls" upstream?
You should probably be looking to use the coming DMABUF stuff instead.
Jason
^ permalink raw reply
* Re: [PATCH net-next v2] net: mana: Implement ndo_tx_timeout and serialize queue resets per port.
From: Jakub Kicinski @ 2025-10-30 1:22 UTC (permalink / raw)
To: Dipayaan Roy
Cc: kys, haiyangz, wei.liu, decui, andrew+netdev, davem, edumazet,
pabeni, longli, kotaranov, horms, shradhagupta, ssengar, ernis,
shirazsaleem, linux-hyperv, netdev, linux-kernel, linux-rdma,
dipayanroy
In-Reply-To: <20251027201351.GA8995@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
On Mon, 27 Oct 2025 13:13:51 -0700 Dipayaan Roy wrote:
> Implement .ndo_tx_timeout for MANA so any stalled TX queue can be detected
> and a device-controlled port reset for all queues can be scheduled to a
> ordered workqueue. The reset for all queues on stall detection is
> recomended by hardware team.
>
> The change introduces a single ordered workqueue
> ("mana_per_port_queue_reset_wq") with WQ_UNBOUND | WQ_MEM_RECLAIM and
> queues exactly one work_struct per port onto it. This achieves:
>
> * Global FIFO across all port reset requests (alloc_ordered_workqueue).
Why does this matter?
> * Natural per-port de-duplication: the same work_struct cannot be
> queued twice while pending/running.
That's true for all work_structs even without a separate wq.
> * Avoids hogging a per-CPU kworker for long, may-sleep reset paths
> (WQ_UNBOUND).
?
> * Guarantees forward progress during memory pressure
> (WQ_MEM_RECLAIM rescuer).
? meaning? What scenario are you preventing?
> Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
> Signed-off-by: Dipayaan Roy <dipayanroy@linux.microsoft.com>
> ---
> Changes in v2:
> - Fixed cosmetic changes.
> ---
> drivers/net/ethernet/microsoft/mana/mana_en.c | 82 +++++++++++++++++++
> include/net/mana/gdma.h | 6 +-
> include/net/mana/mana.h | 15 ++++
> 3 files changed, 102 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c b/drivers/net/ethernet/microsoft/mana/mana_en.c
> index f4fc86f20213..05b7046ae3b5 100644
> --- a/drivers/net/ethernet/microsoft/mana/mana_en.c
> +++ b/drivers/net/ethernet/microsoft/mana/mana_en.c
> @@ -258,6 +258,45 @@ static int mana_get_gso_hs(struct sk_buff *skb)
> return gso_hs;
> }
>
> +static void mana_per_port_queue_reset_work_handler(struct work_struct *work)
> +{
> + struct mana_queue_reset_work *reset_queue_work =
> + container_of(work, struct mana_queue_reset_work, work);
> + struct mana_port_context *apc = reset_queue_work->apc;
> + struct net_device *ndev = apc->ndev;
> + struct mana_context *ac = apc->ac;
> + int err;
> +
> + if (!rtnl_trylock()) {
Use disable_work_sync() in the remove path and you won't have to do
the retry dance, right?
> + /* Someone else holds RTNL, requeue and exit. */
> + queue_work(ac->per_port_queue_reset_wq,
> + &apc->queue_reset_work.work);
> + return;
> + }
> +static void mana_tx_timeout(struct net_device *netdev, unsigned int txqueue)
> +{
> + struct mana_port_context *apc = netdev_priv(netdev);
> + struct mana_context *ac = apc->ac;
> + struct gdma_context *gc = ac->gdma_dev->gdma_context;
> +
> + netdev_warn(netdev, "%s(): called on txq: %u\n", __func__, txqueue);
I believe that core already prints this sort of thing, please don't
duplicate.
> + /* Already in service, hence tx queue reset is not required.*/
> + if (gc->in_service)
> + return;
> +
> + /* Note: If there are pending queue reset work for this port(apc),
> + * subsequent request queued up from here are ignored. This is because
> + * we are using the same work instance per port(apc).
> + */
> + queue_work(ac->per_port_queue_reset_wq, &apc->queue_reset_work.work);
> +}
> +
> static int mana_shaper_set(struct net_shaper_binding *binding,
> const struct net_shaper *shaper,
> struct netlink_ext_ack *extack)
> @@ -844,7 +902,9 @@ static const struct net_device_ops mana_devops = {
> .ndo_bpf = mana_bpf,
> .ndo_xdp_xmit = mana_xdp_xmit,
> .ndo_change_mtu = mana_change_mtu,
> + .ndo_tx_timeout = mana_tx_timeout,
other ndos were aligned with tabs you're using spaces
> .net_shaper_ops = &mana_shaper_ops,
> +
> };
>
> static void mana_cleanup_port_context(struct mana_port_context *apc)
> @@ -3218,6 +3278,7 @@ static int mana_probe_port(struct mana_context *ac, int port_idx,
> ndev->min_mtu = ETH_MIN_MTU;
> ndev->needed_headroom = MANA_HEADROOM;
> ndev->dev_port = port_idx;
> + ndev->watchdog_timeo = MANA_TXQ_TIMEOUT;
why you need a define for this is unclear. You can use 15 * HZ here
directly
> SET_NETDEV_DEV(ndev, gc->dev);
>
> netif_set_tso_max_size(ndev, GSO_MAX_SIZE);
> @@ -3255,6 +3316,11 @@ static int mana_probe_port(struct mana_context *ac, int port_idx,
>
> debugfs_create_u32("current_speed", 0400, apc->mana_port_debugfs, &apc->speed);
>
> + /* Initialize the per port queue reset work.*/
> + apc->queue_reset_work.apc = apc;
> + INIT_WORK(&apc->queue_reset_work.work,
> + mana_per_port_queue_reset_work_handler);
> +
> return 0;
>
> free_indir:
> @@ -3456,6 +3522,15 @@ int mana_probe(struct gdma_dev *gd, bool resuming)
> if (ac->num_ports > MAX_PORTS_IN_MANA_DEV)
> ac->num_ports = MAX_PORTS_IN_MANA_DEV;
>
> + ac->per_port_queue_reset_wq =
> + alloc_ordered_workqueue("mana_per_port_queue_reset_wq",
> + WQ_UNBOUND | WQ_MEM_RECLAIM);
> + if (!ac->per_port_queue_reset_wq) {
> + dev_err(dev, "Failed to allocate per port queue reset workqueue\n");
> + err = -ENOMEM;
> + goto out;
> + }
> +
> if (!resuming) {
> for (i = 0; i < ac->num_ports; i++) {
> err = mana_probe_port(ac, i, &ac->ports[i]);
> @@ -3528,6 +3603,8 @@ void mana_remove(struct gdma_dev *gd, bool suspending)
> */
> rtnl_lock();
>
> + cancel_work_sync(&apc->queue_reset_work.work);
> +
> err = mana_detach(ndev, false);
> if (err)
> netdev_err(ndev, "Failed to detach vPort %d: %d\n",
> @@ -3547,6 +3624,11 @@ void mana_remove(struct gdma_dev *gd, bool suspending)
> free_netdev(ndev);
> }
>
> + if (ac->per_port_queue_reset_wq) {
> + destroy_workqueue(ac->per_port_queue_reset_wq);
> + ac->per_port_queue_reset_wq = NULL;
> + }
> +
> mana_destroy_eq(ac);
> out:
> mana_gd_deregister_device(gd);
> diff --git a/include/net/mana/gdma.h b/include/net/mana/gdma.h
> index 57df78cfbf82..1f8c536ba3be 100644
> --- a/include/net/mana/gdma.h
> +++ b/include/net/mana/gdma.h
> @@ -591,6 +591,9 @@ enum {
> /* Driver can self reset on FPGA Reconfig EQE notification */
> #define GDMA_DRV_CAP_FLAG_1_HANDLE_RECONFIG_EQE BIT(17)
>
> +/* Driver detects stalled send queues and recovers them */
> +#define GDMA_DRV_CAP_FLAG_1_HANDLE_STALL_SQ_RECOVERY BIT(18)
> +
> #define GDMA_DRV_CAP_FLAGS1 \
> (GDMA_DRV_CAP_FLAG_1_EQ_SHARING_MULTI_VPORT | \
> GDMA_DRV_CAP_FLAG_1_NAPI_WKDONE_FIX | \
> @@ -599,7 +602,8 @@ enum {
> GDMA_DRV_CAP_FLAG_1_DEV_LIST_HOLES_SUP | \
> GDMA_DRV_CAP_FLAG_1_DYNAMIC_IRQ_ALLOC_SUPPORT | \
> GDMA_DRV_CAP_FLAG_1_SELF_RESET_ON_EQE | \
> - GDMA_DRV_CAP_FLAG_1_HANDLE_RECONFIG_EQE)
> + GDMA_DRV_CAP_FLAG_1_HANDLE_RECONFIG_EQE | \
> + GDMA_DRV_CAP_FLAG_1_HANDLE_STALL_SQ_RECOVERY)
>
> #define GDMA_DRV_CAP_FLAGS2 0
>
> diff --git a/include/net/mana/mana.h b/include/net/mana/mana.h
> index 0921485565c0..e0b44ae2226a 100644
> --- a/include/net/mana/mana.h
> +++ b/include/net/mana/mana.h
> @@ -67,6 +67,11 @@ enum TRI_STATE {
>
> #define MANA_RX_FRAG_ALIGNMENT 64
>
> +/* Timeout value for Txq stall detection & recovery used by ndo_tx_timeout.
> + * The value is chosen after considering fpga re-config scenarios.
> + */
> +#define MANA_TXQ_TIMEOUT (15 * HZ)
> +
> struct mana_stats_rx {
> u64 packets;
> u64 bytes;
> @@ -475,13 +480,23 @@ struct mana_context {
>
> struct mana_eq *eqs;
> struct dentry *mana_eqs_debugfs;
> + struct workqueue_struct *per_port_queue_reset_wq;
>
> struct net_device *ports[MAX_PORTS_IN_MANA_DEV];
> };
>
> +struct mana_queue_reset_work {
> +
nit spurious empty line
> + /* Work structure */
> + struct work_struct work;
> + /* Pointer to the port context */
> + struct mana_port_context *apc;
This struct is placed in apc, unclear why you need a backpointer
instead of using container_of()
> +};
> +
> struct mana_port_context {
> struct mana_context *ac;
> struct net_device *ndev;
> + struct mana_queue_reset_work queue_reset_work;
>
> u8 mac_addr[ETH_ALEN];
>
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net-next v2] net: mana: Fix incorrect speed reported by debugfs
From: Jakub Kicinski @ 2025-10-30 1:52 UTC (permalink / raw)
To: Erni Sri Satya Vennela
Cc: kys, haiyangz, wei.liu, decui, andrew+netdev, davem, edumazet,
pabeni, shradhagupta, ssengar, dipayanroy, shirazsaleem,
kotaranov, longli, linux-hyperv, netdev, linux-kernel
In-Reply-To: <1761735154-3593-1-git-send-email-ernis@linux.microsoft.com>
On Wed, 29 Oct 2025 03:52:34 -0700 Erni Sri Satya Vennela wrote:
> Fixes: 75cabb46935b ("net: mana: Add support for net_shaper_ops")
I've preferred this without the fixes tag, TBH.
It's debugfs, nobody is supposed to be using it in production.
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH v6 02/10] x86/acpi: Move acpi_wakeup_cpu() and helpers to smpwakeup.c
From: Ricardo Neri @ 2025-10-30 5:43 UTC (permalink / raw)
To: Borislav Petkov
Cc: x86, Krzysztof Kozlowski, Conor Dooley, Rob Herring,
K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui,
Michael Kelley, Rafael J. Wysocki, Saurabh Sengar, Chris Oo,
Kirill A. Shutemov, linux-hyperv, devicetree, linux-acpi,
linux-kernel, Ricardo Neri, Rafael J. Wysocki, Yunhong Jiang
In-Reply-To: <20251029111358.GDaQH29lURT0p_WWsb@fat_crate.local>
On Wed, Oct 29, 2025 at 12:13:58PM +0100, Borislav Petkov wrote:
> On Mon, Oct 27, 2025 at 01:58:16PM -0700, Ricardo Neri wrote:
> > Right. All the functions in the file start with the acpi_ prefix. It could
> > be kept under arch/x86/kernel/acpi/. The Kconfig symbol X86_MAILBOX_WAKEUP
> > would have to live in arch/x86/Kconfig as there is no Kconfig file under
> > arch/x86/kernel/acpi. ACPI_MADT_WAKEUP is arch/x86/Kconfig.
> >
> > Does that sound acceptable?
>
> Right, this looks kinda weird. You have devicetree thing using ACPI code,
> you're trying to carve it out but then it is ACPI code anyway. So why even do
> that?
>
> You can simply leave ACPI enabled on that configuration. I don't see yet what
> the point for the split is - saving memory, or...?
I did not want to enable the whole of ACPI code as I need a tiny portion of it.
Then yes, saving memory and having a smaller binary were considerations.
The only dependency that ACPI_MADT_WAKEUP has on ACPI is the code to read and
parse the ACPI table that enumerates the mailbox. (There are a couple of
declarations for CPU offlining that need tweaking if I want ACPI_MADT_WAKEUP to
not depend on ACPI at all).
The DeviceTree firmware only needs the code to wake CPUs up. That is the code
I am carving out.
Having said that, vmlinux and bzImage increase by 4% if I enable ACPI.
Thanks and BR,
Ricardo
^ permalink raw reply
* Re: [PATCH net-next v2] net: mana: Handle SKB if TX SGEs exceed hardware limit
From: Simon Horman @ 2025-10-30 9:04 UTC (permalink / raw)
To: Aditya Garg
Cc: kys, haiyangz, wei.liu, decui, andrew+netdev, davem, edumazet,
kuba, pabeni, longli, kotaranov, shradhagupta, ssengar, ernis,
dipayanroy, shirazsaleem, linux-hyperv, netdev, linux-kernel,
linux-rdma, gargaditya
In-Reply-To: <20251029131235.GA3903@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
On Wed, Oct 29, 2025 at 06:12:35AM -0700, Aditya Garg wrote:
> The MANA hardware supports a maximum of 30 scatter-gather entries (SGEs)
> per TX WQE. Exceeding this limit can cause TX failures.
> Add ndo_features_check() callback to validate SKB layout before
> transmission. For GSO SKBs that would exceed the hardware SGE limit, clear
> NETIF_F_GSO_MASK to enforce software segmentation in the stack.
> Add a fallback in mana_start_xmit() to linearize non-GSO SKBs that still
> exceed the SGE limit.
>
> Return NETDEV_TX_BUSY only for -ENOSPC from mana_gd_post_work_request(),
> send other errors to free_sgl_ptr to free resources and record the tx
> drop.
>
> Co-developed-by: Dipayaan Roy <dipayanroy@linux.microsoft.com>
> Signed-off-by: Dipayaan Roy <dipayanroy@linux.microsoft.com>
> Signed-off-by: Aditya Garg <gargaditya@linux.microsoft.com>
...
> @@ -289,6 +290,21 @@ netdev_tx_t mana_start_xmit(struct sk_buff *skb, struct net_device *ndev)
> cq = &apc->tx_qp[txq_idx].tx_cq;
> tx_stats = &txq->stats;
>
> + if (MAX_SKB_FRAGS + 2 > MAX_TX_WQE_SGL_ENTRIES &&
> + skb_shinfo(skb)->nr_frags + 2 > MAX_TX_WQE_SGL_ENTRIES) {
> + /* GSO skb with Hardware SGE limit exceeded is not expected here
> + * as they are handled in mana_features_check() callback
> + */
Hi,
I'm curious to know if we actually need this code.
Are there cases where the mana_features_check() doesn't
handle things and the kernel will reach this line?
> + if (skb_is_gso(skb))
> + netdev_warn_once(ndev, "GSO enabled skb exceeds max SGE limit\n");
> + if (skb_linearize(skb)) {
> + netdev_warn_once(ndev, "Failed to linearize skb with nr_frags=%d and is_gso=%d\n",
> + skb_shinfo(skb)->nr_frags,
> + skb_is_gso(skb));
> + goto tx_drop_count;
> + }
> + }
> +
> pkg.tx_oob.s_oob.vcq_num = cq->gdma_id;
> pkg.tx_oob.s_oob.vsq_frame = txq->vsq_frame;
>
...
^ permalink raw reply
* [PATCH v2] mshv: Extend create partition ioctl to support cpu features
From: Nuno Das Neves @ 2025-10-30 21:40 UTC (permalink / raw)
To: linux-hyperv, linux-kernel, muislam
Cc: kys, haiyangz, wei.liu, decui, longli, mhklinux, skinsburskii,
romank, Jinank Jain, Nuno Das Neves
From: Muminul Islam <muislam@microsoft.com>
The existing mshv create partition ioctl does not provide a way to
specify which cpu features are enabled in the guest. This was done
to reduce unnecessary complexity in the API.
However, some new scenarios require fine-grained control over the
cpu feature bits.
Define a new mshv_create_partition_v2 structure which supports passing
through the disabled cpu flags and xsave flags to the hypervisor
directly.
When these are not specified (pt_num_cpu_fbanks == 0) or the old
structure is used, define a set of default flags which cover most
cases.
Retain backward compatibility with the old structure via a new flag
MSHV_PT_BIT_CPU_AND_XSAVE_FEATURES which enables the new struct.
Co-developed-by: Jinank Jain <jinankjain@microsoft.com>
Signed-off-by: Jinank Jain <jinankjain@microsoft.com>
Signed-off-by: Muminul Islam <muislam@microsoft.com>
Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
---
Changes in v2:
- Fix compilation issues [kernel test robot]
---
drivers/hv/mshv_root_main.c | 176 ++++++++++++++++++++++++++++++++----
include/hyperv/hvhdk.h | 86 +++++++++++++++++-
include/uapi/linux/mshv.h | 34 +++++++
3 files changed, 272 insertions(+), 24 deletions(-)
diff --git a/drivers/hv/mshv_root_main.c b/drivers/hv/mshv_root_main.c
index d542a0143bb8..ef2c6d9f0a11 100644
--- a/drivers/hv/mshv_root_main.c
+++ b/drivers/hv/mshv_root_main.c
@@ -1900,43 +1900,181 @@ add_partition(struct mshv_partition *partition)
return 0;
}
-static long
-mshv_ioctl_create_partition(void __user *user_arg, struct device *module_dev)
+static_assert(MSHV_NUM_CPU_FEATURES_BANKS <=
+ HV_PARTITION_PROCESSOR_FEATURES_BANKS);
+
+static long mshv_ioctl_process_pt_flags(void __user *user_arg, u64 *pt_flags,
+ struct hv_partition_creation_properties *cr_props,
+ union hv_partition_isolation_properties *isol_props)
{
- struct mshv_create_partition args;
- u64 creation_flags;
- struct hv_partition_creation_properties creation_properties = {};
- union hv_partition_isolation_properties isolation_properties = {};
- struct mshv_partition *partition;
- struct file *file;
- int fd;
- long ret;
+ int i;
+ struct mshv_create_partition_v2 args;
+ union hv_partition_processor_features *disabled_procs;
+ union hv_partition_processor_xsave_features *disabled_xsave;
- if (copy_from_user(&args, user_arg, sizeof(args)))
+ /* First, copy orig struct in case user is on previous versions */
+ if (copy_from_user(&args, user_arg,
+ sizeof(struct mshv_create_partition)))
return -EFAULT;
if ((args.pt_flags & ~MSHV_PT_FLAGS_MASK) ||
- args.pt_isolation >= MSHV_PT_ISOLATION_COUNT)
+ args.pt_isolation >= MSHV_PT_ISOLATION_COUNT)
return -EINVAL;
+ disabled_procs = &cr_props->disabled_processor_features;
+
+ /* Disable all processor features first */
+ for (i = 0; i < HV_PARTITION_PROCESSOR_FEATURES_BANKS; i++)
+ disabled_procs->as_uint64[i] = -1;
+
+#if IS_ENABLED(CONFIG_X86_64)
+ /* Enable default features that are known to be supported */
+ disabled_procs->cet_ibt_support = 0;
+ disabled_procs->cet_ss_support = 0;
+ disabled_procs->smep_support = 0;
+ disabled_procs->rdtscp_support = 0;
+ disabled_procs->tsc_invariant_support = 0;
+ disabled_procs->sse3_support = 0;
+ disabled_procs->lahf_sahf_support = 0;
+ disabled_procs->ssse3_support = 0;
+ disabled_procs->sse4_1_support = 0;
+ disabled_procs->sse4_2_support = 0;
+ disabled_procs->sse4a_support = 0;
+ disabled_procs->xop_support = 0;
+ disabled_procs->pop_cnt_support = 0;
+ disabled_procs->cmpxchg16b_support = 0;
+ disabled_procs->altmovcr8_support = 0;
+ disabled_procs->lzcnt_support = 0;
+ disabled_procs->mis_align_sse_support = 0;
+ disabled_procs->mmx_ext_support = 0;
+ disabled_procs->amd3dnow_support = 0;
+ disabled_procs->extended_amd3dnow_support = 0;
+ disabled_procs->aes_support = 0;
+ disabled_procs->pclmulqdq_support = 0;
+ disabled_procs->pcid_support = 0;
+ disabled_procs->fma4_support = 0;
+ disabled_procs->f16c_support = 0;
+ disabled_procs->rd_rand_support = 0;
+ disabled_procs->rd_wr_fs_gs_support = 0;
+ disabled_procs->enhanced_fast_string_support = 0;
+ disabled_procs->bmi1_support = 0;
+ disabled_procs->bmi2_support = 0;
+ disabled_procs->hle_support_deprecated = 0;
+ disabled_procs->rtm_support_deprecated = 0;
+ disabled_procs->movbe_support = 0;
+ disabled_procs->npiep1_support = 0;
+ disabled_procs->dep_x87_fpu_save_support = 0;
+ disabled_procs->rd_seed_support = 0;
+ disabled_procs->adx_support = 0;
+ disabled_procs->intel_prefetch_support = 0;
+ disabled_procs->smap_support = 0;
+ disabled_procs->hle_support = 0;
+ disabled_procs->rtm_support = 0;
+ disabled_procs->invpcid_support = 0;
+ disabled_procs->ibrs_support = 0;
+ disabled_procs->stibp_support = 0;
+ disabled_procs->mdd_support = 0;
+ disabled_procs->ibpb_support = 0;
+ disabled_procs->l1dcache_flush_support = 0;
+ disabled_procs->virt_spec_ctrl_support = 0;
+ disabled_procs->mb_clear_support = 0;
+ disabled_procs->tsx_ctrl_support = 0;
+ disabled_procs->clflushopt_support = 0;
+ disabled_procs->rdcl_no_support = 0;
+ disabled_procs->ibrs_all_support = 0;
+ disabled_procs->page_1gb_support = 0;
+ disabled_procs->skip_l1df_support = 0;
+ disabled_procs->ssb_no_support = 0;
+ disabled_procs->mbs_no_support = 0;
+ disabled_procs->taa_no_support = 0;
+ disabled_procs->fb_clear_support = 0;
+ disabled_procs->gds_no_support = 0;
+ disabled_procs->bhi_no_support = 0;
+ disabled_procs->bhi_dis_support = 0;
+ disabled_procs->btc_no_support = 0;
+ disabled_procs->mitigation_ctrl_support = 0;
+ disabled_procs->rfds_no_support = 0;
+ disabled_procs->rfds_clear_support = 0;
+ disabled_procs->unrestricted_guest_support = 0;
+ disabled_procs->fast_short_rep_mov_support = 0;
+ disabled_procs->rsb_a_no_support = 0;
+ disabled_procs->rd_pid_support = 0;
+ disabled_procs->umip_support = 0;
+ disabled_procs->vmx_exception_inject_support = 0;
+ disabled_procs->rdpru_support = 0;
+ disabled_procs->mbec_support = 0;
+ disabled_procs->psfd_support = 0;
+
+ /* Enable default XSave features that are known to be supported*/
+ disabled_xsave = &cr_props->disabled_processor_xsave_features;
+ disabled_xsave->as_uint64 = -1;
+ disabled_xsave->xsave_support = 0;
+ disabled_xsave->xsaveopt_support = 0;
+ disabled_xsave->avx_support = 0;
+ disabled_xsave->xsave_supervisor_support = 0;
+ disabled_xsave->xsave_comp_support = 0;
+#endif
+ /* Check if user provided newer struct with feature fields */
+ if (args.pt_flags & BIT(MSHV_PT_BIT_CPU_AND_XSAVE_FEATURES)) {
+ if (copy_from_user(&args, user_arg, sizeof(args)))
+ return -EFAULT;
+
+ if (args.pt_num_cpu_fbanks > MSHV_NUM_CPU_FEATURES_BANKS ||
+ mshv_field_nonzero(args, pt_rsvd) ||
+ mshv_field_nonzero(args, pt_rsvd1))
+ return -EINVAL;
+
+ for (i = 0; i < args.pt_num_cpu_fbanks; i++)
+ disabled_procs->as_uint64[i] = args.pt_cpu_fbanks[i];
+
+#if IS_ENABLED(CONFIG_X86_64)
+ disabled_xsave->as_uint64 = args.pt_disabled_xsave;
+#else
+ if (mshv_field_nonzero(args, pt_rsvd2))
+ return -EINVAL;
+#endif
+ }
+
/* Only support EXO partitions */
- creation_flags = HV_PARTITION_CREATION_FLAG_EXO_PARTITION |
- HV_PARTITION_CREATION_FLAG_INTERCEPT_MESSAGE_PAGE_ENABLED;
+ *pt_flags = HV_PARTITION_CREATION_FLAG_EXO_PARTITION |
+ HV_PARTITION_CREATION_FLAG_INTERCEPT_MESSAGE_PAGE_ENABLED;
if (args.pt_flags & BIT(MSHV_PT_BIT_LAPIC))
- creation_flags |= HV_PARTITION_CREATION_FLAG_LAPIC_ENABLED;
+ *pt_flags |= HV_PARTITION_CREATION_FLAG_LAPIC_ENABLED;
if (args.pt_flags & BIT(MSHV_PT_BIT_X2APIC))
- creation_flags |= HV_PARTITION_CREATION_FLAG_X2APIC_CAPABLE;
+ *pt_flags |= HV_PARTITION_CREATION_FLAG_X2APIC_CAPABLE;
if (args.pt_flags & BIT(MSHV_PT_BIT_GPA_SUPER_PAGES))
- creation_flags |= HV_PARTITION_CREATION_FLAG_GPA_SUPER_PAGES_ENABLED;
+ *pt_flags |= HV_PARTITION_CREATION_FLAG_GPA_SUPER_PAGES_ENABLED;
switch (args.pt_isolation) {
case MSHV_PT_ISOLATION_NONE:
- isolation_properties.isolation_type =
- HV_PARTITION_ISOLATION_TYPE_NONE;
+ isol_props->isolation_type = HV_PARTITION_ISOLATION_TYPE_NONE;
+ break;
+ case MSHV_PT_ISOLATION_SNP:
+ isol_props->isolation_type = HV_PARTITION_ISOLATION_TYPE_SNP;
break;
}
+ return 0;
+}
+
+static long
+mshv_ioctl_create_partition(void __user *user_arg, struct device *module_dev)
+{
+ u64 creation_flags;
+ struct hv_partition_creation_properties creation_properties = {};
+ union hv_partition_isolation_properties isolation_properties = {};
+ struct mshv_partition *partition;
+ struct file *file;
+ int fd;
+ long ret;
+
+ ret = mshv_ioctl_process_pt_flags(user_arg, &creation_flags,
+ &creation_properties,
+ &isolation_properties);
+ if (ret)
+ return ret;
+
partition = kzalloc(sizeof(*partition), GFP_KERNEL);
if (!partition)
return -ENOMEM;
diff --git a/include/hyperv/hvhdk.h b/include/hyperv/hvhdk.h
index 416c0d45b793..221a90ab07fa 100644
--- a/include/hyperv/hvhdk.h
+++ b/include/hyperv/hvhdk.h
@@ -220,10 +220,51 @@ union hv_partition_processor_features {
u64 serialize_support : 1;
u64 tsc_deadline_tmr_support : 1;
u64 tsc_adjust_support : 1;
- u64 fzlrep_movsb : 1;
- u64 fsrep_stosb : 1;
- u64 fsrep_cmpsb : 1;
- u64 reserved_bank1 : 42;
+ u64 fzl_rep_movsb : 1;
+ u64 fs_rep_stosb : 1;
+ u64 fs_rep_cmpsb : 1;
+ u64 tsx_ld_trk_support : 1;
+ u64 vmx_ins_outs_exit_info_support : 1;
+ u64 hlat_support : 1;
+ u64 sbdr_ssdp_no_support : 1;
+ u64 fbsdp_no_support : 1;
+ u64 psdp_no_support : 1;
+ u64 fb_clear_support : 1;
+ u64 btc_no_support : 1;
+ u64 ibpb_rsb_flush_support : 1;
+ u64 stibp_always_on_support : 1;
+ u64 perf_global_ctrl_support : 1;
+ u64 npt_execute_only_support : 1;
+ u64 npt_ad_flags_support : 1;
+ u64 npt1_gb_page_support : 1;
+ u64 amd_processor_topology_node_id_support : 1;
+ u64 local_machine_check_support : 1;
+ u64 extended_topology_leaf_fp256_amd_support : 1;
+ u64 gds_no_support : 1;
+ u64 cmpccxadd_support : 1;
+ u64 tsc_aux_virtualization_support : 1;
+ u64 rmp_query_support : 1;
+ u64 bhi_no_support : 1;
+ u64 bhi_dis_support : 1;
+ u64 prefetch_i_support : 1;
+ u64 sha512_support : 1;
+ u64 mitigation_ctrl_support : 1;
+ u64 rfds_no_support : 1;
+ u64 rfds_clear_support : 1;
+ u64 sm3_support : 1;
+ u64 sm4_support : 1;
+ u64 secure_avic_support : 1;
+ u64 guest_intercept_ctrl_support : 1;
+ u64 sbpb_supported : 1;
+ u64 ibpb_br_type_supported : 1;
+ u64 srso_no_supported : 1;
+ u64 srso_user_kernel_no_supported : 1;
+ u64 vrew_clear_supported : 1;
+ u64 tsa_l1_no_supported : 1;
+ u64 tsa_sq_no_supported : 1;
+ u64 lass_support : 1;
+ /* Remaining reserved bits */
+ u64 reserved_bank1 : 2;
} __packed;
};
@@ -232,7 +273,42 @@ union hv_partition_processor_xsave_features {
u64 xsave_support : 1;
u64 xsaveopt_support : 1;
u64 avx_support : 1;
- u64 reserved1 : 61;
+ u64 avx2_support : 1;
+ u64 fma_support: 1;
+ u64 mpx_support: 1;
+ u64 avx512_support : 1;
+ u64 avx512_dq_support : 1;
+ u64 avx512_cd_support : 1;
+ u64 avx512_bw_support : 1;
+ u64 avx512_vl_support : 1;
+ u64 xsave_comp_support : 1;
+ u64 xsave_supervisor_support : 1;
+ u64 xcr1_support : 1;
+ u64 avx512_bitalg_support : 1;
+ u64 avx512_i_fma_support : 1;
+ u64 avx512_v_bmi_support : 1;
+ u64 avx512_v_bmi2_support : 1;
+ u64 avx512_vnni_support : 1;
+ u64 gfni_support : 1;
+ u64 vaes_support : 1;
+ u64 avx512_v_popcntdq_support : 1;
+ u64 vpclmulqdq_support : 1;
+ u64 avx512_bf16_support : 1;
+ u64 avx512_vp2_intersect_support : 1;
+ u64 avx512_fp16_support : 1;
+ u64 xfd_support : 1;
+ u64 amx_tile_support : 1;
+ u64 amx_bf16_support : 1;
+ u64 amx_int8_support : 1;
+ u64 avx_vnni_support : 1;
+ u64 avx_ifma_support : 1;
+ u64 avx_ne_convert_support : 1;
+ u64 avx_vnni_int8_support : 1;
+ u64 avx_vnni_int16_support : 1;
+ u64 avx10_1_256_support : 1;
+ u64 avx10_1_512_support : 1;
+ u64 amx_fp16_support : 1;
+ u64 reserved1 : 26;
} __packed;
u64 as_uint64;
};
diff --git a/include/uapi/linux/mshv.h b/include/uapi/linux/mshv.h
index 876bfe4e4227..ee5c69da7b29 100644
--- a/include/uapi/linux/mshv.h
+++ b/include/uapi/linux/mshv.h
@@ -26,6 +26,7 @@ enum {
MSHV_PT_BIT_LAPIC,
MSHV_PT_BIT_X2APIC,
MSHV_PT_BIT_GPA_SUPER_PAGES,
+ MSHV_PT_BIT_CPU_AND_XSAVE_FEATURES,
MSHV_PT_BIT_COUNT,
};
@@ -33,6 +34,7 @@ enum {
enum {
MSHV_PT_ISOLATION_NONE,
+ MSHV_PT_ISOLATION_SNP,
MSHV_PT_ISOLATION_COUNT,
};
@@ -41,6 +43,8 @@ enum {
* @pt_flags: Bitmask of 1 << MSHV_PT_BIT_*
* @pt_isolation: MSHV_PT_ISOLATION_*
*
+ * This is the initial/v0 version for backward compatibility.
+ *
* Returns a file descriptor to act as a handle to a guest partition.
* At this point the partition is not yet initialized in the hypervisor.
* Some operations must be done with the partition in this state, e.g. setting
@@ -52,6 +56,36 @@ struct mshv_create_partition {
__u64 pt_isolation;
};
+#define MSHV_NUM_CPU_FEATURES_BANKS 2
+
+/**
+ * struct mshv_create_partition_v2
+ *
+ * This is extended version of the above initial MSHV_CREATE_PARTITION
+ * ioctl and allows for following additional parameters:
+ *
+ * @pt_num_cpu_fbanks: number of processor feature banks being provided.
+ * This must not exceed MSHV_NUM_CPU_FEATURES_BANKS.
+ * @pt_cpu_fbanks: processor feature banks array
+ * @pt_disabled_xsave: disabled xsave feature bits. Refer to
+ * union hv_partition_processor_xsave_feature
+ *
+ * Returns : same as above original mshv_create_partition
+ */
+struct mshv_create_partition_v2 {
+ __u64 pt_flags;
+ __u64 pt_isolation;
+ __u16 pt_num_cpu_fbanks;
+ __u8 pt_rsvd[6]; /* MBZ */
+ __u64 pt_cpu_fbanks[MSHV_NUM_CPU_FEATURES_BANKS];
+ __u64 pt_rsvd1[2]; /* MBZ */
+#if defined(__x86_64__)
+ __u64 pt_disabled_xsave;
+#else
+ __u64 pt_rsvd2; /* MBZ */
+#endif
+} __packed;
+
/* /dev/mshv */
#define MSHV_CREATE_PARTITION _IOW(MSHV_IOCTL, 0x00, struct mshv_create_partition)
--
2.34.1
^ permalink raw reply related
* [PATCH] x86/hyperv: Use pointer from memcpy() call for assignment in hv_crash_setup_trampdata()
From: Markus Elfring @ 2025-10-31 8:33 UTC (permalink / raw)
To: linux-hyperv, x86, Borislav Petkov, Dave Hansen, Dexuan Cui,
Haiyang Zhang, H. Peter Anvin, Ingo Molnar, K. Y. Srinivasan,
Long Li, Mukesh Rathor, Thomas Gleixner, Wei Liu
Cc: LKML, kernel-janitors, Miaoqian Lin
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Fri, 31 Oct 2025 09:24:31 +0100
A pointer was assigned to a variable. The same pointer was used for
the destination parameter of a memcpy() call.
This function is documented in the way that the same value is returned.
Thus convert two separate statements into a direct variable assignment for
the return value from a memory copy action.
The source code was transformed by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
arch/x86/hyperv/hv_crash.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/x86/hyperv/hv_crash.c b/arch/x86/hyperv/hv_crash.c
index c0e22921ace1..745d02066308 100644
--- a/arch/x86/hyperv/hv_crash.c
+++ b/arch/x86/hyperv/hv_crash.c
@@ -464,9 +464,7 @@ static int hv_crash_setup_trampdata(u64 trampoline_va)
return -1;
}
- dest = (void *)trampoline_va;
- memcpy(dest, &hv_crash_asm32, size);
-
+ dest = memcpy((void *)trampoline_va, &hv_crash_asm32, size);
dest += size;
dest = (void *)round_up((ulong)dest, 16);
tramp = (struct hv_crash_tramp_data *)dest;
--
2.51.1
^ permalink raw reply related
* Re: [PATCH] x86/hyperv: Use pointer from memcpy() call for assignment in hv_crash_setup_trampdata()
From: Naman Jain @ 2025-10-31 9:28 UTC (permalink / raw)
To: Markus Elfring, linux-hyperv, x86, Borislav Petkov, Dave Hansen,
Dexuan Cui, Haiyang Zhang, H. Peter Anvin, Ingo Molnar,
K. Y. Srinivasan, Long Li, Mukesh Rathor, Thomas Gleixner,
Wei Liu
Cc: LKML, kernel-janitors, Miaoqian Lin
In-Reply-To: <d209991b-5aee-4222-aec3-cb662ccb7433@web.de>
On 10/31/2025 2:03 PM, Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Fri, 31 Oct 2025 09:24:31 +0100
>
> A pointer was assigned to a variable. The same pointer was used for
> the destination parameter of a memcpy() call.
> This function is documented in the way that the same value is returned.
> Thus convert two separate statements into a direct variable assignment for
> the return value from a memory copy action.
>
> The source code was transformed by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
> arch/x86/hyperv/hv_crash.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/arch/x86/hyperv/hv_crash.c b/arch/x86/hyperv/hv_crash.c
> index c0e22921ace1..745d02066308 100644
> --- a/arch/x86/hyperv/hv_crash.c
> +++ b/arch/x86/hyperv/hv_crash.c
> @@ -464,9 +464,7 @@ static int hv_crash_setup_trampdata(u64 trampoline_va)
> return -1;
> }
>
> - dest = (void *)trampoline_va;
> - memcpy(dest, &hv_crash_asm32, size);
> -
> + dest = memcpy((void *)trampoline_va, &hv_crash_asm32, size);
> dest += size;
> dest = (void *)round_up((ulong)dest, 16);
> tramp = (struct hv_crash_tramp_data *)dest;
I tried running spatch Coccinelle checks on this file, but could not get
it to flag this improvement. Do you mind sharing more details on the
issue reproduction please.
I am OK with this change, though it may cost code readability a little
bit. But if this is a result of some known standard rule, added as part
of these Coccinelle rules, we should be good.
Regards,
Naman
^ permalink raw reply
* Re: [PATCH] x86/hyperv: Use pointer from memcpy() call for assignment in hv_crash_setup_trampdata()
From: Julia Lawall @ 2025-10-31 9:37 UTC (permalink / raw)
To: Naman Jain
Cc: Markus Elfring, linux-hyperv, x86, Borislav Petkov, Dave Hansen,
Dexuan Cui, Haiyang Zhang, H. Peter Anvin, Ingo Molnar,
K. Y. Srinivasan, Long Li, Mukesh Rathor, Thomas Gleixner,
Wei Liu, LKML, kernel-janitors, Miaoqian Lin
In-Reply-To: <cea9d987-0231-4131-82ac-9ba8c852f963@linux.microsoft.com>
On Fri, 31 Oct 2025, Naman Jain wrote:
>
>
> On 10/31/2025 2:03 PM, Markus Elfring wrote:
> > From: Markus Elfring <elfring@users.sourceforge.net>
> > Date: Fri, 31 Oct 2025 09:24:31 +0100
> >
> > A pointer was assigned to a variable. The same pointer was used for
> > the destination parameter of a memcpy() call.
> > This function is documented in the way that the same value is returned.
> > Thus convert two separate statements into a direct variable assignment for
> > the return value from a memory copy action.
> >
> > The source code was transformed by using the Coccinelle software.
> >
> > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> > ---
> > arch/x86/hyperv/hv_crash.c | 4 +---
> > 1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/arch/x86/hyperv/hv_crash.c b/arch/x86/hyperv/hv_crash.c
> > index c0e22921ace1..745d02066308 100644
> > --- a/arch/x86/hyperv/hv_crash.c
> > +++ b/arch/x86/hyperv/hv_crash.c
> > @@ -464,9 +464,7 @@ static int hv_crash_setup_trampdata(u64 trampoline_va)
> > return -1;
> > }
> > - dest = (void *)trampoline_va;
> > - memcpy(dest, &hv_crash_asm32, size);
> > -
> > + dest = memcpy((void *)trampoline_va, &hv_crash_asm32, size);
> > dest += size;
> > dest = (void *)round_up((ulong)dest, 16);
> > tramp = (struct hv_crash_tramp_data *)dest;
>
>
> I tried running spatch Coccinelle checks on this file, but could not get it to
> flag this improvement. Do you mind sharing more details on the issue
> reproduction please.
>
> I am OK with this change, though it may cost code readability a little bit.
> But if this is a result of some known standard rule, added as part of these
> Coccinelle rules, we should be good.
Multiple people have suggested that due to the loos of readability the
change is not a good idea.
It's not done by a standard rule.
julia
^ permalink raw reply
* Re: [PATCH] x86/hyperv: Use pointer from memcpy() call for assignment in hv_crash_setup_trampdata()
From: Markus Elfring @ 2025-10-31 9:44 UTC (permalink / raw)
To: Naman Jain, linux-hyperv, x86, Borislav Petkov, Dave Hansen,
Dexuan Cui, Haiyang Zhang, H. Peter Anvin, Ingo Molnar,
K. Y. Srinivasan, Long Li, Mukesh Rathor, Thomas Gleixner,
Wei Liu
Cc: LKML, kernel-janitors, Miaoqian Lin
In-Reply-To: <cea9d987-0231-4131-82ac-9ba8c852f963@linux.microsoft.com>
…>> +++ b/arch/x86/hyperv/hv_crash.c
>> @@ -464,9 +464,7 @@ static int hv_crash_setup_trampdata(u64 trampoline_va)
>> return -1;
>> }
>> - dest = (void *)trampoline_va;
>> - memcpy(dest, &hv_crash_asm32, size);
>> -
>> + dest = memcpy((void *)trampoline_va, &hv_crash_asm32, size);
>> dest += size;
>> dest = (void *)round_up((ulong)dest, 16);
>> tramp = (struct hv_crash_tramp_data *)dest;
>
>
> I tried running spatch Coccinelle checks on this file, but could not get it to flag this improvement.
The proposed source code transformation is not supported by a coccicheck script so far.
> Do you mind sharing more details on the issue reproduction please.
Would you like to take another look at corresponding development discussions?
Example:
[RFC] Increasing usage of direct pointer assignments from memcpy() calls with SmPL?
https://lore.kernel.org/cocci/ddc8654a-9505-451f-87ad-075bfa646381@web.de/
https://sympa.inria.fr/sympa/arc/cocci/2025-10/msg00049.html
> I am OK with this change,
Thanks for a bit of positive feedback.
> though it may cost code readability a little bit.
Would you complain about other variable assignments in such a direction?
Regards,
Markus
^ permalink raw reply
* Re: [PATCH] x86/hyperv: Use pointer from memcpy() call for assignment in hv_crash_setup_trampdata()
From: Naman Jain @ 2025-10-31 12:32 UTC (permalink / raw)
To: Markus Elfring, linux-hyperv, x86, Borislav Petkov, Dave Hansen,
Dexuan Cui, Haiyang Zhang, H. Peter Anvin, Ingo Molnar,
K. Y. Srinivasan, Long Li, Mukesh Rathor, Thomas Gleixner,
Wei Liu
Cc: LKML, kernel-janitors, Miaoqian Lin
In-Reply-To: <17da2cdc-7fdd-43d1-91d5-36425615588a@web.de>
On 10/31/2025 3:14 PM, Markus Elfring wrote:
> …>> +++ b/arch/x86/hyperv/hv_crash.c
>>> @@ -464,9 +464,7 @@ static int hv_crash_setup_trampdata(u64 trampoline_va)
>>> return -1;
>>> }
>>> - dest = (void *)trampoline_va;
>>> - memcpy(dest, &hv_crash_asm32, size);
>>> -
>>> + dest = memcpy((void *)trampoline_va, &hv_crash_asm32, size);
>>> dest += size;
>>> dest = (void *)round_up((ulong)dest, 16);
>>> tramp = (struct hv_crash_tramp_data *)dest;
>>
>>
>> I tried running spatch Coccinelle checks on this file, but could not get it to flag this improvement.
>
> The proposed source code transformation is not supported by a coccicheck script so far.
>
>
>> Do you mind sharing more details on the issue reproduction please.
>
> Would you like to take another look at corresponding development discussions?
>
> Example:
> [RFC] Increasing usage of direct pointer assignments from memcpy() calls with SmPL?
> https://lore.kernel.org/cocci/ddc8654a-9505-451f-87ad-075bfa646381@web.de/
> https://sympa.inria.fr/sympa/arc/cocci/2025-10/msg00049.html
>
>
>> I am OK with this change,
>
> Thanks for a bit of positive feedback.
>
>
>> though it may cost code readability a little bit.
>
> Would you complain about other variable assignments in such a direction?
>
> Regards,
> Markus
The only thing which concerns readability IMO is that it is based on the
assumption that the person reading the code is aware of the return value
of memcpy. Now, it is debatable if that is something which can be
considered trivial. I don't have a strong opinion there, but would
prefer it in its current form.
Also, we could have optimized it further by writing it as below, but we
are not doing that for a reason as we want to keep the code simpler to
read and understand. The same may apply here as well.
dest = memcpy((void *)trampoline_va, &hv_crash_asm32, size) + size;
Regards,
Naman
^ permalink raw reply
* Re: [PATCH net-next v2] net: mana: Handle SKB if TX SGEs exceed hardware limit
From: Aditya Garg @ 2025-10-31 13:20 UTC (permalink / raw)
To: Simon Horman
Cc: kys, haiyangz, wei.liu, decui, andrew+netdev, davem, edumazet,
kuba, pabeni, longli, kotaranov, shradhagupta, ssengar, ernis,
dipayanroy, shirazsaleem, linux-hyperv, netdev, linux-kernel,
linux-rdma, gargaditya
In-Reply-To: <aQMqLN0FRmNU3_ke@horms.kernel.org>
On 30-10-2025 14:34, Simon Horman wrote:
> On Wed, Oct 29, 2025 at 06:12:35AM -0700, Aditya Garg wrote:
>> The MANA hardware supports a maximum of 30 scatter-gather entries (SGEs)
>> per TX WQE. Exceeding this limit can cause TX failures.
>> Add ndo_features_check() callback to validate SKB layout before
>> transmission. For GSO SKBs that would exceed the hardware SGE limit, clear
>> NETIF_F_GSO_MASK to enforce software segmentation in the stack.
>> Add a fallback in mana_start_xmit() to linearize non-GSO SKBs that still
>> exceed the SGE limit.
>>
>> Return NETDEV_TX_BUSY only for -ENOSPC from mana_gd_post_work_request(),
>> send other errors to free_sgl_ptr to free resources and record the tx
>> drop.
>>
>> Co-developed-by: Dipayaan Roy <dipayanroy@linux.microsoft.com>
>> Signed-off-by: Dipayaan Roy <dipayanroy@linux.microsoft.com>
>> Signed-off-by: Aditya Garg <gargaditya@linux.microsoft.com>
>
> ...
>
>> @@ -289,6 +290,21 @@ netdev_tx_t mana_start_xmit(struct sk_buff *skb, struct net_device *ndev)
>> cq = &apc->tx_qp[txq_idx].tx_cq;
>> tx_stats = &txq->stats;
>>
>> + if (MAX_SKB_FRAGS + 2 > MAX_TX_WQE_SGL_ENTRIES &&
>> + skb_shinfo(skb)->nr_frags + 2 > MAX_TX_WQE_SGL_ENTRIES) {
>> + /* GSO skb with Hardware SGE limit exceeded is not expected here
>> + * as they are handled in mana_features_check() callback
>> + */
>
> Hi,
>
> I'm curious to know if we actually need this code.
> Are there cases where the mana_features_check() doesn't
> handle things and the kernel will reach this line?
>
>> + if (skb_is_gso(skb))
>> + netdev_warn_once(ndev, "GSO enabled skb exceeds max SGE limit\n");
>> + if (skb_linearize(skb)) {
>> + netdev_warn_once(ndev, "Failed to linearize skb with nr_frags=%d and is_gso=%d\n",
>> + skb_shinfo(skb)->nr_frags,
>> + skb_is_gso(skb));
>> + goto tx_drop_count;
>> + }
>> + }
>> +
>> pkg.tx_oob.s_oob.vcq_num = cq->gdma_id;
>> pkg.tx_oob.s_oob.vsq_frame = txq->vsq_frame;
>>
>
> ...
Hi Simon,
As it was previously discussed and agreed on with Eric, this is for
Non-GSO skbs which could have possibly nr_frags greater than hardware limit.
Quoting Eric's comment from v1 thread:
https://lore.kernel.org/netdev/CANn89iKwHWdUaeAsdSuZUXG-W8XwyM2oppQL9spKkex0p9-Azw@mail.gmail.com/
"I think that for non GSO, the linearization attempt is fine.
Note that this is extremely unlikely for non malicious users,
and MTU being usually small (9K or less),
the allocation will be much smaller than a GSO packet."
Regards,
Aditya
^ permalink raw reply
* Re: [PATCH] hv: fix missing kernel-doc description for 'size' in request_arr_init()
From: Wei Liu @ 2025-10-31 17:54 UTC (permalink / raw)
To: kriish.sharma2006
Cc: kys, haiyangz, wei.liu, decui, longli, linux-hyperv, linux-kernel,
kernel test robot
In-Reply-To: <20251025120707.686825-1-kriish.sharma2006@gmail.com>
On Sat, Oct 25, 2025 at 12:07:07PM +0000, kriish.sharma2006@gmail.com wrote:
> From: Kriish Sharma <kriish.sharma2006@gmail.com>
>
> Add missing kernel-doc entry for the @size parameter in
> request_arr_init(), fixing the following documentation warning
> reported by the kernel test robot and detected via kernel-doc:
>
> Warning: drivers/hv/channel.c:595 function parameter 'size' not described in 'request_arr_init'
>
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202503021934.wH1BERla-lkp@intel.com
> Signed-off-by: Kriish Sharma <kriish.sharma2006@gmail.com>
Applied to hyperv-next.
I changed the subject line to match the existing pattern.
> ---
> drivers/hv/channel.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
> index 88485d255a42..6821f225248b 100644
> --- a/drivers/hv/channel.c
> +++ b/drivers/hv/channel.c
> @@ -590,7 +590,7 @@ EXPORT_SYMBOL_GPL(vmbus_establish_gpadl);
> * keeps track of the next available slot in the array. Initially, each
> * slot points to the next one (as in a Linked List). The last slot
> * does not point to anything, so its value is U64_MAX by default.
> - * @size The size of the array
> + * @size: The size of the array
> */
> static u64 *request_arr_init(u32 size)
> {
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH] x86/hyperv: Use pointer from memcpy() call for assignment in hv_crash_setup_trampdata()
From: Wei Liu @ 2025-10-31 18:26 UTC (permalink / raw)
To: Markus Elfring
Cc: linux-hyperv, x86, Borislav Petkov, Dave Hansen, Dexuan Cui,
Haiyang Zhang, H. Peter Anvin, Ingo Molnar, K. Y. Srinivasan,
Long Li, Mukesh Rathor, Thomas Gleixner, Wei Liu, LKML,
kernel-janitors, Miaoqian Lin
In-Reply-To: <d209991b-5aee-4222-aec3-cb662ccb7433@web.de>
On Fri, Oct 31, 2025 at 09:33:17AM +0100, Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Fri, 31 Oct 2025 09:24:31 +0100
>
> A pointer was assigned to a variable. The same pointer was used for
> the destination parameter of a memcpy() call.
> This function is documented in the way that the same value is returned.
> Thus convert two separate statements into a direct variable assignment for
> the return value from a memory copy action.
>
> The source code was transformed by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
> arch/x86/hyperv/hv_crash.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/arch/x86/hyperv/hv_crash.c b/arch/x86/hyperv/hv_crash.c
> index c0e22921ace1..745d02066308 100644
> --- a/arch/x86/hyperv/hv_crash.c
> +++ b/arch/x86/hyperv/hv_crash.c
> @@ -464,9 +464,7 @@ static int hv_crash_setup_trampdata(u64 trampoline_va)
> return -1;
> }
>
> - dest = (void *)trampoline_va;
> - memcpy(dest, &hv_crash_asm32, size);
> -
> + dest = memcpy((void *)trampoline_va, &hv_crash_asm32, size);
I don't think this change is needed.
There aren't that many places in the kernel tree that use this pattern.
The pattern used by the original code is far more pervasive.
Wei
> dest += size;
> dest = (void *)round_up((ulong)dest, 16);
> tramp = (struct hv_crash_tramp_data *)dest;
> --
> 2.51.1
>
^ permalink raw reply
* Re: [PATCH v2] mshv: Extend create partition ioctl to support cpu features
From: Wei Liu @ 2025-10-31 18:31 UTC (permalink / raw)
To: Nuno Das Neves
Cc: linux-hyperv, linux-kernel, muislam, kys, haiyangz, wei.liu,
decui, longli, mhklinux, skinsburskii, romank, Jinank Jain
In-Reply-To: <1761860431-11208-1-git-send-email-nunodasneves@linux.microsoft.com>
On Thu, Oct 30, 2025 at 02:40:31PM -0700, Nuno Das Neves wrote:
> From: Muminul Islam <muislam@microsoft.com>
>
> The existing mshv create partition ioctl does not provide a way to
> specify which cpu features are enabled in the guest. This was done
> to reduce unnecessary complexity in the API.
>
> However, some new scenarios require fine-grained control over the
> cpu feature bits.
>
> Define a new mshv_create_partition_v2 structure which supports passing
> through the disabled cpu flags and xsave flags to the hypervisor
> directly.
>
> When these are not specified (pt_num_cpu_fbanks == 0) or the old
> structure is used, define a set of default flags which cover most
> cases.
>
> Retain backward compatibility with the old structure via a new flag
> MSHV_PT_BIT_CPU_AND_XSAVE_FEATURES which enables the new struct.
>
> Co-developed-by: Jinank Jain <jinankjain@microsoft.com>
> Signed-off-by: Jinank Jain <jinankjain@microsoft.com>
> Signed-off-by: Muminul Islam <muislam@microsoft.com>
> Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
> ---
> Changes in v2:
> - Fix compilation issues [kernel test robot]
>
> ---
> drivers/hv/mshv_root_main.c | 176 ++++++++++++++++++++++++++++++++----
> include/hyperv/hvhdk.h | 86 +++++++++++++++++-
There is no mention of updating hvhdk.h in the commit message.
Can you split out this part to a separate commit?
Wei
^ permalink raw reply
* Re: [RFC PATCH] Drivers: hv: Resolve ambiguity in hypervisor version log
From: Wei Liu @ 2025-10-31 18:32 UTC (permalink / raw)
To: Nuno Das Neves
Cc: Stanislav Kinsburskii, kys, haiyangz, wei.liu, decui,
linux-hyperv, linux-kernel
In-Reply-To: <fa14e8f8-fe92-4636-9565-a6174edcea71@linux.microsoft.com>
On Fri, Oct 10, 2025 at 03:49:17PM -0700, Nuno Das Neves wrote:
> On 10/8/2025 3:43 PM, Stanislav Kinsburskii wrote:
> > Update the log message in hv_common_init to explicitly state that the
> > reported version is for the Microsoft Hypervisor, not the host OS.
> >
> > Previously, this message was accurate for guests running on Windows
> > hosts, where the host and hypervisor versions matched. With support for
> > Linux hosts running the Hyper-V hypervisor, the host OS and hypervisor
> > versions may differ.
> >
> > This change avoids confusion by making it clear that the version refers to
> > the Microsoft Hypervisor regardless of the host operating system.
> >
> > Signed-off-by: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>
> > ---
> > drivers/hv/hv_common.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/hv/hv_common.c b/drivers/hv/hv_common.c
> > index e109a620c83fc..0289ee4ed5ebf 100644
> > --- a/drivers/hv/hv_common.c
> > +++ b/drivers/hv/hv_common.c
> > @@ -315,9 +315,9 @@ int __init hv_common_init(void)
> > int i;
> > union hv_hypervisor_version_info version;
> >
> > - /* Get information about the Hyper-V host version */
> > + /* Get information about the Microsoft Hypervisor version */
> > if (!hv_get_hypervisor_version(&version))
> > - pr_info("Hyper-V: Host Build %d.%d.%d.%d-%d-%d\n",
> > + pr_info("Hyper-V: Hypervisor Build %d.%d.%d.%d-%d-%d\n",
> > version.major_version, version.minor_version,
> > version.build_number, version.service_number,
> > version.service_pack, version.service_branch);
> >
> >
>
> Looks like a good idea.
>
> Reviewed-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
Applied to hyperv-next.
^ permalink raw reply
* Re: [PATCH v2] mshv: Extend create partition ioctl to support cpu features
From: Easwar Hariharan @ 2025-10-31 18:37 UTC (permalink / raw)
To: Nuno Das Neves
Cc: linux-hyperv, linux-kernel, muislam, easwar.hariharan, kys,
haiyangz, wei.liu, decui, longli, mhklinux, skinsburskii, romank,
Jinank Jain
In-Reply-To: <1761860431-11208-1-git-send-email-nunodasneves@linux.microsoft.com>
On 10/30/2025 2:40 PM, Nuno Das Neves wrote:
> From: Muminul Islam <muislam@microsoft.com>
>
> The existing mshv create partition ioctl does not provide a way to
> specify which cpu features are enabled in the guest. This was done
> to reduce unnecessary complexity in the API.
>
> However, some new scenarios require fine-grained control over the
> cpu feature bits.
>
> Define a new mshv_create_partition_v2 structure which supports passing
> through the disabled cpu flags and xsave flags to the hypervisor
> directly.
>
> When these are not specified (pt_num_cpu_fbanks == 0) or the old
> structure is used, define a set of default flags which cover most
> cases.
>
> Retain backward compatibility with the old structure via a new flag
> MSHV_PT_BIT_CPU_AND_XSAVE_FEATURES which enables the new struct.
>
> Co-developed-by: Jinank Jain <jinankjain@microsoft.com>
> Signed-off-by: Jinank Jain <jinankjain@microsoft.com>
> Signed-off-by: Muminul Islam <muislam@microsoft.com>
> Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
> ---
> Changes in v2:
> - Fix compilation issues [kernel test robot]
>
> ---
> drivers/hv/mshv_root_main.c | 176 ++++++++++++++++++++++++++++++++----
> include/hyperv/hvhdk.h | 86 +++++++++++++++++-
> include/uapi/linux/mshv.h | 34 +++++++
> 3 files changed, 272 insertions(+), 24 deletions(-)
lkp also pointed out that we are leaking a kernel config to userspace:
https://lore.kernel.org/all/202510292330.LCHvPCLt-lkp@intel.com/
In the v3 that Wei requested, please address that as well.
Thanks,
Easwar (he/him)
<snip>
^ permalink raw reply
* Re: [PATCH v2] mshv: Extend create partition ioctl to support cpu features
From: Nuno Das Neves @ 2025-10-31 19:49 UTC (permalink / raw)
To: Easwar Hariharan
Cc: linux-hyperv, linux-kernel, muislam, kys, haiyangz, wei.liu,
decui, longli, mhklinux, skinsburskii, romank, Jinank Jain
In-Reply-To: <119f11e7-6074-4bd4-a72b-fc76370c284f@linux.microsoft.com>
On 10/31/2025 11:37 AM, Easwar Hariharan wrote:
> On 10/30/2025 2:40 PM, Nuno Das Neves wrote:
>> From: Muminul Islam <muislam@microsoft.com>
>>
>> The existing mshv create partition ioctl does not provide a way to
>> specify which cpu features are enabled in the guest. This was done
>> to reduce unnecessary complexity in the API.
>>
>> However, some new scenarios require fine-grained control over the
>> cpu feature bits.
>>
>> Define a new mshv_create_partition_v2 structure which supports passing
>> through the disabled cpu flags and xsave flags to the hypervisor
>> directly.
>>
>> When these are not specified (pt_num_cpu_fbanks == 0) or the old
>> structure is used, define a set of default flags which cover most
>> cases.
>>
>> Retain backward compatibility with the old structure via a new flag
>> MSHV_PT_BIT_CPU_AND_XSAVE_FEATURES which enables the new struct.
>>
>> Co-developed-by: Jinank Jain <jinankjain@microsoft.com>
>> Signed-off-by: Jinank Jain <jinankjain@microsoft.com>
>> Signed-off-by: Muminul Islam <muislam@microsoft.com>
>> Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
>> ---
>> Changes in v2:
>> - Fix compilation issues [kernel test robot]
>>
>> ---
>> drivers/hv/mshv_root_main.c | 176 ++++++++++++++++++++++++++++++++----
>> include/hyperv/hvhdk.h | 86 +++++++++++++++++-
>> include/uapi/linux/mshv.h | 34 +++++++
>> 3 files changed, 272 insertions(+), 24 deletions(-)
>
> lkp also pointed out that we are leaking a kernel config to userspace:
> https://lore.kernel.org/all/202510292330.LCHvPCLt-lkp@intel.com/
>
> In the v3 that Wei requested, please address that as well.
Thanks, I did fix this issue in v2 but I didn't mention it explicitly.
I'll update the changelog in v3 to call it out.
>
> Thanks,
> Easwar (he/him)
>
> <snip>
^ permalink raw reply
* Re: [PATCH v2] mshv: Extend create partition ioctl to support cpu features
From: Nuno Das Neves @ 2025-10-31 20:08 UTC (permalink / raw)
To: Wei Liu
Cc: linux-hyperv, linux-kernel, muislam, kys, haiyangz, decui, longli,
mhklinux, skinsburskii, romank, Jinank Jain
In-Reply-To: <20251031183109.GC2612078@liuwe-devbox-debian-v2.local>
On 10/31/2025 11:31 AM, Wei Liu wrote:
> On Thu, Oct 30, 2025 at 02:40:31PM -0700, Nuno Das Neves wrote:
>> From: Muminul Islam <muislam@microsoft.com>
>>
>> The existing mshv create partition ioctl does not provide a way to
>> specify which cpu features are enabled in the guest. This was done
>> to reduce unnecessary complexity in the API.
>>
>> However, some new scenarios require fine-grained control over the
>> cpu feature bits.
>>
>> Define a new mshv_create_partition_v2 structure which supports passing
>> through the disabled cpu flags and xsave flags to the hypervisor
>> directly.
>>
>> When these are not specified (pt_num_cpu_fbanks == 0) or the old
>> structure is used, define a set of default flags which cover most
>> cases.
>>
>> Retain backward compatibility with the old structure via a new flag
>> MSHV_PT_BIT_CPU_AND_XSAVE_FEATURES which enables the new struct.
>>
>> Co-developed-by: Jinank Jain <jinankjain@microsoft.com>
>> Signed-off-by: Jinank Jain <jinankjain@microsoft.com>
>> Signed-off-by: Muminul Islam <muislam@microsoft.com>
>> Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com>
>> ---
>> Changes in v2:
>> - Fix compilation issues [kernel test robot]
>>
>> ---
>> drivers/hv/mshv_root_main.c | 176 ++++++++++++++++++++++++++++++++----
>> include/hyperv/hvhdk.h | 86 +++++++++++++++++-
>
> There is no mention of updating hvhdk.h in the commit message.
>
Ah, that's true..
> Can you split out this part to a separate commit?
I put the header changes in this patch because a patch containing
those alone doesn't have much merit on its own.
I know we have split header changes into separate patches in the
past but I'm not sure it's always the right choice.
Thinking about this, I could also split it up another way: one
patch to introduce the new cpu features flags and use them in the
driver, and one patch to introduce mshv_create_partition_v2.
Nuno>
> Wei
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] net: mana: Refactor GF stats to use global mana_context
From: Jakub Kicinski @ 2025-10-31 23:06 UTC (permalink / raw)
To: Erni Sri Satya Vennela
Cc: kys, haiyangz, wei.liu, decui, andrew+netdev, davem, edumazet,
pabeni, longli, kotaranov, horms, shradhagupta, ssengar,
dipayanroy, shirazsaleem, rosenp, linux-hyperv, netdev,
linux-kernel, linux-rdma
In-Reply-To: <1761734272-32055-2-git-send-email-ernis@linux.microsoft.com>
On Wed, 29 Oct 2025 03:37:51 -0700 Erni Sri Satya Vennela wrote:
> Refactor mana_query_gf_stats() to use mana_context instead of per-port,
> enabling single query for all VFs.
What does "single query for all VFs" mean?
All types? All within the host?
Coincidentally I don't know what HC and GF stand for.
Please explain things in more detail, all atypical acronyms
(for *Linux* networking).
> Isolate hardware counter stats by introducing mana_ethtool_hc_stats
> in mana_context and update the code to ensure all stats are properly
> reported via ethtool -S <interface>, maintaining consistency with
> previous behavior.
> -void mana_query_gf_stats(struct mana_port_context *apc)
> +void mana_query_gf_stats(struct mana_context *ac)
> {
> struct mana_query_gf_stat_resp resp = {};
> struct mana_query_gf_stat_req req = {};
> - struct net_device *ndev = apc->ndev;
> + struct gdma_context *gc = ac->gdma_dev->gdma_context;
reverse xmas tree, please
> + struct device *dev = gc->dev;
> int err;
^ permalink raw reply
* Re: [PATCH net-next v2 2/2] net: mana: Add standard counter rx_missed_errors
From: Jakub Kicinski @ 2025-10-31 23:17 UTC (permalink / raw)
To: Erni Sri Satya Vennela
Cc: kys, haiyangz, wei.liu, decui, andrew+netdev, davem, edumazet,
pabeni, longli, kotaranov, horms, shradhagupta, ssengar,
dipayanroy, shirazsaleem, rosenp, linux-hyperv, netdev,
linux-kernel, linux-rdma
In-Reply-To: <1761734272-32055-3-git-send-email-ernis@linux.microsoft.com>
On Wed, 29 Oct 2025 03:37:52 -0700 Erni Sri Satya Vennela wrote:
> diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c b/drivers/net/ethernet/microsoft/mana/mana_en.c
> index 009e869ef296..48df44889f05 100644
> --- a/drivers/net/ethernet/microsoft/mana/mana_en.c
> +++ b/drivers/net/ethernet/microsoft/mana/mana_en.c
> @@ -494,6 +494,11 @@ static void mana_get_stats64(struct net_device *ndev,
>
> netdev_stats_to_stats64(st, &ndev->stats);
>
> + if (apc->ac->hwc_timeout_occurred)
> + netdev_warn_once(ndev, "HWC timeout occurred\n");
I don't think there's much value in this print.
> +#define MANA_GF_STATS_PERIOD (2 * HZ)
> +
> +static void mana_gf_stats_work_handler(struct work_struct *work)
> +{
> + struct mana_context *ac =
> + container_of(to_delayed_work(work), struct mana_context, gf_stats_work);
> + int err;
> +
> + err = mana_query_gf_stats(ac);
> + if (err == -ETIMEDOUT) {
> + /* HWC timeout detected - reset stats and stop rescheduling */
> + ac->hwc_timeout_occurred = true;
> + memset(&ac->hc_stats, 0, sizeof(ac->hc_stats));
Not sure I've seen another device using this approach but I can't
really tell what's the best strategy. The device is unusable if it
can't provide stats..
> + return;
> + }
> + queue_delayed_work(ac->gf_stats_wq, &ac->gf_stats_work, MANA_GF_STATS_PERIOD);
> +}
> +
> int mana_probe(struct gdma_dev *gd, bool resuming)
> {
> struct gdma_context *gc = gd->gdma_context;
> @@ -3478,6 +3503,15 @@ int mana_probe(struct gdma_dev *gd, bool resuming)
> }
>
> err = add_adev(gd, "eth");
> + ac->gf_stats_wq = create_singlethread_workqueue("mana_gf_stats");
Why are you creating a workqueue? You can use system queues.
> + queue_delayed_work(ac->gf_stats_wq, &ac->gf_stats_work, MANA_GF_STATS_PERIOD);
ls wrap long lines at 80 chars.
> diff --git a/drivers/net/ethernet/microsoft/mana/mana_ethtool.c b/drivers/net/ethernet/microsoft/mana/mana_ethtool.c
> index 3dfd96146424..99e811208683 100644
> --- a/drivers/net/ethernet/microsoft/mana/mana_ethtool.c
> +++ b/drivers/net/ethernet/microsoft/mana/mana_ethtool.c
> @@ -213,8 +213,6 @@ static void mana_get_ethtool_stats(struct net_device *ndev,
>
> if (!apc->port_is_up)
> return;
> - /* we call mana function to update stats from GDMA */
> - mana_query_gf_stats(apc->ac);
Why delete this? We can get fresh stats for the user in this context.
^ permalink raw reply
* Re: [PATCH net-next v2] net: mana: Handle SKB if TX SGEs exceed hardware limit
From: Jakub Kicinski @ 2025-10-31 23:26 UTC (permalink / raw)
To: Aditya Garg
Cc: kys, haiyangz, wei.liu, decui, andrew+netdev, davem, edumazet,
pabeni, longli, kotaranov, horms, shradhagupta, ssengar, ernis,
dipayanroy, shirazsaleem, linux-hyperv, netdev, linux-kernel,
linux-rdma, gargaditya
In-Reply-To: <20251029131235.GA3903@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
On Wed, 29 Oct 2025 06:12:35 -0700 Aditya Garg wrote:
> @@ -289,6 +290,21 @@ netdev_tx_t mana_start_xmit(struct sk_buff *skb, struct net_device *ndev)
> cq = &apc->tx_qp[txq_idx].tx_cq;
> tx_stats = &txq->stats;
>
> + if (MAX_SKB_FRAGS + 2 > MAX_TX_WQE_SGL_ENTRIES &&
> + skb_shinfo(skb)->nr_frags + 2 > MAX_TX_WQE_SGL_ENTRIES) {
> + /* GSO skb with Hardware SGE limit exceeded is not expected here
> + * as they are handled in mana_features_check() callback
> + */
> + if (skb_is_gso(skb))
> + netdev_warn_once(ndev, "GSO enabled skb exceeds max SGE limit\n");
This could be the same question Simon asked but why do you think you
need this line? Sure you need to linearize non-GSO but why do you care
to warn specifically about GSO?! Looks like defensive programming or
testing leftover..
> + if (skb_linearize(skb)) {
> + netdev_warn_once(ndev, "Failed to linearize skb with nr_frags=%d and is_gso=%d\n",
> + skb_shinfo(skb)->nr_frags,
> + skb_is_gso(skb));
.. in practice including is_gso() here as you do is probably enough for
debug
> + goto tx_drop_count;
> + }
> + }
> +
> pkg.tx_oob.s_oob.vcq_num = cq->gdma_id;
> pkg.tx_oob.s_oob.vsq_frame = txq->vsq_frame;
>
> @@ -402,8 +418,6 @@ netdev_tx_t mana_start_xmit(struct sk_buff *skb, struct net_device *ndev)
> }
> }
>
> - WARN_ON_ONCE(pkg.wqe_req.num_sge > MAX_TX_WQE_SGL_ENTRIES);
> -
> if (pkg.wqe_req.num_sge <= ARRAY_SIZE(pkg.sgl_array)) {
> pkg.wqe_req.sgl = pkg.sgl_array;
> } else {
> @@ -438,9 +452,13 @@ netdev_tx_t mana_start_xmit(struct sk_buff *skb, struct net_device *ndev)
>
> if (err) {
> (void)skb_dequeue_tail(&txq->pending_skbs);
> + mana_unmap_skb(skb, apc);
> netdev_warn(ndev, "Failed to post TX OOB: %d\n", err);
You have a print right here and in the callee. This condition must
(almost) never happen in practice. It's likely fine to just drop
the packet.
Either way -- this should be a separate patch.
> - err = NETDEV_TX_BUSY;
> - goto tx_busy;
> + if (err == -ENOSPC) {
> + err = NETDEV_TX_BUSY;
> + goto tx_busy;
> + }
> + goto free_sgl_ptr;
> }
>
> err = NETDEV_TX_OK;
> @@ -478,6 +496,25 @@ netdev_tx_t mana_start_xmit(struct sk_buff *skb, struct net_device *ndev)
> return NETDEV_TX_OK;
> }
--
pw-bot: cr
^ permalink raw reply
* Re: [net-next,v4] net: mana: Support HW link state events
From: patchwork-bot+netdevbpf @ 2025-10-31 23:30 UTC (permalink / raw)
To: Haiyang Zhang
Cc: linux-hyperv, netdev, kys, haiyangz, wei.liu, decui,
andrew+netdev, davem, edumazet, kuba, pabeni, longli, kotaranov,
horms, leon, shradhagupta, mlevitsk, ernis, yury.norov,
dipayanroy, shirazsaleem, ssengar, linux-kernel, linux-rdma,
paulros
In-Reply-To: <1761770601-16920-1-git-send-email-haiyangz@linux.microsoft.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 29 Oct 2025 13:43:10 -0700 you wrote:
> From: Haiyang Zhang <haiyangz@microsoft.com>
>
> Handle the NIC hardware link state events received from the HW
> channel, then set the proper link state accordingly.
>
> And, add a feature bit, GDMA_DRV_CAP_FLAG_1_HW_VPORT_LINK_AWARE,
> to inform the NIC hardware this handler exists.
>
> [...]
Here is the summary with links:
- [net-next,v4] net: mana: Support HW link state events
https://git.kernel.org/netdev/net-next/c/54133f9b4b53
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ 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