* [RFC v1 2/5] iommu: Move Hyper-V IOMMU driver to its own subdirectory
From: Yu Zhang @ 2025-12-09 5:11 UTC (permalink / raw)
To: linux-kernel, linux-hyperv, iommu, linux-pci
Cc: kys, haiyangz, wei.liu, decui, lpieralisi, kwilczynski, mani,
robh, bhelgaas, arnd, joro, will, robin.murphy, easwar.hariharan,
jacob.pan, nunodasneves, mrathor, mhklinux, peterz, linux-arch
In-Reply-To: <20251209051128.76913-1-zhangyu1@linux.microsoft.com>
From: Easwar Hariharan <eahariha@linux.microsoft.com>
The Hyper-V IOMMU driver currently only supports IRQ remapping.
As it will be adding DMA remapping support, prepare a directory
to contain all the different feature files.
This is a simple rename commit and has no functional changes.
Signed-off-by: Easwar Hariharan <eahariha@linux.microsoft.com>
Signed-off-by: Yu Zhang <zhangyu1@linux.microsoft.com>
---
drivers/iommu/Kconfig | 10 +---------
drivers/iommu/Makefile | 2 +-
drivers/iommu/hyperv/Kconfig | 10 ++++++++++
drivers/iommu/hyperv/Makefile | 2 ++
.../iommu/{hyperv-iommu.c => hyperv/irq_remapping.c} | 2 +-
5 files changed, 15 insertions(+), 11 deletions(-)
create mode 100644 drivers/iommu/hyperv/Kconfig
create mode 100644 drivers/iommu/hyperv/Makefile
rename drivers/iommu/{hyperv-iommu.c => hyperv/irq_remapping.c} (99%)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index c9ae3221cd6f..661ff4e764cc 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -194,6 +194,7 @@ config MSM_IOMMU
source "drivers/iommu/amd/Kconfig"
source "drivers/iommu/arm/Kconfig"
source "drivers/iommu/intel/Kconfig"
+source "drivers/iommu/hyperv/Kconfig"
source "drivers/iommu/iommufd/Kconfig"
source "drivers/iommu/riscv/Kconfig"
@@ -350,15 +351,6 @@ config MTK_IOMMU_V1
if unsure, say N here.
-config HYPERV_IOMMU
- bool "Hyper-V IRQ Handling"
- depends on HYPERV && X86
- select IOMMU_API
- default HYPERV
- help
- Stub IOMMU driver to handle IRQs to support Hyper-V Linux
- guest and root partitions.
-
config VIRTIO_IOMMU
tristate "Virtio IOMMU driver"
depends on VIRTIO
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index b17ef9818759..757dc377cb66 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_AMD_IOMMU) += amd/
obj-$(CONFIG_INTEL_IOMMU) += intel/
obj-$(CONFIG_RISCV_IOMMU) += riscv/
obj-$(CONFIG_GENERIC_PT) += generic_pt/fmt/
+obj-$(CONFIG_HYPERV_IOMMU) += hyperv/
obj-$(CONFIG_IOMMU_API) += iommu.o
obj-$(CONFIG_IOMMU_SUPPORT) += iommu-pages.o
obj-$(CONFIG_IOMMU_API) += iommu-traces.o
@@ -29,7 +30,6 @@ obj-$(CONFIG_TEGRA_IOMMU_SMMU) += tegra-smmu.o
obj-$(CONFIG_EXYNOS_IOMMU) += exynos-iommu.o
obj-$(CONFIG_FSL_PAMU) += fsl_pamu.o fsl_pamu_domain.o
obj-$(CONFIG_S390_IOMMU) += s390-iommu.o
-obj-$(CONFIG_HYPERV_IOMMU) += hyperv-iommu.o
obj-$(CONFIG_VIRTIO_IOMMU) += virtio-iommu.o
obj-$(CONFIG_IOMMU_SVA) += iommu-sva.o
obj-$(CONFIG_IOMMU_IOPF) += io-pgfault.o
diff --git a/drivers/iommu/hyperv/Kconfig b/drivers/iommu/hyperv/Kconfig
new file mode 100644
index 000000000000..30f40d867036
--- /dev/null
+++ b/drivers/iommu/hyperv/Kconfig
@@ -0,0 +1,10 @@
+# SPDX-License-Identifier: GPL-2.0-only
+# HyperV paravirtualized IOMMU support
+config HYPERV_IOMMU
+ bool "Hyper-V IRQ Handling"
+ depends on HYPERV && X86
+ select IOMMU_API
+ default HYPERV
+ help
+ Stub IOMMU driver to handle IRQs to support Hyper-V Linux
+ guest and root partitions.
diff --git a/drivers/iommu/hyperv/Makefile b/drivers/iommu/hyperv/Makefile
new file mode 100644
index 000000000000..9f557bad94ff
--- /dev/null
+++ b/drivers/iommu/hyperv/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_HYPERV_IOMMU) += irq_remapping.o
diff --git a/drivers/iommu/hyperv-iommu.c b/drivers/iommu/hyperv/irq_remapping.c
similarity index 99%
rename from drivers/iommu/hyperv-iommu.c
rename to drivers/iommu/hyperv/irq_remapping.c
index 0961ac805944..f2c4c7d67302 100644
--- a/drivers/iommu/hyperv-iommu.c
+++ b/drivers/iommu/hyperv/irq_remapping.c
@@ -22,7 +22,7 @@
#include <asm/hypervisor.h>
#include <asm/mshyperv.h>
-#include "irq_remapping.h"
+#include "../irq_remapping.h"
#ifdef CONFIG_IRQ_REMAP
--
2.49.0
^ permalink raw reply related
* [RFC v1 3/5] hyperv: Introduce new hypercall interfaces used by Hyper-V guest IOMMU
From: Yu Zhang @ 2025-12-09 5:11 UTC (permalink / raw)
To: linux-kernel, linux-hyperv, iommu, linux-pci
Cc: kys, haiyangz, wei.liu, decui, lpieralisi, kwilczynski, mani,
robh, bhelgaas, arnd, joro, will, robin.murphy, easwar.hariharan,
jacob.pan, nunodasneves, mrathor, mhklinux, peterz, linux-arch
In-Reply-To: <20251209051128.76913-1-zhangyu1@linux.microsoft.com>
From: Wei Liu <wei.liu@kernel.org>
Hyper-V guest IOMMU is a para-virtualized IOMMU based on hypercalls.
Introduce the hypercalls used by the child partition to interact with
this facility.
These hypercalls fall into below categories:
- Detection and capability: HVCALL_GET_IOMMU_CAPABILITIES is used to
detect the existence and capabilities of the guest IOMMU.
- Device management: HVCALL_GET_LOGICAL_DEVICE_PROPERTY is used to
check whether an endpoint device is managed by the guest IOMMU.
- Domain management: A set of hypercalls is provided to handle the
creation, configuration, and deletion of guest domains, as well as
the attachment/detachment of endpoint devices to/from those domains.
- IOTLB flushing: HVCALL_FLUSH_DEVICE_DOMAIN is used to ask Hyper-V
for a domain-selective IOTLB flush(which in its handler may flush
the device TLB as well). Page-selective IOTLB flushes will be offered
by new hypercalls in future patches.
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Co-developed-by: Jacob Pan <jacob.pan@linux.microsoft.com>
Signed-off-by: Jacob Pan <jacob.pan@linux.microsoft.com>
Co-developed-by: Easwar Hariharan <easwar.hariharan@linux.microsoft.com>
Signed-off-by: Easwar Hariharan <easwar.hariharan@linux.microsoft.com>
Co-developed-by: Yu Zhang <zhangyu1@linux.microsoft.com>
Signed-off-by: Yu Zhang <zhangyu1@linux.microsoft.com>
---
include/hyperv/hvgdk_mini.h | 8 +++
include/hyperv/hvhdk_mini.h | 123 ++++++++++++++++++++++++++++++++++++
2 files changed, 131 insertions(+)
diff --git a/include/hyperv/hvgdk_mini.h b/include/hyperv/hvgdk_mini.h
index 77abddfc750e..e5b302bbfe14 100644
--- a/include/hyperv/hvgdk_mini.h
+++ b/include/hyperv/hvgdk_mini.h
@@ -478,10 +478,16 @@ union hv_vp_assist_msr_contents { /* HV_REGISTER_VP_ASSIST_PAGE */
#define HVCALL_GET_VP_INDEX_FROM_APIC_ID 0x009a
#define HVCALL_FLUSH_GUEST_PHYSICAL_ADDRESS_SPACE 0x00af
#define HVCALL_FLUSH_GUEST_PHYSICAL_ADDRESS_LIST 0x00b0
+#define HVCALL_CREATE_DEVICE_DOMAIN 0x00b1
+#define HVCALL_ATTACH_DEVICE_DOMAIN 0x00b2
#define HVCALL_SIGNAL_EVENT_DIRECT 0x00c0
#define HVCALL_POST_MESSAGE_DIRECT 0x00c1
#define HVCALL_DISPATCH_VP 0x00c2
+#define HVCALL_DETACH_DEVICE_DOMAIN 0x00c4
+#define HVCALL_DELETE_DEVICE_DOMAIN 0x00c5
#define HVCALL_GET_GPA_PAGES_ACCESS_STATES 0x00c9
+#define HVCALL_CONFIGURE_DEVICE_DOMAIN 0x00ce
+#define HVCALL_FLUSH_DEVICE_DOMAIN 0x00d0
#define HVCALL_ACQUIRE_SPARSE_SPA_PAGE_HOST_ACCESS 0x00d7
#define HVCALL_RELEASE_SPARSE_SPA_PAGE_HOST_ACCESS 0x00d8
#define HVCALL_MODIFY_SPARSE_GPA_PAGE_HOST_VISIBILITY 0x00db
@@ -492,6 +498,8 @@ union hv_vp_assist_msr_contents { /* HV_REGISTER_VP_ASSIST_PAGE */
#define HVCALL_GET_VP_CPUID_VALUES 0x00f4
#define HVCALL_MMIO_READ 0x0106
#define HVCALL_MMIO_WRITE 0x0107
+#define HVCALL_GET_IOMMU_CAPABILITIES 0x0125
+#define HVCALL_GET_LOGICAL_DEVICE_PROPERTY 0x0127
/* HV_HYPERCALL_INPUT */
#define HV_HYPERCALL_RESULT_MASK GENMASK_ULL(15, 0)
diff --git a/include/hyperv/hvhdk_mini.h b/include/hyperv/hvhdk_mini.h
index 858f6a3925b3..ba6b91746b13 100644
--- a/include/hyperv/hvhdk_mini.h
+++ b/include/hyperv/hvhdk_mini.h
@@ -400,4 +400,127 @@ union hv_device_id { /* HV_DEVICE_ID */
} acpi;
} __packed;
+/* Device domain types */
+#define HV_DEVICE_DOMAIN_TYPE_S1 1 /* Stage 1 domain */
+
+/* ID for default domain and NULL domain */
+#define HV_DEVICE_DOMAIN_ID_DEFAULT 0
+#define HV_DEVICE_DOMAIN_ID_NULL 0xFFFFFFFFULL
+
+union hv_device_domain_id {
+ u64 as_uint64;
+ struct {
+ u32 type: 4;
+ u32 reserved: 28;
+ u32 id;
+ } __packed;
+};
+
+struct hv_input_device_domain {
+ u64 partition_id;
+ union hv_input_vtl owner_vtl;
+ u8 padding[7];
+ union hv_device_domain_id domain_id;
+} __packed;
+
+union hv_create_device_domain_flags {
+ u32 as_uint32;
+ struct {
+ u32 forward_progress_required: 1;
+ u32 inherit_owning_vtl: 1;
+ u32 reserved: 30;
+ } __packed;
+};
+
+struct hv_input_create_device_domain {
+ struct hv_input_device_domain device_domain;
+ union hv_create_device_domain_flags create_device_domain_flags;
+} __packed;
+
+struct hv_input_delete_device_domain {
+ struct hv_input_device_domain device_domain;
+} __packed;
+
+struct hv_input_attach_device_domain {
+ struct hv_input_device_domain device_domain;
+ union hv_device_id device_id;
+} __packed;
+
+struct hv_input_detach_device_domain {
+ u64 partition_id;
+ union hv_device_id device_id;
+} __packed;
+
+struct hv_device_domain_settings {
+ struct {
+ /*
+ * Enable translations. If not enabled, all transaction bypass
+ * S1 translations.
+ */
+ u64 translation_enabled: 1;
+ u64 blocked: 1;
+ /*
+ * First stage address translation paging mode:
+ * 0: 4-level paging (default)
+ * 1: 5-level paging
+ */
+ u64 first_stage_paging_mode: 1;
+ u64 reserved: 61;
+ } flags;
+
+ /* Address of translation table */
+ u64 page_table_root;
+} __packed;
+
+struct hv_input_configure_device_domain {
+ struct hv_input_device_domain device_domain;
+ struct hv_device_domain_settings settings;
+} __packed;
+
+struct hv_input_get_iommu_capabilities {
+ u64 partition_id;
+ u64 reserved;
+} __packed;
+
+struct hv_output_get_iommu_capabilities {
+ u32 size;
+ u16 reserved;
+ u8 max_iova_width;
+ u8 max_pasid_width;
+
+#define HV_IOMMU_CAP_PRESENT (1ULL << 0)
+#define HV_IOMMU_CAP_S2 (1ULL << 1)
+#define HV_IOMMU_CAP_S1 (1ULL << 2)
+#define HV_IOMMU_CAP_S1_5LVL (1ULL << 3)
+#define HV_IOMMU_CAP_PASID (1ULL << 4)
+#define HV_IOMMU_CAP_ATS (1ULL << 5)
+#define HV_IOMMU_CAP_PRI (1ULL << 6)
+
+ u64 iommu_cap;
+ u64 pgsize_bitmap;
+} __packed;
+
+enum hv_logical_device_property_code {
+ HV_LOGICAL_DEVICE_PROPERTY_PVIOMMU = 10,
+};
+
+struct hv_input_get_logical_device_property {
+ u64 partition_id;
+ u64 logical_device_id;
+ enum hv_logical_device_property_code code;
+ u32 reserved;
+} __packed;
+
+struct hv_output_get_logical_device_property {
+#define HV_DEVICE_IOMMU_ENABLED (1ULL << 0)
+ u64 device_iommu;
+ u64 reserved;
+} __packed;
+
+struct hv_input_flush_device_domain {
+ struct hv_input_device_domain device_domain;
+ u32 flags;
+ u32 reserved;
+} __packed;
+
#endif /* _HV_HVHDK_MINI_H */
--
2.49.0
^ permalink raw reply related
* [RFC v1 4/5] hyperv: allow hypercall output pages to be allocated for child partitions
From: Yu Zhang @ 2025-12-09 5:11 UTC (permalink / raw)
To: linux-kernel, linux-hyperv, iommu, linux-pci
Cc: kys, haiyangz, wei.liu, decui, lpieralisi, kwilczynski, mani,
robh, bhelgaas, arnd, joro, will, robin.murphy, easwar.hariharan,
jacob.pan, nunodasneves, mrathor, mhklinux, peterz, linux-arch
In-Reply-To: <20251209051128.76913-1-zhangyu1@linux.microsoft.com>
Previously, the allocation of per-CPU output argument pages was restricted
to root partitions or those operating in VTL mode.
Remove this restriction to support guest IOMMU related hypercalls, which
require valid output pages to function correctly.
While unconditionally allocating per-CPU output pages scales with the number
of vCPUs, and potentially adding overhead for guests that may not utilize the
IOMMU, this change anticipates that future hypercalls from child partitions
may also require these output pages.
Signed-off-by: Yu Zhang <zhangyu1@linux.microsoft.com>
---
drivers/hv/hv_common.c | 21 ++++++---------------
1 file changed, 6 insertions(+), 15 deletions(-)
diff --git a/drivers/hv/hv_common.c b/drivers/hv/hv_common.c
index e109a620c83f..034fb2592884 100644
--- a/drivers/hv/hv_common.c
+++ b/drivers/hv/hv_common.c
@@ -255,11 +255,6 @@ static void hv_kmsg_dump_register(void)
}
}
-static inline bool hv_output_page_exists(void)
-{
- return hv_parent_partition() || IS_ENABLED(CONFIG_HYPERV_VTL_MODE);
-}
-
void __init hv_get_partition_id(void)
{
struct hv_output_get_partition_id *output;
@@ -371,11 +366,9 @@ int __init hv_common_init(void)
hyperv_pcpu_input_arg = alloc_percpu(void *);
BUG_ON(!hyperv_pcpu_input_arg);
- /* Allocate the per-CPU state for output arg for root */
- if (hv_output_page_exists()) {
- hyperv_pcpu_output_arg = alloc_percpu(void *);
- BUG_ON(!hyperv_pcpu_output_arg);
- }
+ /* Allocate the per-CPU state for output arg*/
+ hyperv_pcpu_output_arg = alloc_percpu(void *);
+ BUG_ON(!hyperv_pcpu_output_arg);
if (hv_parent_partition()) {
hv_synic_eventring_tail = alloc_percpu(u8 *);
@@ -473,7 +466,7 @@ int hv_common_cpu_init(unsigned int cpu)
u8 **synic_eventring_tail;
u64 msr_vp_index;
gfp_t flags;
- const int pgcount = hv_output_page_exists() ? 2 : 1;
+ const int pgcount = 2;
void *mem;
int ret = 0;
@@ -491,10 +484,8 @@ int hv_common_cpu_init(unsigned int cpu)
if (!mem)
return -ENOMEM;
- if (hv_output_page_exists()) {
- outputarg = (void **)this_cpu_ptr(hyperv_pcpu_output_arg);
- *outputarg = (char *)mem + HV_HYP_PAGE_SIZE;
- }
+ outputarg = (void **)this_cpu_ptr(hyperv_pcpu_output_arg);
+ *outputarg = (char *)mem + HV_HYP_PAGE_SIZE;
if (!ms_hyperv.paravisor_present &&
(hv_isolation_type_snp() || hv_isolation_type_tdx())) {
--
2.49.0
^ permalink raw reply related
* [RFC v1 5/5] iommu/hyperv: Add para-virtualized IOMMU support for Hyper-V guest
From: Yu Zhang @ 2025-12-09 5:11 UTC (permalink / raw)
To: linux-kernel, linux-hyperv, iommu, linux-pci
Cc: kys, haiyangz, wei.liu, decui, lpieralisi, kwilczynski, mani,
robh, bhelgaas, arnd, joro, will, robin.murphy, easwar.hariharan,
jacob.pan, nunodasneves, mrathor, mhklinux, peterz, linux-arch
In-Reply-To: <20251209051128.76913-1-zhangyu1@linux.microsoft.com>
Add a para-virtualized IOMMU driver for Linux guests running on Hyper-V.
This driver implements stage-1 IO translation within the guest OS.
It integrates with the Linux IOMMU core, utilizing Hyper-V hypercalls
for:
- Capability discovery
- Domain allocation, configuration, and deallocation
- Device attachment and detachment
- IOTLB invalidation
The driver constructs x86-compatible stage-1 IO page tables in the
guest memory using consolidated IO page table helpers. This allows
the guest to manage stage-1 translations independently of vendor-
specific drivers (like Intel VT-d or AMD IOMMU).
Hyper-v consumes this stage-1 IO page table, when a device domain is
created and configured, and nests it with the host's stage-2 IO page
tables, therefore elemenating the VM exits for guest IOMMU mapping
operations.
For guest IOMMU unmapping operations, VM exits to perform the IOTLB
flush(and possibly the device TLB flush) is still unavoidable. For
now, HVCALL_FLUSH_DEVICE_DOMAIN is used to implement a domain-selective
IOTLB flush. New hypercalls for finer-grained hypercall will be provided
in future patches.
Co-developed-by: Wei Liu <wei.liu@kernel.org>
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Co-developed-by: Jacob Pan <jacob.pan@linux.microsoft.com>
Signed-off-by: Jacob Pan <jacob.pan@linux.microsoft.com>
Co-developed-by: Easwar Hariharan <easwar.hariharan@linux.microsoft.com>
Signed-off-by: Easwar Hariharan <easwar.hariharan@linux.microsoft.com>
Signed-off-by: Yu Zhang <zhangyu1@linux.microsoft.com>
---
drivers/iommu/hyperv/Kconfig | 14 +
drivers/iommu/hyperv/Makefile | 1 +
drivers/iommu/hyperv/iommu.c | 608 ++++++++++++++++++++++++++++++++++
drivers/iommu/hyperv/iommu.h | 53 +++
4 files changed, 676 insertions(+)
create mode 100644 drivers/iommu/hyperv/iommu.c
create mode 100644 drivers/iommu/hyperv/iommu.h
diff --git a/drivers/iommu/hyperv/Kconfig b/drivers/iommu/hyperv/Kconfig
index 30f40d867036..fa3c77752d7b 100644
--- a/drivers/iommu/hyperv/Kconfig
+++ b/drivers/iommu/hyperv/Kconfig
@@ -8,3 +8,17 @@ config HYPERV_IOMMU
help
Stub IOMMU driver to handle IRQs to support Hyper-V Linux
guest and root partitions.
+
+if HYPERV_IOMMU
+config HYPERV_PVIOMMU
+ bool "Microsoft Hypervisor para-virtualized IOMMU support"
+ depends on X86 && HYPERV && PCI_HYPERV
+ depends on IOMMU_PT
+ select IOMMU_API
+ select IOMMU_DMA
+ select DMA_OPS
+ select IOMMU_IOVA
+ default HYPERV
+ help
+ A para-virtualized IOMMU for Microsoft Hypervisor guest.
+endif
diff --git a/drivers/iommu/hyperv/Makefile b/drivers/iommu/hyperv/Makefile
index 9f557bad94ff..8669741c0a51 100644
--- a/drivers/iommu/hyperv/Makefile
+++ b/drivers/iommu/hyperv/Makefile
@@ -1,2 +1,3 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_HYPERV_IOMMU) += irq_remapping.o
+obj-$(CONFIG_HYPERV_PVIOMMU) += iommu.o
diff --git a/drivers/iommu/hyperv/iommu.c b/drivers/iommu/hyperv/iommu.c
new file mode 100644
index 000000000000..3d0aff868e16
--- /dev/null
+++ b/drivers/iommu/hyperv/iommu.c
@@ -0,0 +1,608 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/*
+ * Hyper-V IOMMU driver.
+ *
+ * Copyright (C) 2019, 2024-2025 Microsoft, Inc.
+ */
+
+#include <linux/iommu.h>
+#include <linux/pci.h>
+#include <linux/dma-map-ops.h>
+#include <linux/generic_pt/iommu.h>
+#include <linux/syscore_ops.h>
+#include <linux/pci-ats.h>
+
+#include <asm/iommu.h>
+#include <asm/hypervisor.h>
+#include <asm/mshyperv.h>
+
+#include "iommu.h"
+#include "../dma-iommu.h"
+#include "../iommu-pages.h"
+
+static void hv_iommu_detach_dev(struct iommu_domain *domain, struct device *dev);
+static void hv_flush_device_domain(struct hv_iommu_domain *hv_domain);
+struct hv_iommu_dev *hv_iommu_device;
+static struct hv_iommu_domain hv_identity_domain;
+static struct hv_iommu_domain hv_blocking_domain;
+static const struct iommu_domain_ops hv_iommu_identity_domain_ops;
+static const struct iommu_domain_ops hv_iommu_blocking_domain_ops;
+static struct iommu_ops hv_iommu_ops;
+
+#define hv_iommu_present(iommu_cap) (iommu_cap & HV_IOMMU_CAP_PRESENT)
+#define hv_iommu_s1_domain_supported(iommu_cap) (iommu_cap & HV_IOMMU_CAP_S1)
+#define hv_iommu_5lvl_supported(iommu_cap) (iommu_cap & HV_IOMMU_CAP_S1_5LVL)
+#define hv_iommu_ats_supported(iommu_cap) (iommu_cap & HV_IOMMU_CAP_ATS)
+
+static int hv_create_device_domain(struct hv_iommu_domain *hv_domain, u32 domain_stage)
+{
+ int ret;
+ u64 status;
+ unsigned long flags;
+ struct hv_input_create_device_domain *input;
+
+ ret = ida_alloc_range(&hv_iommu_device->domain_ids,
+ hv_iommu_device->first_domain, hv_iommu_device->last_domain,
+ GFP_KERNEL);
+ if (ret < 0)
+ return ret;
+
+ hv_domain->device_domain.partition_id = HV_PARTITION_ID_SELF;
+ hv_domain->device_domain.domain_id.type = domain_stage;
+ hv_domain->device_domain.domain_id.id = ret;
+ hv_domain->hv_iommu = hv_iommu_device;
+
+ local_irq_save(flags);
+
+ input = *this_cpu_ptr(hyperv_pcpu_input_arg);
+ memset(input, 0, sizeof(*input));
+ input->device_domain = hv_domain->device_domain;
+ input->create_device_domain_flags.forward_progress_required = 1;
+ input->create_device_domain_flags.inherit_owning_vtl = 0;
+ status = hv_do_hypercall(HVCALL_CREATE_DEVICE_DOMAIN, input, NULL);
+
+ local_irq_restore(flags);
+
+ if (!hv_result_success(status)) {
+ pr_err("%s: hypercall failed, status %lld\n", __func__, status);
+ ida_free(&hv_iommu_device->domain_ids, hv_domain->device_domain.domain_id.id);
+ }
+
+ return hv_result_to_errno(status);
+}
+
+static void hv_delete_device_domain(struct hv_iommu_domain *hv_domain)
+{
+ u64 status;
+ unsigned long flags;
+ struct hv_input_delete_device_domain *input;
+
+ local_irq_save(flags);
+
+ input = *this_cpu_ptr(hyperv_pcpu_input_arg);
+ memset(input, 0, sizeof(*input));
+ input->device_domain = hv_domain->device_domain;
+ status = hv_do_hypercall(HVCALL_DELETE_DEVICE_DOMAIN, input, NULL);
+
+ local_irq_restore(flags);
+
+ if (!hv_result_success(status))
+ pr_err("%s: hypercall failed, status %lld\n", __func__, status);
+
+ ida_free(&hv_domain->hv_iommu->domain_ids, hv_domain->device_domain.domain_id.id);
+}
+
+static bool hv_iommu_capable(struct device *dev, enum iommu_cap cap)
+{
+ switch (cap) {
+ case IOMMU_CAP_CACHE_COHERENCY:
+ return true;
+ case IOMMU_CAP_DEFERRED_FLUSH:
+ return true;
+ default:
+ return false;
+ }
+}
+
+static int hv_iommu_attach_dev(struct iommu_domain *domain, struct device *dev)
+{
+ u64 status;
+ unsigned long flags;
+ struct pci_dev *pdev;
+ struct hv_input_attach_device_domain *input;
+ struct hv_iommu_endpoint *vdev = dev_iommu_priv_get(dev);
+ struct hv_iommu_domain *hv_domain = to_hv_iommu_domain(domain);
+
+ /* Only allow PCI devices for now */
+ if (!dev_is_pci(dev))
+ return -EINVAL;
+
+ if (vdev->hv_domain == hv_domain)
+ return 0;
+
+ if (vdev->hv_domain)
+ hv_iommu_detach_dev(&vdev->hv_domain->domain, dev);
+
+ pdev = to_pci_dev(dev);
+ dev_dbg(dev, "Attaching (%strusted) to %d\n", pdev->untrusted ? "un" : "",
+ hv_domain->device_domain.domain_id.id);
+
+ local_irq_save(flags);
+
+ input = *this_cpu_ptr(hyperv_pcpu_input_arg);
+ memset(input, 0, sizeof(*input));
+ input->device_domain = hv_domain->device_domain;
+ input->device_id.as_uint64 = hv_build_logical_dev_id(pdev);
+ status = hv_do_hypercall(HVCALL_ATTACH_DEVICE_DOMAIN, input, NULL);
+
+ local_irq_restore(flags);
+
+ if (!hv_result_success(status)) {
+ pr_err("%s: hypercall failed, status %lld\n", __func__, status);
+ } else {
+ vdev->hv_domain = hv_domain;
+ spin_lock_irqsave(&hv_domain->lock, flags);
+ list_add(&vdev->list, &hv_domain->dev_list);
+ spin_unlock_irqrestore(&hv_domain->lock, flags);
+ }
+
+ return hv_result_to_errno(status);
+}
+
+static void hv_iommu_detach_dev(struct iommu_domain *domain, struct device *dev)
+{
+ u64 status;
+ unsigned long flags;
+ struct hv_input_detach_device_domain *input;
+ struct pci_dev *pdev;
+ struct hv_iommu_domain *hv_domain = to_hv_iommu_domain(domain);
+ struct hv_iommu_endpoint *vdev = dev_iommu_priv_get(dev);
+
+ /* See the attach function, only PCI devices for now */
+ if (!dev_is_pci(dev) || vdev->hv_domain != hv_domain)
+ return;
+
+ pdev = to_pci_dev(dev);
+
+ dev_dbg(dev, "Detaching from %d\n", hv_domain->device_domain.domain_id.id);
+
+ local_irq_save(flags);
+
+ input = *this_cpu_ptr(hyperv_pcpu_input_arg);
+ memset(input, 0, sizeof(*input));
+ input->partition_id = HV_PARTITION_ID_SELF;
+ input->device_id.as_uint64 = hv_build_logical_dev_id(pdev);
+ status = hv_do_hypercall(HVCALL_DETACH_DEVICE_DOMAIN, input, NULL);
+
+ local_irq_restore(flags);
+
+ if (!hv_result_success(status))
+ pr_err("%s: hypercall failed, status %lld\n", __func__, status);
+
+ spin_lock_irqsave(&hv_domain->lock, flags);
+ hv_flush_device_domain(hv_domain);
+ list_del(&vdev->list);
+ spin_unlock_irqrestore(&hv_domain->lock, flags);
+
+ vdev->hv_domain = NULL;
+}
+
+static int hv_iommu_get_logical_device_property(struct device *dev,
+ enum hv_logical_device_property_code code,
+ struct hv_output_get_logical_device_property *property)
+{
+ u64 status;
+ unsigned long flags;
+ struct hv_input_get_logical_device_property *input;
+ struct hv_output_get_logical_device_property *output;
+
+ local_irq_save(flags);
+
+ input = *this_cpu_ptr(hyperv_pcpu_input_arg);
+ output = *this_cpu_ptr(hyperv_pcpu_output_arg);
+ memset(input, 0, sizeof(*input));
+ memset(output, 0, sizeof(*output));
+ input->partition_id = HV_PARTITION_ID_SELF;
+ input->logical_device_id = hv_build_logical_dev_id(to_pci_dev(dev));
+ input->code = code;
+ status = hv_do_hypercall(HVCALL_GET_LOGICAL_DEVICE_PROPERTY, input, output);
+ *property = *output;
+
+ local_irq_restore(flags);
+
+ if (!hv_result_success(status))
+ pr_err("%s: hypercall failed, status %lld\n", __func__, status);
+
+ return hv_result_to_errno(status);
+}
+
+static struct iommu_device *hv_iommu_probe_device(struct device *dev)
+{
+ struct pci_dev *pdev;
+ struct hv_iommu_endpoint *vdev;
+ struct hv_output_get_logical_device_property device_iommu_property = {0};
+
+ if (!dev_is_pci(dev))
+ return ERR_PTR(-ENODEV);
+
+ if (hv_iommu_get_logical_device_property(dev,
+ HV_LOGICAL_DEVICE_PROPERTY_PVIOMMU,
+ &device_iommu_property) ||
+ !(device_iommu_property.device_iommu & HV_DEVICE_IOMMU_ENABLED))
+ return ERR_PTR(-ENODEV);
+
+ pdev = to_pci_dev(dev);
+ vdev = kzalloc(sizeof(*vdev), GFP_KERNEL);
+ if (!vdev)
+ return ERR_PTR(-ENOMEM);
+
+ vdev->dev = dev;
+ vdev->hv_iommu = hv_iommu_device;
+ dev_iommu_priv_set(dev, vdev);
+
+ if (hv_iommu_ats_supported(hv_iommu_device->cap) &&
+ pci_ats_supported(pdev))
+ pci_enable_ats(pdev, __ffs(hv_iommu_device->pgsize_bitmap));
+
+ return &vdev->hv_iommu->iommu;
+}
+
+static void hv_iommu_release_device(struct device *dev)
+{
+ struct hv_iommu_endpoint *vdev = dev_iommu_priv_get(dev);
+
+ if (vdev->hv_domain)
+ hv_iommu_detach_dev(&vdev->hv_domain->domain, dev);
+
+ dev_iommu_priv_set(dev, NULL);
+ set_dma_ops(dev, NULL);
+
+ kfree(vdev);
+}
+
+static struct iommu_group *hv_iommu_device_group(struct device *dev)
+{
+ if (dev_is_pci(dev))
+ return pci_device_group(dev);
+ else
+ return generic_device_group(dev);
+}
+
+static int hv_configure_device_domain(struct hv_iommu_domain *hv_domain, u32 domain_type)
+{
+ u64 status;
+ unsigned long flags;
+ struct pt_iommu_x86_64_hw_info pt_info;
+ struct hv_input_configure_device_domain *input;
+
+ local_irq_save(flags);
+
+ input = *this_cpu_ptr(hyperv_pcpu_input_arg);
+ memset(input, 0, sizeof(*input));
+ input->device_domain = hv_domain->device_domain;
+ input->settings.flags.blocked = (domain_type == IOMMU_DOMAIN_BLOCKED);
+ input->settings.flags.translation_enabled = (domain_type != IOMMU_DOMAIN_IDENTITY);
+
+ if (domain_type & __IOMMU_DOMAIN_PAGING) {
+ pt_iommu_x86_64_hw_info(&hv_domain->pt_iommu_x86_64, &pt_info);
+ input->settings.page_table_root = pt_info.gcr3_pt;
+ input->settings.flags.first_stage_paging_mode =
+ pt_info.levels == 5;
+ }
+ status = hv_do_hypercall(HVCALL_CONFIGURE_DEVICE_DOMAIN, input, NULL);
+
+ local_irq_restore(flags);
+
+ if (!hv_result_success(status))
+ pr_err("%s: hypercall failed, status %lld\n", __func__, status);
+
+ return hv_result_to_errno(status);
+}
+
+static int __init hv_initialize_static_domains(void)
+{
+ int ret;
+ struct hv_iommu_domain *hv_domain;
+
+ /* Default stage-1 identity domain */
+ hv_domain = &hv_identity_domain;
+ memset(hv_domain, 0, sizeof(*hv_domain));
+
+ ret = hv_create_device_domain(hv_domain, HV_DEVICE_DOMAIN_TYPE_S1);
+ if (ret)
+ return ret;
+
+ ret = hv_configure_device_domain(hv_domain, IOMMU_DOMAIN_IDENTITY);
+ if (ret)
+ goto delete_identity_domain;
+
+ hv_domain->domain.type = IOMMU_DOMAIN_IDENTITY;
+ hv_domain->domain.ops = &hv_iommu_identity_domain_ops;
+ hv_domain->domain.owner = &hv_iommu_ops;
+ hv_domain->domain.geometry = hv_iommu_device->geometry;
+ hv_domain->domain.pgsize_bitmap = hv_iommu_device->pgsize_bitmap;
+ INIT_LIST_HEAD(&hv_domain->dev_list);
+
+ /* Default stage-1 blocked domain */
+ hv_domain = &hv_blocking_domain;
+ memset(hv_domain, 0, sizeof(*hv_domain));
+
+ ret = hv_create_device_domain(hv_domain, HV_DEVICE_DOMAIN_TYPE_S1);
+ if (ret)
+ goto delete_identity_domain;
+
+ ret = hv_configure_device_domain(hv_domain, IOMMU_DOMAIN_BLOCKED);
+ if (ret)
+ goto delete_blocked_domain;
+
+ hv_domain->domain.type = IOMMU_DOMAIN_BLOCKED;
+ hv_domain->domain.ops = &hv_iommu_blocking_domain_ops;
+ hv_domain->domain.owner = &hv_iommu_ops;
+ hv_domain->domain.geometry = hv_iommu_device->geometry;
+ hv_domain->domain.pgsize_bitmap = hv_iommu_device->pgsize_bitmap;
+ INIT_LIST_HEAD(&hv_domain->dev_list);
+
+ return 0;
+
+delete_blocked_domain:
+ hv_delete_device_domain(&hv_blocking_domain);
+delete_identity_domain:
+ hv_delete_device_domain(&hv_identity_domain);
+ return ret;
+}
+
+#define INTERRUPT_RANGE_START (0xfee00000)
+#define INTERRUPT_RANGE_END (0xfeefffff)
+static void hv_iommu_get_resv_regions(struct device *dev,
+ struct list_head *head)
+{
+ struct iommu_resv_region *region;
+
+ region = iommu_alloc_resv_region(INTERRUPT_RANGE_START,
+ INTERRUPT_RANGE_END - INTERRUPT_RANGE_START + 1,
+ 0, IOMMU_RESV_MSI, GFP_KERNEL);
+ if (!region)
+ return;
+
+ list_add_tail(®ion->list, head);
+}
+
+static void hv_flush_device_domain(struct hv_iommu_domain *hv_domain)
+{
+ u64 status;
+ unsigned long flags;
+ struct hv_input_flush_device_domain *input;
+
+ local_irq_save(flags);
+
+ input = *this_cpu_ptr(hyperv_pcpu_input_arg);
+ memset(input, 0, sizeof(*input));
+ input->device_domain.partition_id = hv_domain->device_domain.partition_id;
+ input->device_domain.owner_vtl = hv_domain->device_domain.owner_vtl;
+ input->device_domain.domain_id.type = hv_domain->device_domain.domain_id.type;
+ input->device_domain.domain_id.id = hv_domain->device_domain.domain_id.id;
+ status = hv_do_hypercall(HVCALL_FLUSH_DEVICE_DOMAIN, input, NULL);
+
+ local_irq_restore(flags);
+
+ if (!hv_result_success(status))
+ pr_err("%s: hypercall failed, status %lld\n", __func__, status);
+}
+
+static void hv_iommu_flush_iotlb_all(struct iommu_domain *domain)
+{
+ hv_flush_device_domain(to_hv_iommu_domain(domain));
+}
+
+static void hv_iommu_iotlb_sync(struct iommu_domain *domain,
+ struct iommu_iotlb_gather *iotlb_gather)
+{
+ hv_flush_device_domain(to_hv_iommu_domain(domain));
+
+ iommu_put_pages_list(&iotlb_gather->freelist);
+}
+
+static void hv_iommu_paging_domain_free(struct iommu_domain *domain)
+{
+ struct hv_iommu_domain *hv_domain = to_hv_iommu_domain(domain);
+
+ /* Free all remaining mappings */
+ pt_iommu_deinit(&hv_domain->pt_iommu);
+
+ hv_delete_device_domain(hv_domain);
+
+ kfree(hv_domain);
+}
+
+static const struct iommu_domain_ops hv_iommu_identity_domain_ops = {
+ .attach_dev = hv_iommu_attach_dev,
+};
+
+static const struct iommu_domain_ops hv_iommu_blocking_domain_ops = {
+ .attach_dev = hv_iommu_attach_dev,
+};
+
+static const struct iommu_domain_ops hv_iommu_paging_domain_ops = {
+ .attach_dev = hv_iommu_attach_dev,
+ IOMMU_PT_DOMAIN_OPS(x86_64),
+ .flush_iotlb_all = hv_iommu_flush_iotlb_all,
+ .iotlb_sync = hv_iommu_iotlb_sync,
+ .free = hv_iommu_paging_domain_free,
+};
+
+static struct iommu_domain *hv_iommu_domain_alloc_paging(struct device *dev)
+{
+ int ret;
+ struct hv_iommu_domain *hv_domain;
+ struct pt_iommu_x86_64_cfg cfg = {};
+
+ hv_domain = kzalloc(sizeof(*hv_domain), GFP_KERNEL);
+ if (!hv_domain)
+ return ERR_PTR(-ENOMEM);
+
+ ret = hv_create_device_domain(hv_domain, HV_DEVICE_DOMAIN_TYPE_S1);
+ if (ret) {
+ kfree(hv_domain);
+ return ERR_PTR(ret);
+ }
+
+ hv_domain->domain.pgsize_bitmap = hv_iommu_device->pgsize_bitmap;
+ hv_domain->domain.geometry = hv_iommu_device->geometry;
+ hv_domain->pt_iommu.nid = dev_to_node(dev);
+ INIT_LIST_HEAD(&hv_domain->dev_list);
+ spin_lock_init(&hv_domain->lock);
+
+ cfg.common.hw_max_vasz_lg2 = hv_iommu_device->max_iova_width;
+ cfg.common.hw_max_oasz_lg2 = 52;
+
+ ret = pt_iommu_x86_64_init(&hv_domain->pt_iommu_x86_64, &cfg, GFP_KERNEL);
+ if (ret) {
+ hv_delete_device_domain(hv_domain);
+ return ERR_PTR(ret);
+ }
+
+ hv_domain->domain.ops = &hv_iommu_paging_domain_ops;
+
+ ret = hv_configure_device_domain(hv_domain, __IOMMU_DOMAIN_PAGING);
+ if (ret) {
+ pt_iommu_deinit(&hv_domain->pt_iommu);
+ hv_delete_device_domain(hv_domain);
+ return ERR_PTR(ret);
+ }
+
+ return &hv_domain->domain;
+}
+
+static struct iommu_ops hv_iommu_ops = {
+ .capable = hv_iommu_capable,
+ .domain_alloc_paging = hv_iommu_domain_alloc_paging,
+ .probe_device = hv_iommu_probe_device,
+ .release_device = hv_iommu_release_device,
+ .device_group = hv_iommu_device_group,
+ .get_resv_regions = hv_iommu_get_resv_regions,
+ .owner = THIS_MODULE,
+ .identity_domain = &hv_identity_domain.domain,
+ .blocked_domain = &hv_blocking_domain.domain,
+ .release_domain = &hv_blocking_domain.domain,
+};
+
+static void hv_iommu_shutdown(void)
+{
+ iommu_device_sysfs_remove(&hv_iommu_device->iommu);
+
+ kfree(hv_iommu_device);
+}
+
+static struct syscore_ops hv_iommu_syscore_ops = {
+ .shutdown = hv_iommu_shutdown,
+};
+
+static int hv_iommu_detect(struct hv_output_get_iommu_capabilities *hv_iommu_cap)
+{
+ u64 status;
+ unsigned long flags;
+ struct hv_input_get_iommu_capabilities *input;
+ struct hv_output_get_iommu_capabilities *output;
+
+ local_irq_save(flags);
+
+ input = *this_cpu_ptr(hyperv_pcpu_input_arg);
+ output = *this_cpu_ptr(hyperv_pcpu_output_arg);
+ memset(input, 0, sizeof(*input));
+ memset(output, 0, sizeof(*output));
+ input->partition_id = HV_PARTITION_ID_SELF;
+ status = hv_do_hypercall(HVCALL_GET_IOMMU_CAPABILITIES, input, output);
+ *hv_iommu_cap = *output;
+
+ local_irq_restore(flags);
+
+ if (!hv_result_success(status))
+ pr_err("%s: hypercall failed, status %lld\n", __func__, status);
+
+ return hv_result_to_errno(status);
+}
+
+static void __init hv_init_iommu_device(struct hv_iommu_dev *hv_iommu,
+ struct hv_output_get_iommu_capabilities *hv_iommu_cap)
+{
+ ida_init(&hv_iommu->domain_ids);
+
+ hv_iommu->cap = hv_iommu_cap->iommu_cap;
+ hv_iommu->max_iova_width = hv_iommu_cap->max_iova_width;
+ if (!hv_iommu_5lvl_supported(hv_iommu->cap) &&
+ hv_iommu->max_iova_width > 48) {
+ pr_err("5-level paging not supported, limiting iova width to 48.\n");
+ hv_iommu->max_iova_width = 48;
+ }
+
+ hv_iommu->geometry = (struct iommu_domain_geometry) {
+ .aperture_start = 0,
+ .aperture_end = (((u64)1) << hv_iommu_cap->max_iova_width) - 1,
+ .force_aperture = true,
+ };
+
+ hv_iommu->first_domain = HV_DEVICE_DOMAIN_ID_DEFAULT + 1;
+ hv_iommu->last_domain = HV_DEVICE_DOMAIN_ID_NULL - 1;
+ hv_iommu->pgsize_bitmap = hv_iommu_cap->pgsize_bitmap;
+ hv_iommu_device = hv_iommu;
+}
+
+static int __init hv_iommu_init(void)
+{
+ int ret = 0;
+ struct hv_iommu_dev *hv_iommu = NULL;
+ struct hv_output_get_iommu_capabilities hv_iommu_cap = {0};
+
+ if (no_iommu || iommu_detected)
+ return -ENODEV;
+
+ if (!hv_is_hyperv_initialized())
+ return -ENODEV;
+
+ if (hv_iommu_detect(&hv_iommu_cap) ||
+ !hv_iommu_present(hv_iommu_cap.iommu_cap) ||
+ !hv_iommu_s1_domain_supported(hv_iommu_cap.iommu_cap))
+ return -ENODEV;
+
+ iommu_detected = 1;
+ pci_request_acs();
+
+ hv_iommu = kzalloc(sizeof(*hv_iommu), GFP_KERNEL);
+ if (!hv_iommu)
+ return -ENOMEM;
+
+ hv_init_iommu_device(hv_iommu, &hv_iommu_cap);
+
+ ret = hv_initialize_static_domains();
+ if (ret) {
+ pr_err("hv_initialize_static_domains failed: %d\n", ret);
+ goto err_sysfs_remove;
+ }
+
+ ret = iommu_device_sysfs_add(&hv_iommu->iommu, NULL, NULL, "%s", "hv-iommu");
+ if (ret) {
+ pr_err("iommu_device_sysfs_add failed: %d\n", ret);
+ goto err_free;
+ }
+
+
+ ret = iommu_device_register(&hv_iommu->iommu, &hv_iommu_ops, NULL);
+ if (ret) {
+ pr_err("iommu_device_register failed: %d\n", ret);
+ goto err_sysfs_remove;
+ }
+
+ register_syscore_ops(&hv_iommu_syscore_ops);
+
+ pr_info("Microsoft Hypervisor IOMMU initialized\n");
+ return 0;
+
+err_sysfs_remove:
+ iommu_device_sysfs_remove(&hv_iommu->iommu);
+err_free:
+ kfree(hv_iommu);
+ return ret;
+}
+
+device_initcall(hv_iommu_init);
diff --git a/drivers/iommu/hyperv/iommu.h b/drivers/iommu/hyperv/iommu.h
new file mode 100644
index 000000000000..c8657e791a6e
--- /dev/null
+++ b/drivers/iommu/hyperv/iommu.h
@@ -0,0 +1,53 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+/*
+ * Hyper-V IOMMU driver.
+ *
+ * Copyright (C) 2024-2025, Microsoft, Inc.
+ *
+ */
+
+#ifndef _HYPERV_IOMMU_H
+#define _HYPERV_IOMMU_H
+
+struct hv_iommu_dev {
+ struct iommu_device iommu;
+ struct ida domain_ids;
+
+ /* Device configuration */
+ u8 max_iova_width;
+ u8 max_pasid_width;
+ u64 cap;
+ u64 pgsize_bitmap;
+
+ struct iommu_domain_geometry geometry;
+ u64 first_domain;
+ u64 last_domain;
+};
+
+struct hv_iommu_domain {
+ union {
+ struct iommu_domain domain;
+ struct pt_iommu pt_iommu;
+ struct pt_iommu_x86_64 pt_iommu_x86_64;
+ };
+ struct hv_iommu_dev *hv_iommu;
+ struct hv_input_device_domain device_domain;
+ u64 pgsize_bitmap;
+
+ spinlock_t lock; /* protects dev_list and TLB flushes */
+ /* List of devices in this DMA domain */
+ struct list_head dev_list;
+};
+
+struct hv_iommu_endpoint {
+ struct device *dev;
+ struct hv_iommu_dev *hv_iommu;
+ struct hv_iommu_domain *hv_domain;
+ struct list_head list; /* For domain->dev_list */
+};
+
+#define to_hv_iommu_domain(d) \
+ container_of(d, struct hv_iommu_domain, domain)
+
+#endif /* _HYPERV_IOMMU_H */
--
2.49.0
^ permalink raw reply related
* Re: [RFC v1 1/5] PCI: hv: Create and export hv_build_logical_dev_id()
From: Randy Dunlap @ 2025-12-09 5:21 UTC (permalink / raw)
To: Yu Zhang, linux-kernel, linux-hyperv, iommu, linux-pci
Cc: kys, haiyangz, wei.liu, decui, lpieralisi, kwilczynski, mani,
robh, bhelgaas, arnd, joro, will, robin.murphy, easwar.hariharan,
jacob.pan, nunodasneves, mrathor, mhklinux, peterz, linux-arch
In-Reply-To: <20251209051128.76913-2-zhangyu1@linux.microsoft.com>
Hi--
On 12/8/25 9:11 PM, Yu Zhang wrote:
> From: Easwar Hariharan <easwar.hariharan@linux.microsoft.com>
>
> Hyper-V uses a logical device ID to identify a PCI endpoint device for
> child partitions. This ID will also be required for future hypercalls
> used by the Hyper-V IOMMU driver.
>
> Refactor the logic for building this logical device ID into a standalone
> helper function and export the interface for wider use.
>
> Signed-off-by: Easwar Hariharan <easwar.hariharan@linux.microsoft.com>
> Signed-off-by: Yu Zhang <zhangyu1@linux.microsoft.com>
> ---
> drivers/pci/controller/pci-hyperv.c | 28 ++++++++++++++++++++--------
> include/asm-generic/mshyperv.h | 2 ++
> 2 files changed, 22 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c
> index 146b43981b27..4b82e06b5d93 100644
> --- a/drivers/pci/controller/pci-hyperv.c
> +++ b/drivers/pci/controller/pci-hyperv.c
> @@ -598,15 +598,31 @@ static unsigned int hv_msi_get_int_vector(struct irq_data *data)
>
> #define hv_msi_prepare pci_msi_prepare
>
> +/**
> + * Build a "Device Logical ID" out of this PCI bus's instance GUID and the
> + * function number of the device.
> + */
Don't use kernel-doc notation "/**" unless you are using kernel-doc comments.
You could just convert it to a kernel-doc style comment...
> +u64 hv_build_logical_dev_id(struct pci_dev *pdev)
> +{
thanks.
--
~Randy
^ permalink raw reply
* [PATCH] mshv: Use PMD_ORDER instead of HPAGE_PMD_ORDER when processing regions
From: Stanislav Kinsburskii @ 2025-12-09 16:37 UTC (permalink / raw)
To: kys, haiyangz, wei.liu, decui, longli; +Cc: linux-hyperv, linux-kernel
Fix page order determination logic when CONFIG_PGTABLE_HAS_HUGE_LEAVES
is undefined, as HPAGE_PMD_SHIFT is defined as BUILD_BUG in that case.
Fixes: abceb4297bf8 ("mshv: Fix huge page handling in memory region
traversal")
Signed-off-by: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>
---
drivers/hv/mshv_regions.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hv/mshv_regions.c b/drivers/hv/mshv_regions.c
index 202b9d551e39..dc2d7044fb91 100644
--- a/drivers/hv/mshv_regions.c
+++ b/drivers/hv/mshv_regions.c
@@ -58,7 +58,7 @@ static long mshv_region_process_chunk(struct mshv_mem_region *region,
page_order = folio_order(page_folio(page));
/* The hypervisor only supports 4K and 2M page sizes */
- if (page_order && page_order != HPAGE_PMD_ORDER)
+ if (page_order && page_order != PMD_ORDER)
return -EINVAL;
stride = 1 << page_order;
^ permalink raw reply related
* [bug report] mshv: Add support for movable memory regions
From: Dan Carpenter @ 2025-12-10 8:02 UTC (permalink / raw)
To: Stanislav Kinsburskii; +Cc: linux-hyperv
Hello Stanislav Kinsburskii,
Commit b9a66cd5ccbb ("mshv: Add support for movable memory regions")
from Dec 3, 2025 (linux-next), leads to the following Smatch static
checker warning:
drivers/hv/mshv_regions.c:523 mshv_region_interval_invalidate()
warn: passing uninitialized 'page_offset'
drivers/hv/mshv_regions.c
486 static bool mshv_region_interval_invalidate(struct mmu_interval_notifier *mni,
487 const struct mmu_notifier_range *range,
488 unsigned long cur_seq)
489 {
490 struct mshv_mem_region *region = container_of(mni,
491 struct mshv_mem_region,
492 mni);
493 u64 page_offset, page_count;
494 unsigned long mstart, mend;
495 int ret = -EPERM;
496
497 if (mmu_notifier_range_blockable(range))
498 mutex_lock(®ion->mutex);
499 else if (!mutex_trylock(®ion->mutex))
500 goto out_fail;
page_offset and page_count are uninitialized.
501
502 mmu_interval_set_seq(mni, cur_seq);
503
504 mstart = max(range->start, region->start_uaddr);
505 mend = min(range->end, region->start_uaddr +
506 (region->nr_pages << HV_HYP_PAGE_SHIFT));
507
508 page_offset = HVPFN_DOWN(mstart - region->start_uaddr);
509 page_count = HVPFN_DOWN(mend - mstart);
510
511 ret = mshv_region_remap_pages(region, HV_MAP_GPA_NO_ACCESS,
512 page_offset, page_count);
513 if (ret)
514 goto out_fail;
515
516 mshv_region_invalidate_pages(region, page_offset, page_count);
517
518 mutex_unlock(®ion->mutex);
519
520 return true;
521
522 out_fail:
--> 523 WARN_ONCE(ret,
524 "Failed to invalidate region %#llx-%#llx (range %#lx-%#lx, event: %u, pages %#llx-%#llx, mm: %#llx): %d\n",
525 region->start_uaddr,
526 region->start_uaddr + (region->nr_pages << HV_HYP_PAGE_SHIFT),
527 range->start, range->end, range->event,
528 page_offset, page_offset + page_count - 1, (u64)range->mm, ret);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
529 return false;
530 }
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH v7 0/4] Add support for clean shutdown with MSHV
From: Nathan Chancellor @ 2025-12-10 8:14 UTC (permalink / raw)
To: Praveen K Paladugu
Cc: kys, haiyangz, wei.liu, decui, tglx, mingo, linux-hyperv,
linux-kernel, bp, dave.hansen, x86, hpa, arnd, anbelski,
easwar.hariharan, nunodasneves, skinsburskii
In-Reply-To: <20251205201721.7253-1-prapal@linux.microsoft.com>
Hi Praveen,
On Fri, Dec 05, 2025 at 02:17:04PM -0600, Praveen K Paladugu wrote:
...
> hyperv: Use reboot notifier to configure sleep state
> hyperv: Cleanly shutdown root partition with MSHV
These two patches result in warnings (that get upgraded to errors with
CONFIG_WERROR=y / W=e) on arm64:
$ make -skj"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux- clean defconfig
$ scripts/config -e HYPERV -e MSHV_ROOT
$ make -skj"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux- olddefconfig drivers/hv/mshv_common.o
drivers/hv/mshv_common.c:210:6: warning: no previous prototype for 'hv_sleep_notifiers_register' [-Wmissing-prototypes]
210 | void hv_sleep_notifiers_register(void)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/hv/mshv_common.c:224:6: warning: no previous prototype for 'hv_machine_power_off' [-Wmissing-prototypes]
224 | void hv_machine_power_off(void)
| ^~~~~~~~~~~~~~~~~~~~
The prototypes for these functions are only available for x86.
Cheers,
Nathan
^ permalink raw reply
* Dostawa sprzętu
From: Tomasz Chabierski @ 2025-12-10 9:16 UTC (permalink / raw)
To: linux-hyperv
Dzień dobry,
reprezentuję dystrybutora sprzętu elektronicznego i IT, oferującego ponad 90 000 produktów od 1 100 marek z możliwością wysyłki tego samego dnia.
Wspieramy firmy w doborze odpowiednich rozwiązań – od akcesoriów po nowoczesne technologie zwiększające efektywność operacyjną. Zapewniamy pełne wsparcie ekspertów oraz możliwość przetestowania produktów przed większym zamówieniem.
Chętnie porozmawiam o tym, jak możemy wspierać Państwa cele biznesowe.
Kiedy moglibyśmy umówić się na rozmowę?
Pozdrawiam
Tomasz Chabierski
^ permalink raw reply
* Re: [RFC v1 1/5] PCI: hv: Create and export hv_build_logical_dev_id()
From: Easwar Hariharan @ 2025-12-10 17:03 UTC (permalink / raw)
To: Randy Dunlap
Cc: Yu Zhang, linux-kernel, linux-hyperv, iommu, linux-pci,
easwar.hariharan, kys, haiyangz, wei.liu, decui, lpieralisi,
kwilczynski, mani, robh, bhelgaas, arnd, joro, will, robin.murphy,
jacob.pan, nunodasneves, mrathor, mhklinux, peterz, linux-arch
In-Reply-To: <827c75e4-8e6c-4e98-9a1a-80ddba0de61a@infradead.org>
On 12/8/2025 9:21 PM, Randy Dunlap wrote:
> Hi--
>
> On 12/8/25 9:11 PM, Yu Zhang wrote:
>> From: Easwar Hariharan <easwar.hariharan@linux.microsoft.com>
>>
>> Hyper-V uses a logical device ID to identify a PCI endpoint device for
>> child partitions. This ID will also be required for future hypercalls
>> used by the Hyper-V IOMMU driver.
>>
>> Refactor the logic for building this logical device ID into a standalone
>> helper function and export the interface for wider use.
>>
>> Signed-off-by: Easwar Hariharan <easwar.hariharan@linux.microsoft.com>
>> Signed-off-by: Yu Zhang <zhangyu1@linux.microsoft.com>
>> ---
>> drivers/pci/controller/pci-hyperv.c | 28 ++++++++++++++++++++--------
>> include/asm-generic/mshyperv.h | 2 ++
>> 2 files changed, 22 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c
>> index 146b43981b27..4b82e06b5d93 100644
>> --- a/drivers/pci/controller/pci-hyperv.c
>> +++ b/drivers/pci/controller/pci-hyperv.c
>> @@ -598,15 +598,31 @@ static unsigned int hv_msi_get_int_vector(struct irq_data *data)
>>
>> #define hv_msi_prepare pci_msi_prepare
>>
>> +/**
>> + * Build a "Device Logical ID" out of this PCI bus's instance GUID and the
>> + * function number of the device.
>> + */
>
> Don't use kernel-doc notation "/**" unless you are using kernel-doc comments.
> You could just convert it to a kernel-doc style comment...
Thank you for the review, I will fix in a future revision.
Thanks,
Easwar (he/him)
^ permalink raw reply
* Re: [RFC v1 5/5] iommu/hyperv: Add para-virtualized IOMMU support for Hyper-V guest
From: Easwar Hariharan @ 2025-12-10 17:15 UTC (permalink / raw)
To: Yu Zhang
Cc: linux-kernel, linux-hyperv, iommu, linux-pci, easwar.hariharan,
kys, haiyangz, wei.liu, decui, lpieralisi, kwilczynski, mani,
robh, bhelgaas, arnd, joro, will, robin.murphy, jacob.pan,
nunodasneves, mrathor, mhklinux, peterz, linux-arch
In-Reply-To: <20251209051128.76913-6-zhangyu1@linux.microsoft.com>
On 12/8/2025 9:11 PM, Yu Zhang wrote:
> Add a para-virtualized IOMMU driver for Linux guests running on Hyper-V.
> This driver implements stage-1 IO translation within the guest OS.
> It integrates with the Linux IOMMU core, utilizing Hyper-V hypercalls
> for:
> - Capability discovery
> - Domain allocation, configuration, and deallocation
> - Device attachment and detachment
> - IOTLB invalidation
>
> The driver constructs x86-compatible stage-1 IO page tables in the
> guest memory using consolidated IO page table helpers. This allows
> the guest to manage stage-1 translations independently of vendor-
> specific drivers (like Intel VT-d or AMD IOMMU).
>
> Hyper-v consumes this stage-1 IO page table, when a device domain is
> created and configured, and nests it with the host's stage-2 IO page
> tables, therefore elemenating the VM exits for guest IOMMU mapping
> operations.
>
> For guest IOMMU unmapping operations, VM exits to perform the IOTLB
> flush(and possibly the device TLB flush) is still unavoidable. For
> now, HVCALL_FLUSH_DEVICE_DOMAIN is used to implement a domain-selective
> IOTLB flush. New hypercalls for finer-grained hypercall will be provided
> in future patches.
>
> Co-developed-by: Wei Liu <wei.liu@kernel.org>
> Signed-off-by: Wei Liu <wei.liu@kernel.org>
> Co-developed-by: Jacob Pan <jacob.pan@linux.microsoft.com>
> Signed-off-by: Jacob Pan <jacob.pan@linux.microsoft.com>
> Co-developed-by: Easwar Hariharan <easwar.hariharan@linux.microsoft.com>
> Signed-off-by: Easwar Hariharan <easwar.hariharan@linux.microsoft.com>
> Signed-off-by: Yu Zhang <zhangyu1@linux.microsoft.com>
> ---
> drivers/iommu/hyperv/Kconfig | 14 +
> drivers/iommu/hyperv/Makefile | 1 +
> drivers/iommu/hyperv/iommu.c | 608 ++++++++++++++++++++++++++++++++++
> drivers/iommu/hyperv/iommu.h | 53 +++
> 4 files changed, 676 insertions(+)
> create mode 100644 drivers/iommu/hyperv/iommu.c
> create mode 100644 drivers/iommu/hyperv/iommu.h
>
<snip>
> +
> +static int __init hv_iommu_init(void)
> +{
> + int ret = 0;
> + struct hv_iommu_dev *hv_iommu = NULL;
> + struct hv_output_get_iommu_capabilities hv_iommu_cap = {0};
> +
> + if (no_iommu || iommu_detected)
> + return -ENODEV;
> +
> + if (!hv_is_hyperv_initialized())
> + return -ENODEV;
> +
> + if (hv_iommu_detect(&hv_iommu_cap) ||
> + !hv_iommu_present(hv_iommu_cap.iommu_cap) ||
> + !hv_iommu_s1_domain_supported(hv_iommu_cap.iommu_cap))
> + return -ENODEV;
> +
> + iommu_detected = 1;
> + pci_request_acs();
> +
> + hv_iommu = kzalloc(sizeof(*hv_iommu), GFP_KERNEL);
> + if (!hv_iommu)
> + return -ENOMEM;
> +
> + hv_init_iommu_device(hv_iommu, &hv_iommu_cap);
> +
> + ret = hv_initialize_static_domains();
> + if (ret) {
> + pr_err("hv_initialize_static_domains failed: %d\n", ret);
> + goto err_sysfs_remove;
This should be goto err_free since we haven't done the sysfs_add yet
> + }
> +
> + ret = iommu_device_sysfs_add(&hv_iommu->iommu, NULL, NULL, "%s", "hv-iommu");
> + if (ret) {
> + pr_err("iommu_device_sysfs_add failed: %d\n", ret);
> + goto err_free;
And this should be probably a goto delete_static_domains that cleans up the allocated static
domains...
> + }
> +
> +
> + ret = iommu_device_register(&hv_iommu->iommu, &hv_iommu_ops, NULL);
> + if (ret) {
> + pr_err("iommu_device_register failed: %d\n", ret);
> + goto err_sysfs_remove;
> + }
> +
> + register_syscore_ops(&hv_iommu_syscore_ops);
> +
> + pr_info("Microsoft Hypervisor IOMMU initialized\n");
> + return 0;
> +
> +err_sysfs_remove:
> + iommu_device_sysfs_remove(&hv_iommu->iommu);
> +err_free:
> + kfree(hv_iommu);
> + return ret;
> +}
> +
> +device_initcall(hv_iommu_init);
<snip>
^ permalink raw reply
* [PATCH] mshv: Initialize local variables early upon region invalidation
From: Stanislav Kinsburskii @ 2025-12-10 17:55 UTC (permalink / raw)
To: kys, haiyangz, wei.liu, decui, longli; +Cc: linux-hyperv, linux-kernel
Ensure local variables are initialized before use so that the warning can
print the right values if locking the region to invalidate fails due to
inability to lock the region.
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Fixes: b9a66cd5ccbb ("mshv: Add support for movable memory regions")
Signed-off-by: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>
---
drivers/hv/mshv_regions.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/hv/mshv_regions.c b/drivers/hv/mshv_regions.c
index dc2d7044fb91..8abf80129f9b 100644
--- a/drivers/hv/mshv_regions.c
+++ b/drivers/hv/mshv_regions.c
@@ -494,13 +494,6 @@ static bool mshv_region_interval_invalidate(struct mmu_interval_notifier *mni,
unsigned long mstart, mend;
int ret = -EPERM;
- if (mmu_notifier_range_blockable(range))
- mutex_lock(®ion->mutex);
- else if (!mutex_trylock(®ion->mutex))
- goto out_fail;
-
- mmu_interval_set_seq(mni, cur_seq);
-
mstart = max(range->start, region->start_uaddr);
mend = min(range->end, region->start_uaddr +
(region->nr_pages << HV_HYP_PAGE_SHIFT));
@@ -508,6 +501,13 @@ static bool mshv_region_interval_invalidate(struct mmu_interval_notifier *mni,
page_offset = HVPFN_DOWN(mstart - region->start_uaddr);
page_count = HVPFN_DOWN(mend - mstart);
+ if (mmu_notifier_range_blockable(range))
+ mutex_lock(®ion->mutex);
+ else if (!mutex_trylock(®ion->mutex))
+ goto out_fail;
+
+ mmu_interval_set_seq(mni, cur_seq);
+
ret = mshv_region_remap_pages(region, HV_MAP_GPA_NO_ACCESS,
page_offset, page_count);
if (ret)
^ permalink raw reply related
* Re: [RFC v1 1/5] PCI: hv: Create and export hv_build_logical_dev_id()
From: Bjorn Helgaas @ 2025-12-10 21:39 UTC (permalink / raw)
To: Yu Zhang
Cc: linux-kernel, linux-hyperv, iommu, linux-pci, kys, haiyangz,
wei.liu, decui, lpieralisi, kwilczynski, mani, robh, bhelgaas,
arnd, joro, will, robin.murphy, easwar.hariharan, jacob.pan,
nunodasneves, mrathor, mhklinux, peterz, linux-arch
In-Reply-To: <20251209051128.76913-2-zhangyu1@linux.microsoft.com>
On Tue, Dec 09, 2025 at 01:11:24PM +0800, Yu Zhang wrote:
> From: Easwar Hariharan <easwar.hariharan@linux.microsoft.com>
>
> Hyper-V uses a logical device ID to identify a PCI endpoint device for
> child partitions. This ID will also be required for future hypercalls
> used by the Hyper-V IOMMU driver.
>
> Refactor the logic for building this logical device ID into a standalone
> helper function and export the interface for wider use.
>
> Signed-off-by: Easwar Hariharan <easwar.hariharan@linux.microsoft.com>
> Signed-off-by: Yu Zhang <zhangyu1@linux.microsoft.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> ---
> drivers/pci/controller/pci-hyperv.c | 28 ++++++++++++++++++++--------
> include/asm-generic/mshyperv.h | 2 ++
> 2 files changed, 22 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c
> index 146b43981b27..4b82e06b5d93 100644
> --- a/drivers/pci/controller/pci-hyperv.c
> +++ b/drivers/pci/controller/pci-hyperv.c
> @@ -598,15 +598,31 @@ static unsigned int hv_msi_get_int_vector(struct irq_data *data)
>
> #define hv_msi_prepare pci_msi_prepare
>
> +/**
> + * Build a "Device Logical ID" out of this PCI bus's instance GUID and the
> + * function number of the device.
> + */
> +u64 hv_build_logical_dev_id(struct pci_dev *pdev)
> +{
> + struct pci_bus *pbus = pdev->bus;
> + struct hv_pcibus_device *hbus = container_of(pbus->sysdata,
> + struct hv_pcibus_device, sysdata);
> +
> + return (u64)((hbus->hdev->dev_instance.b[5] << 24) |
> + (hbus->hdev->dev_instance.b[4] << 16) |
> + (hbus->hdev->dev_instance.b[7] << 8) |
> + (hbus->hdev->dev_instance.b[6] & 0xf8) |
> + PCI_FUNC(pdev->devfn));
> +}
> +EXPORT_SYMBOL_GPL(hv_build_logical_dev_id);
> +
> /**
> * hv_irq_retarget_interrupt() - "Unmask" the IRQ by setting its current
> * affinity.
> * @data: Describes the IRQ
> *
> * Build new a destination for the MSI and make a hypercall to
> - * update the Interrupt Redirection Table. "Device Logical ID"
> - * is built out of this PCI bus's instance GUID and the function
> - * number of the device.
> + * update the Interrupt Redirection Table.
> */
> static void hv_irq_retarget_interrupt(struct irq_data *data)
> {
> @@ -642,11 +658,7 @@ static void hv_irq_retarget_interrupt(struct irq_data *data)
> params->int_entry.source = HV_INTERRUPT_SOURCE_MSI;
> params->int_entry.msi_entry.address.as_uint32 = int_desc->address & 0xffffffff;
> params->int_entry.msi_entry.data.as_uint32 = int_desc->data;
> - params->device_id = (hbus->hdev->dev_instance.b[5] << 24) |
> - (hbus->hdev->dev_instance.b[4] << 16) |
> - (hbus->hdev->dev_instance.b[7] << 8) |
> - (hbus->hdev->dev_instance.b[6] & 0xf8) |
> - PCI_FUNC(pdev->devfn);
> + params->device_id = hv_build_logical_dev_id(pdev);
> params->int_target.vector = hv_msi_get_int_vector(data);
>
> if (hbus->protocol_version >= PCI_PROTOCOL_VERSION_1_2) {
> diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyperv.h
> index 64ba6bc807d9..1a205ed69435 100644
> --- a/include/asm-generic/mshyperv.h
> +++ b/include/asm-generic/mshyperv.h
> @@ -71,6 +71,8 @@ extern enum hv_partition_type hv_curr_partition_type;
> extern void * __percpu *hyperv_pcpu_input_arg;
> extern void * __percpu *hyperv_pcpu_output_arg;
>
> +extern u64 hv_build_logical_dev_id(struct pci_dev *pdev);
Curious why you would include the "extern" in this declaration? It's
not *wrong*, but it's not necessary, and other declarations in this
file omit it, e.g., the ones below:
> u64 hv_do_hypercall(u64 control, void *inputaddr, void *outputaddr);
> u64 hv_do_fast_hypercall8(u16 control, u64 input8);
> u64 hv_do_fast_hypercall16(u16 control, u64 input1, u64 input2);
> --
> 2.49.0
>
^ permalink raw reply
* [PATCH] mshv: Move function prototypes to the generic header
From: wei.liu @ 2025-12-10 21:46 UTC (permalink / raw)
To: Linux on Hyper-V List
Cc: Wei Liu, Nathan Chancellor, K. Y. Srinivasan, Haiyang Zhang,
Dexuan Cui, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
H. Peter Anvin, Arnd Bergmann, Praveen K Paladugu,
Easwar Hariharan, Anatol Belski, Stanislav Kinsburskii,
Nuno Das Neves, open list:X86 ARCHITECTURE (32-BIT AND 64-BIT),
open list:GENERIC INCLUDE/ASM HEADER FILES
From: Wei Liu <wei.liu@kernel.org>
The same code is built on both x86 and ARM64 architectures. This fixes
two missing prototype warnings when building on ARM64.
This only eliminates the warnings. Making things work on ARM64 requires
more work.
Reported-by: Nathan Chancellor <nathan@kernel.org>
Fixes: 615a6e7d83f9 ("mshv: Cleanly shutdown root partition with MSHV")
Fixes: f0be2600ac55 ("mshv: Use reboot notifier to configure sleep state")
Signed-off-by: Wei Liu <wei.liu@kernel.org>
---
arch/x86/include/asm/mshyperv.h | 2 --
include/asm-generic/mshyperv.h | 2 ++
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index eef4c3a5ba28..10037125099a 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -177,8 +177,6 @@ int hyperv_flush_guest_mapping_range(u64 as,
int hyperv_fill_flush_guest_mapping_list(
struct hv_guest_mapping_flush_list *flush,
u64 start_gfn, u64 end_gfn);
-void hv_sleep_notifiers_register(void);
-void hv_machine_power_off(void);
#ifdef CONFIG_X86_64
void hv_apic_init(void);
diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyperv.h
index ecedab554c80..d4eded472db7 100644
--- a/include/asm-generic/mshyperv.h
+++ b/include/asm-generic/mshyperv.h
@@ -316,6 +316,8 @@ void hv_para_set_synic_register(unsigned int reg, u64 val);
void hyperv_cleanup(void);
bool hv_query_ext_cap(u64 cap_query);
void hv_setup_dma_ops(struct device *dev, bool coherent);
+void hv_sleep_notifiers_register(void);
+void hv_machine_power_off(void);
#else /* CONFIG_HYPERV */
static inline void hv_identify_partition_type(void) {}
static inline bool hv_is_hyperv_initialized(void) { return false; }
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] mshv: Move function prototypes to the generic header
From: Hamza Mahfooz @ 2025-12-10 21:54 UTC (permalink / raw)
To: wei.liu
Cc: Linux on Hyper-V List, Nathan Chancellor, K. Y. Srinivasan,
Haiyang Zhang, Dexuan Cui, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT), H. Peter Anvin,
Arnd Bergmann, Praveen K Paladugu, Easwar Hariharan,
Anatol Belski, Stanislav Kinsburskii, Nuno Das Neves,
open list:X86 ARCHITECTURE (32-BIT AND 64-BIT),
open list:GENERIC INCLUDE/ASM HEADER FILES
In-Reply-To: <20251210214625.3114545-1-wei.liu@kernel.org>
On Wed, Dec 10, 2025 at 09:46:24PM +0000, wei.liu@kernel.org wrote:
> From: Wei Liu <wei.liu@kernel.org>
>
> The same code is built on both x86 and ARM64 architectures. This fixes
> two missing prototype warnings when building on ARM64.
>
> This only eliminates the warnings. Making things work on ARM64 requires
> more work.
>
> Reported-by: Nathan Chancellor <nathan@kernel.org>
> Fixes: 615a6e7d83f9 ("mshv: Cleanly shutdown root partition with MSHV")
> Fixes: f0be2600ac55 ("mshv: Use reboot notifier to configure sleep state")
> Signed-off-by: Wei Liu <wei.liu@kernel.org>
Reviewed-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com>
^ permalink raw reply
* Re: [PATCH] mshv: Use PMD_ORDER instead of HPAGE_PMD_ORDER when processing regions
From: Wei Liu @ 2025-12-10 22:43 UTC (permalink / raw)
To: Stanislav Kinsburskii
Cc: kys, haiyangz, wei.liu, decui, longli, linux-hyperv, linux-kernel
In-Reply-To: <176529822862.17729.14849117117197568731.stgit@skinsburskii-cloud-desktop.internal.cloudapp.net>
On Tue, Dec 09, 2025 at 04:37:20PM +0000, Stanislav Kinsburskii wrote:
> Fix page order determination logic when CONFIG_PGTABLE_HAS_HUGE_LEAVES
> is undefined, as HPAGE_PMD_SHIFT is defined as BUILD_BUG in that case.
>
> Fixes: abceb4297bf8 ("mshv: Fix huge page handling in memory region
> traversal")
> Signed-off-by: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>
Queued.
> ---
> drivers/hv/mshv_regions.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hv/mshv_regions.c b/drivers/hv/mshv_regions.c
> index 202b9d551e39..dc2d7044fb91 100644
> --- a/drivers/hv/mshv_regions.c
> +++ b/drivers/hv/mshv_regions.c
> @@ -58,7 +58,7 @@ static long mshv_region_process_chunk(struct mshv_mem_region *region,
>
> page_order = folio_order(page_folio(page));
> /* The hypervisor only supports 4K and 2M page sizes */
> - if (page_order && page_order != HPAGE_PMD_ORDER)
> + if (page_order && page_order != PMD_ORDER)
> return -EINVAL;
>
> stride = 1 << page_order;
>
>
^ permalink raw reply
* Re: [PATCH] mshv: Initialize local variables early upon region invalidation
From: Wei Liu @ 2025-12-10 22:43 UTC (permalink / raw)
To: Stanislav Kinsburskii
Cc: kys, haiyangz, wei.liu, decui, longli, linux-hyperv, linux-kernel
In-Reply-To: <176538934140.22759.15324831745272282048.stgit@skinsburskii-cloud-desktop.internal.cloudapp.net>
On Wed, Dec 10, 2025 at 05:55:47PM +0000, Stanislav Kinsburskii wrote:
> Ensure local variables are initialized before use so that the warning can
> print the right values if locking the region to invalidate fails due to
> inability to lock the region.
>
> Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
> Fixes: b9a66cd5ccbb ("mshv: Add support for movable memory regions")
> Signed-off-by: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>
Queued.
^ permalink raw reply
* Re: [RFC v1 1/5] PCI: hv: Create and export hv_build_logical_dev_id()
From: Yu Zhang @ 2025-12-11 8:31 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: linux-kernel, linux-hyperv, iommu, linux-pci, kys, haiyangz,
wei.liu, decui, lpieralisi, kwilczynski, mani, robh, bhelgaas,
arnd, joro, will, robin.murphy, easwar.hariharan, jacob.pan,
nunodasneves, mrathor, mhklinux, peterz, linux-arch
In-Reply-To: <20251210213945.GA3541010@bhelgaas>
On Wed, Dec 10, 2025 at 03:39:45PM -0600, Bjorn Helgaas wrote:
> On Tue, Dec 09, 2025 at 01:11:24PM +0800, Yu Zhang wrote:
> > From: Easwar Hariharan <easwar.hariharan@linux.microsoft.com>
> >
> > Hyper-V uses a logical device ID to identify a PCI endpoint device for
> > child partitions. This ID will also be required for future hypercalls
> > used by the Hyper-V IOMMU driver.
> >
> > Refactor the logic for building this logical device ID into a standalone
> > helper function and export the interface for wider use.
> >
> > Signed-off-by: Easwar Hariharan <easwar.hariharan@linux.microsoft.com>
> > Signed-off-by: Yu Zhang <zhangyu1@linux.microsoft.com>
>
> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
>
> > ---
> > drivers/pci/controller/pci-hyperv.c | 28 ++++++++++++++++++++--------
> > include/asm-generic/mshyperv.h | 2 ++
> > 2 files changed, 22 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c
> > index 146b43981b27..4b82e06b5d93 100644
> > --- a/drivers/pci/controller/pci-hyperv.c
> > +++ b/drivers/pci/controller/pci-hyperv.c
> > @@ -598,15 +598,31 @@ static unsigned int hv_msi_get_int_vector(struct irq_data *data)
> >
> > #define hv_msi_prepare pci_msi_prepare
> >
> > +/**
> > + * Build a "Device Logical ID" out of this PCI bus's instance GUID and the
> > + * function number of the device.
> > + */
> > +u64 hv_build_logical_dev_id(struct pci_dev *pdev)
> > +{
> > + struct pci_bus *pbus = pdev->bus;
> > + struct hv_pcibus_device *hbus = container_of(pbus->sysdata,
> > + struct hv_pcibus_device, sysdata);
> > +
> > + return (u64)((hbus->hdev->dev_instance.b[5] << 24) |
> > + (hbus->hdev->dev_instance.b[4] << 16) |
> > + (hbus->hdev->dev_instance.b[7] << 8) |
> > + (hbus->hdev->dev_instance.b[6] & 0xf8) |
> > + PCI_FUNC(pdev->devfn));
> > +}
> > +EXPORT_SYMBOL_GPL(hv_build_logical_dev_id);
> > +
> > /**
> > * hv_irq_retarget_interrupt() - "Unmask" the IRQ by setting its current
> > * affinity.
> > * @data: Describes the IRQ
> > *
> > * Build new a destination for the MSI and make a hypercall to
> > - * update the Interrupt Redirection Table. "Device Logical ID"
> > - * is built out of this PCI bus's instance GUID and the function
> > - * number of the device.
> > + * update the Interrupt Redirection Table.
> > */
> > static void hv_irq_retarget_interrupt(struct irq_data *data)
> > {
> > @@ -642,11 +658,7 @@ static void hv_irq_retarget_interrupt(struct irq_data *data)
> > params->int_entry.source = HV_INTERRUPT_SOURCE_MSI;
> > params->int_entry.msi_entry.address.as_uint32 = int_desc->address & 0xffffffff;
> > params->int_entry.msi_entry.data.as_uint32 = int_desc->data;
> > - params->device_id = (hbus->hdev->dev_instance.b[5] << 24) |
> > - (hbus->hdev->dev_instance.b[4] << 16) |
> > - (hbus->hdev->dev_instance.b[7] << 8) |
> > - (hbus->hdev->dev_instance.b[6] & 0xf8) |
> > - PCI_FUNC(pdev->devfn);
> > + params->device_id = hv_build_logical_dev_id(pdev);
> > params->int_target.vector = hv_msi_get_int_vector(data);
> >
> > if (hbus->protocol_version >= PCI_PROTOCOL_VERSION_1_2) {
> > diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyperv.h
> > index 64ba6bc807d9..1a205ed69435 100644
> > --- a/include/asm-generic/mshyperv.h
> > +++ b/include/asm-generic/mshyperv.h
> > @@ -71,6 +71,8 @@ extern enum hv_partition_type hv_curr_partition_type;
> > extern void * __percpu *hyperv_pcpu_input_arg;
> > extern void * __percpu *hyperv_pcpu_output_arg;
> >
> > +extern u64 hv_build_logical_dev_id(struct pci_dev *pdev);
>
> Curious why you would include the "extern" in this declaration? It's
> not *wrong*, but it's not necessary, and other declarations in this
> file omit it, e.g., the ones below:
>
Thank you, Bjorn.
Actually I don't think it is necessary. Will remove it in v2. :)
B.R.
Yu
^ permalink raw reply
* Re: [RFC v1 5/5] iommu/hyperv: Add para-virtualized IOMMU support for Hyper-V guest
From: Yu Zhang @ 2025-12-11 8:41 UTC (permalink / raw)
To: Easwar Hariharan
Cc: linux-kernel, linux-hyperv, iommu, linux-pci, kys, haiyangz,
wei.liu, decui, lpieralisi, kwilczynski, mani, robh, bhelgaas,
arnd, joro, will, robin.murphy, jacob.pan, nunodasneves, mrathor,
mhklinux, peterz, linux-arch
In-Reply-To: <0c34e66f-7766-4b4f-a04d-77dbc330f1fe@linux.microsoft.com>
On Wed, Dec 10, 2025 at 09:15:18AM -0800, Easwar Hariharan wrote:
> On 12/8/2025 9:11 PM, Yu Zhang wrote:
> > Add a para-virtualized IOMMU driver for Linux guests running on Hyper-V.
> > This driver implements stage-1 IO translation within the guest OS.
> > It integrates with the Linux IOMMU core, utilizing Hyper-V hypercalls
> > for:
> > - Capability discovery
> > - Domain allocation, configuration, and deallocation
> > - Device attachment and detachment
> > - IOTLB invalidation
> >
> > The driver constructs x86-compatible stage-1 IO page tables in the
> > guest memory using consolidated IO page table helpers. This allows
> > the guest to manage stage-1 translations independently of vendor-
> > specific drivers (like Intel VT-d or AMD IOMMU).
> >
> > Hyper-v consumes this stage-1 IO page table, when a device domain is
> > created and configured, and nests it with the host's stage-2 IO page
> > tables, therefore elemenating the VM exits for guest IOMMU mapping
> > operations.
> >
> > For guest IOMMU unmapping operations, VM exits to perform the IOTLB
> > flush(and possibly the device TLB flush) is still unavoidable. For
> > now, HVCALL_FLUSH_DEVICE_DOMAIN is used to implement a domain-selective
> > IOTLB flush. New hypercalls for finer-grained hypercall will be provided
> > in future patches.
> >
> > Co-developed-by: Wei Liu <wei.liu@kernel.org>
> > Signed-off-by: Wei Liu <wei.liu@kernel.org>
> > Co-developed-by: Jacob Pan <jacob.pan@linux.microsoft.com>
> > Signed-off-by: Jacob Pan <jacob.pan@linux.microsoft.com>
> > Co-developed-by: Easwar Hariharan <easwar.hariharan@linux.microsoft.com>
> > Signed-off-by: Easwar Hariharan <easwar.hariharan@linux.microsoft.com>
> > Signed-off-by: Yu Zhang <zhangyu1@linux.microsoft.com>
> > ---
> > drivers/iommu/hyperv/Kconfig | 14 +
> > drivers/iommu/hyperv/Makefile | 1 +
> > drivers/iommu/hyperv/iommu.c | 608 ++++++++++++++++++++++++++++++++++
> > drivers/iommu/hyperv/iommu.h | 53 +++
> > 4 files changed, 676 insertions(+)
> > create mode 100644 drivers/iommu/hyperv/iommu.c
> > create mode 100644 drivers/iommu/hyperv/iommu.h
> >
>
> <snip>
>
> > +
> > +static int __init hv_iommu_init(void)
> > +{
> > + int ret = 0;
> > + struct hv_iommu_dev *hv_iommu = NULL;
> > + struct hv_output_get_iommu_capabilities hv_iommu_cap = {0};
> > +
> > + if (no_iommu || iommu_detected)
> > + return -ENODEV;
> > +
> > + if (!hv_is_hyperv_initialized())
> > + return -ENODEV;
> > +
> > + if (hv_iommu_detect(&hv_iommu_cap) ||
> > + !hv_iommu_present(hv_iommu_cap.iommu_cap) ||
> > + !hv_iommu_s1_domain_supported(hv_iommu_cap.iommu_cap))
> > + return -ENODEV;
> > +
> > + iommu_detected = 1;
> > + pci_request_acs();
> > +
> > + hv_iommu = kzalloc(sizeof(*hv_iommu), GFP_KERNEL);
> > + if (!hv_iommu)
> > + return -ENOMEM;
> > +
> > + hv_init_iommu_device(hv_iommu, &hv_iommu_cap);
> > +
> > + ret = hv_initialize_static_domains();
> > + if (ret) {
> > + pr_err("hv_initialize_static_domains failed: %d\n", ret);
> > + goto err_sysfs_remove;
>
> This should be goto err_free since we haven't done the sysfs_add yet
>
> > + }
> > +
> > + ret = iommu_device_sysfs_add(&hv_iommu->iommu, NULL, NULL, "%s", "hv-iommu");
> > + if (ret) {
> > + pr_err("iommu_device_sysfs_add failed: %d\n", ret);
> > + goto err_free;
>
> And this should be probably a goto delete_static_domains that cleans up the allocated static
> domains...
>
Nice catch. And thanks! :)
Yu
^ permalink raw reply
* RE: [PATCH v7 4/7] Drivers: hv: Fix huge page handling in memory region traversal
From: Michael Kelley @ 2025-12-11 17:37 UTC (permalink / raw)
To: Stanislav Kinsburskii
Cc: kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org,
decui@microsoft.com, linux-hyperv@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <aTH4T-FKcL1knHaD@skinsburskii.localdomain>
From: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com> Sent: Thursday, December 4, 2025 1:09 PM
>
> On Thu, Dec 04, 2025 at 04:03:26PM +0000, Michael Kelley wrote:
> > From: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com> Sent: Tuesday, November 25, 2025 6:09 PM
> > >
[snip]
> > > +static long mshv_region_process_chunk(struct mshv_mem_region *region,
> > > + u32 flags,
> > > + u64 page_offset, u64 page_count,
> > > + int (*handler)(struct mshv_mem_region *region,
> > > + u32 flags,
> > > + u64 page_offset,
> > > + u64 page_count))
> > > +{
> > > + u64 count, stride;
> > > + unsigned int page_order;
> > > + struct page *page;
> > > + int ret;
> > > +
> > > + page = region->pages[page_offset];
> > > + if (!page)
> > > + return -EINVAL;
> > > +
> > > + page_order = folio_order(page_folio(page));
> > > + /* 1G huge pages aren't supported by the hypercalls */
> > > + if (page_order == PUD_ORDER)
> > > + return -EINVAL;
> >
> > In the general case, folio_order() could return a variety of values ranging from
> > 0 up to at least PUD_ORDER. For example, "2" would be valid value in file
> > system code that uses folios to do I/O in 16K blocks instead of just 4K blocks.
> > Since this function is trying to find contiguous chunks of either single pages
> > or 2M huge pages, I think you are expecting only three possible values: 0,
> > PMD_ORDER, or PUD_ORDER. But do you know that "2" (for example)
> > would never be returned? The memory involved here is populated using
> > pin_user_pages_fast() for the pinned case, or using hmm_range_fault() for
> > the movable case. I don't know mm behavior well enough to know if those
> > functions could ever populate with a folio with an order other than 0 or
> > PMD_ORDER. If such a folio could ever be used, then the way you check
> > for a page size change won't be valid. For purposes of informing Hyper-V
> > about 2 Meg pages, folio orders 0 through 8 are all equivalent, with folio
> > order 9 (PMD_ORDER) being the marker for the start of 2 Meg large page.
> >
> > Somebody who knows mm behavior better than I do should comment. Or
> > maybe you could just be more defensive and handle the case of folio orders
> > not equal to 0 or PMD_ORDER.
> >
>
> Thanks for the comment.
> This is addressed this in v9 by expclitly checking for 0 and HUGE_PMD_ORDER.
>
> > > +
> > > + stride = 1 << page_order;
> > > +
> > > + /* Start at stride since the first page is validated */
> > > + for (count = stride; count < page_count; count += stride) {
> >
> > This striding doesn't work properly in the general case. Suppose the
> > page_offset value puts the start of the chunk in the middle of a 2 Meg
> > page, and that 2 Meg page is then followed by a bunch of single pages.
> > (Presumably the mmu notifier "invalidate" callback could do this.)
> > The use of the full stride here jumps over the remaining portion of the
> > 2 Meg page plus some number of the single pages, which isn't what you
> > want. For the striding to work, it must figure out how much remains in the
> > initial large page, and then once the striding is aligned to the large page
> > boundaries, the full stride length works.
> >
> > Also, what do the hypercalls in the handler functions do if a chunk starts
> > in the middle of a 2 Meg page? It looks like the handler functions will set
> > the *_LARGE_PAGE flag to the hypercall but then the hv_call_* function
> > will fail if the page_count isn't 2 Meg aligned.
> >
>
> This situation you described is not possible, because invalidation
> callback simply can't invalidate a part of the huge page even in THP
> case (leave aside hugetlb case) without splitting it beforehand, and
> splitting a huge page requires invalidation of the whole huge page
> first.
I've been playing around with mmu notifiers and 2 Meg pages. At least in my
experiment, there's a case where the .invalidate callback is invoked on a
range *before* the 2 Meg page is split. The kernel code that does this is
in zap_page_range_single_batched(). Early on this function calls
mmu_notifier_invalidate_range_start(), which invokes the .invalidate
callback on the initial range. Later on, unmap_single_vma() is called, which
does the split and eventually makes a second .invalidate callback for the
entire 2 Meg page.
Details: My experiment is a user space program that does the following:
1. Allocates 16 Megs of memory on a 16 Meg boundary using
posix_memalign(). So this is private anonymous memory. Transparent
huge pages are enabled.
2. Writes to a byte in each 4K page so they are all populated.
/proc/meminfo shows eight 2 Meg pages have been allocated.
3. Creates an mmu notifier for the allocated 16 Megs, using an ioctl
hacked into the kernel for experimentation purposes.
4. Uses madvise() with the DONTNEED option to free 32 Kbytes on a 4K
page boundary somewhere in the 16 Meg allocation. This results in an mmu
notifier invalidate callback for that 32 Kbytes. Then there's a second invalidate
callback covering the entire 2 Meg page that contains the 32 Kbyte range.
Kernel stack traces for the two invalidate callbacks show them originating
in zap_page_range_single_batched().
5. Sleeps for 60 seconds. During that time, khugepaged wakes up and does
hpage_collapse_scan_pmd() -> collapse_huge_page(), which generates a third
.invalidate callback for the 2 Meg page. I'm haven't investigated what this is
all about.
6. Interestingly, if Step 4 above does a slightly different operation using
mprotect() with PROT_READ instead of madvise(), the 2 Meg page is split first.
The .invalidate callback for the full 2 Meg happens before the .invalidate
callback for the specified range.
The root partition probably isn't doing madvise() with DONTNEED for memory
allocated for guests. But regardless of what user space does or doesn't do, MSHV's
invalidate callback path should be made safe for this case. Maybe that's just
detecting it and returning an error (and maybe a WARN_ON) if user space
doesn't need it to work.
Michael
>
> > > + page = region->pages[page_offset + count];
> > > +
> > > + /* Break if current page is not present */
> > > + if (!page)
> > > + break;
> > > +
> > > + /* Break if page size changes */
> > > + if (page_order != folio_order(page_folio(page)))
> > > + break;
> > > + }
> > > +
> > > + ret = handler(region, flags, page_offset, count);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + return count;
> > > +}
> > > +
> > > +/**
> > > + * mshv_region_process_range - Processes a range of memory pages in a
> > > + * region.
> > > + * @region : Pointer to the memory region structure.
> > > + * @flags : Flags to pass to the handler.
> > > + * @page_offset: Offset into the region's pages array to start processing.
> > > + * @page_count : Number of pages to process.
> > > + * @handler : Callback function to handle each chunk of contiguous
> > > + * pages.
> > > + *
> > > + * Iterates over the specified range of pages in @region, skipping
> > > + * non-present pages. For each contiguous chunk of present pages, invokes
> > > + * @handler via mshv_region_process_chunk.
> > > + *
> > > + * Note: The @handler callback must be able to handle both normal and huge
> > > + * pages.
> > > + *
> > > + * Returns 0 on success, or a negative error code on failure.
> > > + */
> > > +static int mshv_region_process_range(struct mshv_mem_region *region,
> > > + u32 flags,
> > > + u64 page_offset, u64 page_count,
> > > + int (*handler)(struct mshv_mem_region *region,
> > > + u32 flags,
> > > + u64 page_offset,
> > > + u64 page_count))
> > > +{
> > > + long ret;
> > > +
> > > + if (page_offset + page_count > region->nr_pages)
> > > + return -EINVAL;
> > > +
> > > + while (page_count) {
> > > + /* Skip non-present pages */
> > > + if (!region->pages[page_offset]) {
> > > + page_offset++;
> > > + page_count--;
> > > + continue;
> > > + }
> > > +
> > > + ret = mshv_region_process_chunk(region, flags,
> > > + page_offset,
> > > + page_count,
> > > + handler);
> > > + if (ret < 0)
> > > + return ret;
> > > +
> > > + page_offset += ret;
> > > + page_count -= ret;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > > struct mshv_mem_region *mshv_region_create(u64 guest_pfn, u64 nr_pages,
> > > u64 uaddr, u32 flags,
> > > bool is_mmio)
> > > @@ -33,55 +151,80 @@ struct mshv_mem_region *mshv_region_create(u64
> guest_pfn, u64 nr_pages,
> > > if (flags & BIT(MSHV_SET_MEM_BIT_EXECUTABLE))
> > > region->hv_map_flags |= HV_MAP_GPA_EXECUTABLE;
> > >
> > > - /* Note: large_pages flag populated when we pin the pages */
> > > if (!is_mmio)
> > > region->flags.range_pinned = true;
> > >
> > > return region;
> > > }
> > >
> > > +static int mshv_region_chunk_share(struct mshv_mem_region *region,
> > > + u32 flags,
> > > + u64 page_offset, u64 page_count)
> > > +{
> > > + if (PageTransCompound(region->pages[page_offset]))
> > > + flags |= HV_MODIFY_SPA_PAGE_HOST_ACCESS_LARGE_PAGE;
> >
> > mshv_region_process_chunk() uses folio_size() to detect single pages vs. 2 Meg
> > large pages. Here you are using PageTransCompound(). Any reason for the
> > difference? This may be perfectly OK, but my knowledge of mm is too limited to
> > know for sure. Looking at the implementations of folio_size() and
> > PageTransCompound(), they seem to be looking at different fields in the struct page,
> > and I don't know if the different fields are always in sync. Another case for someone
> > with mm expertise to review carefully ....
> >
>
> Indeed, folio_order could be used here as well PageTransCompound could
> be used in the chunk processing function (but then the size of the page
> would still needed to be checked).
> On the other hand, there is subtle difference between the chunk
> procesing function and the callback in calls: the latter doesn't
> validate the input, thus the chunk processing function should.
>
> Thanks,
> Stanislav
>
> > Michael
> >
> > > +
> > > + return hv_call_modify_spa_host_access(region->partition->pt_id,
> > > + region->pages + page_offset,
> > > + page_count,
> > > + HV_MAP_GPA_READABLE |
> > > + HV_MAP_GPA_WRITABLE,
> > > + flags, true);
> > > +}
> > > +
> > > int mshv_region_share(struct mshv_mem_region *region)
> > > {
> > > u32 flags = HV_MODIFY_SPA_PAGE_HOST_ACCESS_MAKE_SHARED;
> > >
> > > - if (region->flags.large_pages)
> > > + return mshv_region_process_range(region, flags,
> > > + 0, region->nr_pages,
> > > + mshv_region_chunk_share);
> > > +}
> > > +
> > > +static int mshv_region_chunk_unshare(struct mshv_mem_region *region,
> > > + u32 flags,
> > > + u64 page_offset, u64 page_count)
> > > +{
> > > + if (PageTransCompound(region->pages[page_offset]))
> > > flags |= HV_MODIFY_SPA_PAGE_HOST_ACCESS_LARGE_PAGE;
> > >
> > > return hv_call_modify_spa_host_access(region->partition->pt_id,
> > > - region->pages, region->nr_pages,
> > > - HV_MAP_GPA_READABLE | HV_MAP_GPA_WRITABLE,
> > > - flags, true);
> > > + region->pages + page_offset,
> > > + page_count, 0,
> > > + flags, false);
> > > }
> > >
> > > int mshv_region_unshare(struct mshv_mem_region *region)
> > > {
> > > u32 flags = HV_MODIFY_SPA_PAGE_HOST_ACCESS_MAKE_EXCLUSIVE;
> > >
> > > - if (region->flags.large_pages)
> > > - flags |= HV_MODIFY_SPA_PAGE_HOST_ACCESS_LARGE_PAGE;
> > > -
> > > - return hv_call_modify_spa_host_access(region->partition->pt_id,
> > > - region->pages, region->nr_pages,
> > > - 0,
> > > - flags, false);
> > > + return mshv_region_process_range(region, flags,
> > > + 0, region->nr_pages,
> > > + mshv_region_chunk_unshare);
> > > }
> > >
> > > -static int mshv_region_remap_pages(struct mshv_mem_region *region,
> > > - u32 map_flags,
> > > +static int mshv_region_chunk_remap(struct mshv_mem_region *region,
> > > + u32 flags,
> > > u64 page_offset, u64 page_count)
> > > {
> > > - if (page_offset + page_count > region->nr_pages)
> > > - return -EINVAL;
> > > -
> > > - if (region->flags.large_pages)
> > > - map_flags |= HV_MAP_GPA_LARGE_PAGE;
> > > + if (PageTransCompound(region->pages[page_offset]))
> > > + flags |= HV_MAP_GPA_LARGE_PAGE;
> > >
> > > return hv_call_map_gpa_pages(region->partition->pt_id,
> > > region->start_gfn + page_offset,
> > > - page_count, map_flags,
> > > + page_count, flags,
> > > region->pages + page_offset);
> > > }
> > >
> > > +static int mshv_region_remap_pages(struct mshv_mem_region *region,
> > > + u32 map_flags,
> > > + u64 page_offset, u64 page_count)
> > > +{
> > > + return mshv_region_process_range(region, map_flags,
> > > + page_offset, page_count,
> > > + mshv_region_chunk_remap);
> > > +}
> > > +
> > > int mshv_region_map(struct mshv_mem_region *region)
> > > {
> > > u32 map_flags = region->hv_map_flags;
> > > @@ -134,9 +277,6 @@ int mshv_region_pin(struct mshv_mem_region *region)
> > > goto release_pages;
> > > }
> > >
> > > - if (PageHuge(region->pages[0]))
> > > - region->flags.large_pages = true;
> > > -
> > > return 0;
> > >
> > > release_pages:
> > > @@ -144,10 +284,28 @@ int mshv_region_pin(struct mshv_mem_region *region)
> > > return ret;
> > > }
> > >
> > > +static int mshv_region_chunk_unmap(struct mshv_mem_region *region,
> > > + u32 flags,
> > > + u64 page_offset, u64 page_count)
> > > +{
> > > + if (PageTransCompound(region->pages[page_offset]))
> > > + flags |= HV_UNMAP_GPA_LARGE_PAGE;
> > > +
> > > + return hv_call_unmap_gpa_pages(region->partition->pt_id,
> > > + region->start_gfn + page_offset,
> > > + page_count, 0);
> > > +}
> > > +
> > > +static int mshv_region_unmap(struct mshv_mem_region *region)
> > > +{
> > > + return mshv_region_process_range(region, 0,
> > > + 0, region->nr_pages,
> > > + mshv_region_chunk_unmap);
> > > +}
> > > +
> > > void mshv_region_destroy(struct mshv_mem_region *region)
> > > {
> > > struct mshv_partition *partition = region->partition;
> > > - u32 unmap_flags = 0;
> > > int ret;
> > >
> > > hlist_del(®ion->hnode);
> > > @@ -162,12 +320,7 @@ void mshv_region_destroy(struct mshv_mem_region
> *region)
> > > }
> > > }
> > >
> > > - if (region->flags.large_pages)
> > > - unmap_flags |= HV_UNMAP_GPA_LARGE_PAGE;
> > > -
> > > - /* ignore unmap failures and continue as process may be exiting */
> > > - hv_call_unmap_gpa_pages(partition->pt_id, region->start_gfn,
> > > - region->nr_pages, unmap_flags);
> > > + mshv_region_unmap(region);
> > >
> > > mshv_region_invalidate(region);
> > >
> > > diff --git a/drivers/hv/mshv_root.h b/drivers/hv/mshv_root.h
> > > index 0366f416c2f0..ff3374f13691 100644
> > > --- a/drivers/hv/mshv_root.h
> > > +++ b/drivers/hv/mshv_root.h
> > > @@ -77,9 +77,8 @@ struct mshv_mem_region {
> > > u64 start_uaddr;
> > > u32 hv_map_flags;
> > > struct {
> > > - u64 large_pages: 1; /* 2MiB */
> > > u64 range_pinned: 1;
> > > - u64 reserved: 62;
> > > + u64 reserved: 63;
> > > } flags;
> > > struct mshv_partition *partition;
> > > struct page *pages[];
> > >
> > >
> >
^ permalink raw reply
* [PATCH][next] hyperv: Avoid -Wflex-array-member-not-at-end warning
From: Gustavo A. R. Silva @ 2025-12-12 6:44 UTC (permalink / raw)
To: K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li
Cc: linux-hyperv, linux-kernel, Gustavo A. R. Silva, linux-hardening
-Wflex-array-member-not-at-end was introduced in GCC-14, and we are
getting ready to enable it, globally.
Use the new __TRAILING_OVERLAP() helper to fix the following warning:
include/hyperv/hvgdk_mini.h:581:25: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
This helper creates a union between a flexible-array member (FAM) and a
set of MEMBERS that would otherwise follow it.
This overlays the trailing MEMBER u64 gva_list[]; onto the FAM
struct hv_tlb_flush_ex::hv_vp_set.bank_contents[], while keeping
the FAM and the start of MEMBER aligned.
The static_assert() ensures this alignment remains, and it's
intentionally placed inmediately after the related structure --no
blank line in between.
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
include/hyperv/hvgdk_mini.h | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/include/hyperv/hvgdk_mini.h b/include/hyperv/hvgdk_mini.h
index 04b18d0e37af..30fbbde81c5c 100644
--- a/include/hyperv/hvgdk_mini.h
+++ b/include/hyperv/hvgdk_mini.h
@@ -578,9 +578,12 @@ struct hv_tlb_flush { /* HV_INPUT_FLUSH_VIRTUAL_ADDRESS_LIST */
struct hv_tlb_flush_ex {
u64 address_space;
u64 flags;
- struct hv_vpset hv_vp_set;
- u64 gva_list[];
+ __TRAILING_OVERLAP(struct hv_vpset, hv_vp_set, bank_contents, __packed,
+ u64 gva_list[];
+ );
} __packed;
+static_assert(offsetof(struct hv_tlb_flush_ex, hv_vp_set.bank_contents) ==
+ offsetof(struct hv_tlb_flush_ex, gva_list));
struct ms_hyperv_tsc_page { /* HV_REFERENCE_TSC_PAGE */
volatile u32 tsc_sequence;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net-next v12 04/12] vsock: add netns support to virtio transports
From: Bobby Eshleman @ 2025-12-12 15:26 UTC (permalink / raw)
To: Paolo Abeni
Cc: Stefano Garzarella, David S. Miller, Eric Dumazet, Jakub Kicinski,
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, linux-kernel,
virtualization, netdev, kvm, linux-hyperv, linux-kselftest,
berrange, Sargun Dhillon, Bobby Eshleman
In-Reply-To: <aS9hoOKb7yA5Qgod@devvm11784.nha0.facebook.com>
On Tue, Dec 02, 2025 at 02:01:04PM -0800, Bobby Eshleman wrote:
> On Tue, Dec 02, 2025 at 09:47:19PM +0100, Paolo Abeni wrote:
> > On 12/2/25 6:56 PM, Bobby Eshleman wrote:
> > > On Tue, Dec 02, 2025 at 11:18:14AM +0100, Paolo Abeni wrote:
> > >> On 11/27/25 8:47 AM, Bobby Eshleman wrote:
> > >>> @@ -674,6 +689,17 @@ static int vhost_vsock_dev_open(struct inode *inode, struct file *file)
> > >>> goto out;
> > >>> }
> > >>>
> > >>> + net = current->nsproxy->net_ns;
> > >>> + vsock->net = get_net_track(net, &vsock->ns_tracker, GFP_KERNEL);
> > >>> +
> > >>> + /* Store the mode of the namespace at the time of creation. If this
> > >>> + * namespace later changes from "global" to "local", we want this vsock
> > >>> + * to continue operating normally and not suddenly break. For that
> > >>> + * reason, we save the mode here and later use it when performing
> > >>> + * socket lookups with vsock_net_check_mode() (see vhost_vsock_get()).
> > >>> + */
> > >>> + vsock->net_mode = vsock_net_mode(net);
> > >>
> > >> I'm sorry for the very late feedback. I think that at very least the
> > >> user-space needs a way to query if the given transport is in local or
> > >> global mode, as AFAICS there is no way to tell that when socket creation
> > >> races with mode change.
> > >
> > > Are you thinking something along the lines of sockopt?
> >
> > I'd like to see a way for the user-space to query the socket 'namespace
> > mode'.
> >
> > sockopt could be an option; a possibly better one could be sock_diag. Or
> > you could do both using dumping the info with a shared helper invoked by
> > both code paths, alike what TCP is doing.
> > >> Also I'm a bit uneasy with the model implemented here, as 'local' socket
> > >> may cross netns boundaris and connect to 'local' socket in other netns
> > >> (if I read correctly patch 2/12). That in turns AFAICS break the netns
> > >> isolation.
> > >
> > > Local mode sockets are unable to communicate with local mode (and global
> > > mode too) sockets that are in other namespaces. The key piece of code
> > > for that is vsock_net_check_mode(), where if either modes is local the
> > > namespaces must be the same.
> >
> > Sorry, I likely misread the large comment in patch 2:
> >
> > https://lore.kernel.org/netdev/20251126-vsock-vmtest-v12-2-257ee21cd5de@meta.com/
> >
> > >> Have you considered instead a slightly different model, where the
> > >> local/global model is set in stone at netns creation time - alike what
> > >> /proc/sys/net/ipv4/tcp_child_ehash_entries is doing[1] - and
> > >> inter-netns connectivity is explicitly granted by the admin (I guess
> > >> you will need new transport operations for that)?
> > >>
> > >> /P
> > >>
> > >> [1] tcp allows using per-netns established socket lookup tables - as
> > >> opposed to the default global lookup table (even if match always takes
> > >> in account the netns obviously). The mentioned sysctl specify such
> > >> configuration for the children namespaces, if any.
> > >
> > > I'll save this discussion if the above doesn't resolve your concerns.
> > I still have some concern WRT the dynamic mode change after netns
> > creation. I fear some 'unsolvable' (or very hard to solve) race I can't
> > see now. A tcp_child_ehash_entries-like model will avoid completely the
> > issue, but I understand it would be a significant change over the
> > current status.
> >
> > "Luckily" the merge window is on us and we have some time to discuss. Do
> > you have a specific use-case for the ability to change the netns mode
> > after creation?
> >
> > /P
>
> I don't think there is a hard requirement that the mode be change-able
> after creation. Though I'd love to avoid such a big change... or at
> least leave unchanged as much of what we've already reviewed as
> possible.
>
> In the scheme of defining the mode at creation and following the
> tcp_child_ehash_entries-ish model, what I'm imagining is:
> - /proc/sys/net/vsock/child_ns_mode can be set to "local" or "global"
> - /proc/sys/net/vsock/child_ns_mode is not immutable, can change any
> number of times
>
> - when a netns is created, the new netns mode is inherited from
> child_ns_mode, being assigned using something like:
>
> net->vsock.ns_mode =
> get_net_ns_by_pid(current->pid)->child_ns_mode
>
> - /proc/sys/net/vsock/ns_mode queries the current mode, returning
> "local" or "global", returning value of net->vsock.ns_mode
> - /proc/sys/net/vsock/ns_mode and net->vsock.ns_mode are immutable and
> reject writes
>
> Does that align with what you have in mind?
Hey Paolo, I just wanted to sync up on this one. Does the above align
with what you envision?
Best,
Bobby
^ permalink raw reply
* Re: [PATCH v4 00/21] paravirt: cleanup and reorg
From: Juergen Gross @ 2025-12-15 8:27 UTC (permalink / raw)
To: linux-kernel, x86, linux-hyperv, virtualization, loongarch,
linuxppc-dev, linux-riscv, kvm
Cc: Andy Lutomirski, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H. Peter Anvin, K. Y. Srinivasan, Haiyang Zhang,
Wei Liu, Dexuan Cui, Peter Zijlstra, Will Deacon, Boqun Feng,
Waiman Long, Jiri Kosina, Josh Poimboeuf, Pawan Gupta,
Boris Ostrovsky, xen-devel, Ajay Kaher, Alexey Makhalov,
Broadcom internal kernel review list, Russell King,
Catalin Marinas, Huacai Chen, WANG Xuerui, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Juri Lelli, Vincent Guittot, Dietmar Eggemann, Steven Rostedt,
Ben Segall, Mel Gorman, Valentin Schneider, linux-arm-kernel,
Paolo Bonzini, Vitaly Kuznetsov, Stefano Stabellini,
Oleksandr Tyshchenko, Daniel Lezcano, Oleg Nesterov
In-Reply-To: <20251127070844.21919-1-jgross@suse.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 7796 bytes --]
At least for patches 1-12: Ping?
Would be nice to have some feedback for 13-21, too (patch 21 needs an
update, though).
Juergen
On 27.11.25 08:08, Juergen Gross wrote:
> Some cleanups and reorg of paravirt code and headers:
>
> - The first 2 patches should be not controversial at all, as they
> remove just some no longer needed #include and struct forward
> declarations.
>
> - The 3rd patch is removing CONFIG_PARAVIRT_DEBUG, which IMO has
> no real value, as it just changes a crash to a BUG() (the stack
> trace will basically be the same). As the maintainer of the main
> paravirt user (Xen) I have never seen this crash/BUG() to happen.
>
> - The 4th patch is just a movement of code.
>
> - I don't know for what reason asm/paravirt_api_clock.h was added,
> as all archs supporting it do it exactly in the same way. Patch
> 5 is removing it.
>
> - Patches 6-14 are streamlining the paravirt clock interfaces by
> using a common implementation across architectures where possible
> and by moving the related code into common sched code, as this is
> where it should live.
>
> - Patches 15-20 are more like RFC material preparing the paravirt
> infrastructure to support multiple pv_ops function arrays.
> As a prerequisite for that it makes life in objtool much easier
> with dropping the Xen static initializers of the pv_ops sub-
> structures, which is done in patches 15-17.
> Patches 18-20 are doing the real preparations for multiple pv_ops
> arrays and using those arrays in multiple headers.
>
> - Patch 21 is an example how the new scheme can look like using the
> PV-spinlocks.
>
> Changes in V2:
> - new patches 13-18 and 20
> - complete rework of patch 21
>
> Changes in V3:
> - fixed 2 issues detected by kernel test robot
>
> Changes in V4:
> - fixed one build issue
>
> Juergen Gross (21):
> x86/paravirt: Remove not needed includes of paravirt.h
> x86/paravirt: Remove some unneeded struct declarations
> x86/paravirt: Remove PARAVIRT_DEBUG config option
> x86/paravirt: Move thunk macros to paravirt_types.h
> paravirt: Remove asm/paravirt_api_clock.h
> sched: Move clock related paravirt code to kernel/sched
> arm/paravirt: Use common code for paravirt_steal_clock()
> arm64/paravirt: Use common code for paravirt_steal_clock()
> loongarch/paravirt: Use common code for paravirt_steal_clock()
> riscv/paravirt: Use common code for paravirt_steal_clock()
> x86/paravirt: Use common code for paravirt_steal_clock()
> x86/paravirt: Move paravirt_sched_clock() related code into tsc.c
> x86/paravirt: Introduce new paravirt-base.h header
> x86/paravirt: Move pv_native_*() prototypes to paravirt.c
> x86/xen: Drop xen_irq_ops
> x86/xen: Drop xen_cpu_ops
> x86/xen: Drop xen_mmu_ops
> objtool: Allow multiple pv_ops arrays
> x86/paravirt: Allow pv-calls outside paravirt.h
> x86/paravirt: Specify pv_ops array in paravirt macros
> x86/pvlocks: Move paravirt spinlock functions into own header
>
> arch/Kconfig | 3 +
> arch/arm/Kconfig | 1 +
> arch/arm/include/asm/paravirt.h | 22 --
> arch/arm/include/asm/paravirt_api_clock.h | 1 -
> arch/arm/kernel/Makefile | 1 -
> arch/arm/kernel/paravirt.c | 23 --
> arch/arm64/Kconfig | 1 +
> arch/arm64/include/asm/paravirt.h | 14 -
> arch/arm64/include/asm/paravirt_api_clock.h | 1 -
> arch/arm64/kernel/paravirt.c | 11 +-
> arch/loongarch/Kconfig | 1 +
> arch/loongarch/include/asm/paravirt.h | 13 -
> .../include/asm/paravirt_api_clock.h | 1 -
> arch/loongarch/kernel/paravirt.c | 10 +-
> arch/powerpc/include/asm/paravirt.h | 3 -
> arch/powerpc/include/asm/paravirt_api_clock.h | 2 -
> arch/powerpc/platforms/pseries/setup.c | 4 +-
> arch/riscv/Kconfig | 1 +
> arch/riscv/include/asm/paravirt.h | 14 -
> arch/riscv/include/asm/paravirt_api_clock.h | 1 -
> arch/riscv/kernel/paravirt.c | 11 +-
> arch/x86/Kconfig | 8 +-
> arch/x86/entry/entry_64.S | 1 -
> arch/x86/entry/vsyscall/vsyscall_64.c | 1 -
> arch/x86/hyperv/hv_spinlock.c | 11 +-
> arch/x86/include/asm/apic.h | 4 -
> arch/x86/include/asm/highmem.h | 1 -
> arch/x86/include/asm/mshyperv.h | 1 -
> arch/x86/include/asm/paravirt-base.h | 29 ++
> arch/x86/include/asm/paravirt-spinlock.h | 146 ++++++++
> arch/x86/include/asm/paravirt.h | 331 +++++-------------
> arch/x86/include/asm/paravirt_api_clock.h | 1 -
> arch/x86/include/asm/paravirt_types.h | 269 +++++++-------
> arch/x86/include/asm/pgtable_32.h | 1 -
> arch/x86/include/asm/ptrace.h | 2 +-
> arch/x86/include/asm/qspinlock.h | 89 +----
> arch/x86/include/asm/spinlock.h | 1 -
> arch/x86/include/asm/timer.h | 1 +
> arch/x86/include/asm/tlbflush.h | 4 -
> arch/x86/kernel/Makefile | 2 +-
> arch/x86/kernel/apm_32.c | 1 -
> arch/x86/kernel/callthunks.c | 1 -
> arch/x86/kernel/cpu/bugs.c | 1 -
> arch/x86/kernel/cpu/vmware.c | 1 +
> arch/x86/kernel/kvm.c | 13 +-
> arch/x86/kernel/kvmclock.c | 1 +
> arch/x86/kernel/paravirt-spinlocks.c | 26 +-
> arch/x86/kernel/paravirt.c | 42 +--
> arch/x86/kernel/tsc.c | 10 +-
> arch/x86/kernel/vsmp_64.c | 1 -
> arch/x86/lib/cache-smp.c | 1 -
> arch/x86/mm/init.c | 1 -
> arch/x86/xen/enlighten_pv.c | 82 ++---
> arch/x86/xen/irq.c | 20 +-
> arch/x86/xen/mmu_pv.c | 100 ++----
> arch/x86/xen/spinlock.c | 11 +-
> arch/x86/xen/time.c | 2 +
> drivers/clocksource/hyperv_timer.c | 2 +
> drivers/xen/time.c | 2 +-
> include/linux/sched/cputime.h | 18 +
> kernel/sched/core.c | 5 +
> kernel/sched/cputime.c | 13 +
> kernel/sched/sched.h | 3 +-
> tools/objtool/arch/x86/decode.c | 8 +-
> tools/objtool/check.c | 78 ++++-
> tools/objtool/include/objtool/check.h | 2 +
> 66 files changed, 661 insertions(+), 826 deletions(-)
> delete mode 100644 arch/arm/include/asm/paravirt.h
> delete mode 100644 arch/arm/include/asm/paravirt_api_clock.h
> delete mode 100644 arch/arm/kernel/paravirt.c
> delete mode 100644 arch/arm64/include/asm/paravirt_api_clock.h
> delete mode 100644 arch/loongarch/include/asm/paravirt_api_clock.h
> delete mode 100644 arch/powerpc/include/asm/paravirt_api_clock.h
> delete mode 100644 arch/riscv/include/asm/paravirt_api_clock.h
> create mode 100644 arch/x86/include/asm/paravirt-base.h
> create mode 100644 arch/x86/include/asm/paravirt-spinlock.h
> delete mode 100644 arch/x86/include/asm/paravirt_api_clock.h
>
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v12 04/12] vsock: add netns support to virtio transports
From: Stefano Garzarella @ 2025-12-15 14:11 UTC (permalink / raw)
To: Bobby Eshleman
Cc: Paolo Abeni, David S. Miller, Eric Dumazet, Jakub Kicinski,
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, linux-kernel,
virtualization, netdev, kvm, linux-hyperv, linux-kselftest,
berrange, Sargun Dhillon, Bobby Eshleman
In-Reply-To: <aTw0F6lufR/nT7OY@devvm11784.nha0.facebook.com>
On Fri, Dec 12, 2025 at 07:26:15AM -0800, Bobby Eshleman wrote:
>On Tue, Dec 02, 2025 at 02:01:04PM -0800, Bobby Eshleman wrote:
>> On Tue, Dec 02, 2025 at 09:47:19PM +0100, Paolo Abeni wrote:
>> > On 12/2/25 6:56 PM, Bobby Eshleman wrote:
>> > > On Tue, Dec 02, 2025 at 11:18:14AM +0100, Paolo Abeni wrote:
>> > >> On 11/27/25 8:47 AM, Bobby Eshleman wrote:
>> > >>> @@ -674,6 +689,17 @@ static int vhost_vsock_dev_open(struct inode *inode, struct file *file)
>> > >>> goto out;
>> > >>> }
>> > >>>
>> > >>> + net = current->nsproxy->net_ns;
>> > >>> + vsock->net = get_net_track(net, &vsock->ns_tracker, GFP_KERNEL);
>> > >>> +
>> > >>> + /* Store the mode of the namespace at the time of creation. If this
>> > >>> + * namespace later changes from "global" to "local", we want this vsock
>> > >>> + * to continue operating normally and not suddenly break. For that
>> > >>> + * reason, we save the mode here and later use it when performing
>> > >>> + * socket lookups with vsock_net_check_mode() (see vhost_vsock_get()).
>> > >>> + */
>> > >>> + vsock->net_mode = vsock_net_mode(net);
>> > >>
>> > >> I'm sorry for the very late feedback. I think that at very least the
>> > >> user-space needs a way to query if the given transport is in local or
>> > >> global mode, as AFAICS there is no way to tell that when socket creation
>> > >> races with mode change.
>> > >
>> > > Are you thinking something along the lines of sockopt?
>> >
>> > I'd like to see a way for the user-space to query the socket 'namespace
>> > mode'.
>> >
>> > sockopt could be an option; a possibly better one could be sock_diag. Or
>> > you could do both using dumping the info with a shared helper invoked by
>> > both code paths, alike what TCP is doing.
>> > >> Also I'm a bit uneasy with the model implemented here, as 'local' socket
>> > >> may cross netns boundaris and connect to 'local' socket in other netns
>> > >> (if I read correctly patch 2/12). That in turns AFAICS break the netns
>> > >> isolation.
>> > >
>> > > Local mode sockets are unable to communicate with local mode (and global
>> > > mode too) sockets that are in other namespaces. The key piece of code
>> > > for that is vsock_net_check_mode(), where if either modes is local the
>> > > namespaces must be the same.
>> >
>> > Sorry, I likely misread the large comment in patch 2:
>> >
>> > https://lore.kernel.org/netdev/20251126-vsock-vmtest-v12-2-257ee21cd5de@meta.com/
>> >
>> > >> Have you considered instead a slightly different model, where the
>> > >> local/global model is set in stone at netns creation time - alike what
>> > >> /proc/sys/net/ipv4/tcp_child_ehash_entries is doing[1] - and
>> > >> inter-netns connectivity is explicitly granted by the admin (I guess
>> > >> you will need new transport operations for that)?
>> > >>
>> > >> /P
>> > >>
>> > >> [1] tcp allows using per-netns established socket lookup tables - as
>> > >> opposed to the default global lookup table (even if match always takes
>> > >> in account the netns obviously). The mentioned sysctl specify such
>> > >> configuration for the children namespaces, if any.
>> > >
>> > > I'll save this discussion if the above doesn't resolve your concerns.
>> > I still have some concern WRT the dynamic mode change after netns
>> > creation. I fear some 'unsolvable' (or very hard to solve) race I can't
>> > see now. A tcp_child_ehash_entries-like model will avoid completely the
>> > issue, but I understand it would be a significant change over the
>> > current status.
>> >
>> > "Luckily" the merge window is on us and we have some time to discuss. Do
>> > you have a specific use-case for the ability to change the netns
>> > mode
>> > after creation?
>> >
>> > /P
>>
>> I don't think there is a hard requirement that the mode be change-able
>> after creation. Though I'd love to avoid such a big change... or at
>> least leave unchanged as much of what we've already reviewed as
>> possible.
>>
>> In the scheme of defining the mode at creation and following the
>> tcp_child_ehash_entries-ish model, what I'm imagining is:
>> - /proc/sys/net/vsock/child_ns_mode can be set to "local" or "global"
>> - /proc/sys/net/vsock/child_ns_mode is not immutable, can change any
>> number of times
>>
>> - when a netns is created, the new netns mode is inherited from
>> child_ns_mode, being assigned using something like:
>>
>> net->vsock.ns_mode =
>> get_net_ns_by_pid(current->pid)->child_ns_mode
>>
>> - /proc/sys/net/vsock/ns_mode queries the current mode, returning
>> "local" or "global", returning value of net->vsock.ns_mode
>> - /proc/sys/net/vsock/ns_mode and net->vsock.ns_mode are immutable and
>> reject writes
>>
>> Does that align with what you have in mind?
>
>Hey Paolo, I just wanted to sync up on this one. Does the above align
>with what you envision?
Hi Bobby, AFAIK Paolo was at LPC, so there could be some delay.
FYI I'll be off from Dec 25 to Jan 6, so if we want to do an RFC in the
middle, I'll do my best to take a look before my time off.
Thanks,
Stefano
^ permalink raw reply
* Re: [PATCH][next] hyperv: Avoid -Wflex-array-member-not-at-end warning
From: Wei Liu @ 2025-12-15 18:47 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
linux-hyperv, linux-kernel, linux-hardening
In-Reply-To: <aTu54qH2iHLKScRW@kspp>
On Fri, Dec 12, 2025 at 03:44:50PM +0900, Gustavo A. R. Silva wrote:
> -Wflex-array-member-not-at-end was introduced in GCC-14, and we are
> getting ready to enable it, globally.
>
> Use the new __TRAILING_OVERLAP() helper to fix the following warning:
>
> include/hyperv/hvgdk_mini.h:581:25: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
>
> This helper creates a union between a flexible-array member (FAM) and a
> set of MEMBERS that would otherwise follow it.
>
> This overlays the trailing MEMBER u64 gva_list[]; onto the FAM
> struct hv_tlb_flush_ex::hv_vp_set.bank_contents[], while keeping
> the FAM and the start of MEMBER aligned.
>
> The static_assert() ensures this alignment remains, and it's
> intentionally placed inmediately after the related structure --no
> blank line in between.
>
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Gustavo, what is your build command? I would like to incorporate that
into my own build tests.
Thanks,
Wei
> ---
> include/hyperv/hvgdk_mini.h | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/include/hyperv/hvgdk_mini.h b/include/hyperv/hvgdk_mini.h
> index 04b18d0e37af..30fbbde81c5c 100644
> --- a/include/hyperv/hvgdk_mini.h
> +++ b/include/hyperv/hvgdk_mini.h
> @@ -578,9 +578,12 @@ struct hv_tlb_flush { /* HV_INPUT_FLUSH_VIRTUAL_ADDRESS_LIST */
> struct hv_tlb_flush_ex {
> u64 address_space;
> u64 flags;
> - struct hv_vpset hv_vp_set;
> - u64 gva_list[];
> + __TRAILING_OVERLAP(struct hv_vpset, hv_vp_set, bank_contents, __packed,
> + u64 gva_list[];
> + );
> } __packed;
> +static_assert(offsetof(struct hv_tlb_flush_ex, hv_vp_set.bank_contents) ==
> + offsetof(struct hv_tlb_flush_ex, gva_list));
>
> struct ms_hyperv_tsc_page { /* HV_REFERENCE_TSC_PAGE */
> volatile u32 tsc_sequence;
> --
> 2.43.0
>
^ 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