[PATCH hyperv-next v5 00/11] arm64: hyperv: Support Virtual Trust Level Boot

[PATCH hyperv-next v5 00/11] arm64: hyperv: Support Virtual Trust Level Boot

[Roman Kisel]

This patch set allows the Hyper-V code to boot on ARM64 inside a Virtual Trust
Level. These levels are a part of the Virtual Secure Mode documented in the
Top-Level Functional Specification available at
https://learn.microsoft.com/en-us/virtualization/hyper-v-on-windows/tlfs/vsm.

The OpenHCL paravisor https://github.com/microsoft/openvmm/tree/main/openhcl
can serve as a practical application of these patches on ARM64.

For validation, I built kernels for the {x86_64, ARM64} x {VTL0, VTL2} set with
a small initrd embedded into the kernel and booted VMs managed by Hyper-V and
OpenVMM off of that.

Starting from V5, the patch series includes a non-functional change to KVM on
arm64 which I tested as well.

[V5]
    - Provide and use a common SMCCC-based infra for the arm64 hypervisor guests
      to detect hypervisor presence.
    ** Thank you, Arnd! **

    - Fix line wraps to follow the rest of the code.
    - Open-code getting IRQ domain parent in the ACPI case to make the code
      better.
    ** Thank you, Bjorn! **

    - Test the binding with the latest dtschema.
    - Clean up the commit title and description.
    - Use proper defines for known constants.
    ** Thank you, Krzysztof! **

    - Extend comment on why ACPI v6 is checked for.
    - Reorder patches to make sure that even with partial series application
      the compilation succeeds.
    - Report VTL the kernel runs in.
    - Use "X86_64" in Kconfig rather than "X86".
    - Extract a non-functional change for hv_get_vmbus_root_device() into
      a separate patch.
    ** Thank you, Michael! **

[V4]
    https://lore.kernel.org/linux-hyperv/20250212014321.1108840-1-romank@linux.microsoft.com/
    - Fixed wording to match acronyms defined in the "Terms and Abbreviations"
      section of the SMCCC specification throughout the patch series.
      **Thank you, Michael!**

    - Replaced the hypervisor ID containing ASCII with an UUID as
      required by the specification.
      **Thank you, Michael!**

    - Added an explicit check for `SMCCC_RET_NOT_SUPPORTED` when discovering the
      hypervisor presence to make the backward compatibility obvious.
      **Thank you, Saurabh!**

    - Split the fix for `get_vtl(void)` out to make it easier to backport.
    - Refactored the configuration options as requested to eliminate the risk
      of building non-functional kernels with randomly selected options.
      **Thank you, Michael!**

    - Refactored the changes not to introduce an additional file with
      a one-line function.
      **Thank you, Wei!**

    - Fixed change description for the VMBus DeviceTree changes, used
      `scripts/get_maintainers.pl` on the latest kernel to get the up-to-date list
      of maintainers as requested.
      **Thank you, Krzysztof!**

    - Removed the added (paranoidal+superfluous) checks for DMA coherence in the
      VMBus driver and instead relied on the DMA and the OF subsystem code.
      **Thank you, Arnd, Krzysztof, Michael!**

    - Used another set of APIs for discovering the hardware interrupt number
      in the VMBus driver to be able to build the driver as a module.
      **Thank you, Michael, Saurabh!**

    - Renamed the newly introduced `get_vmbus_root_device(void)` function to
      `hv_get_vmbus_root_device(void)` as requested.
      **Thank you, Wei!**

    - Applied the suggested small-scale refactoring to simplify changes to the Hyper-V
      PCI driver. Taking the offered liberty of doing the large scale refactoring
      in another patch series.
      **Thank you, Michael!**

    - Added a fix for the issue discovered internally where the CPU would not
      get the interrupt from a PCI device attached to VTL2 as the shared peripheral
      interrupt number (SPI) was not offset by 32 (the first valid SPI number).
      **Thank you, Brian!**

[V3]
    https://lore.kernel.org/lkml/20240726225910.1912537-1-romank@linux.microsoft.com/
    - Employed the SMCCC function recently implemented in the Microsoft Hyper-V
      hypervisor to detect running on Hyper-V/arm64. No dependence on ACPI/DT is
      needed anymore although the source code still falls back to ACPI as the new
      hypervisor might be available only in the Windows Insiders channel just
      yet.
    - As a part of the above, refactored detecting the hypervisor via ACPI FADT.
    - There was a suggestion to explore whether it is feasible or not to express
      that ACPI must be absent for the VTL mode and present for the regular guests
      in the Hyper-V Kconfig file.
      My current conclusion is that this will require refactoring in many places.
      That becomes especially convoluted on x86_64 due to the MSI and APIC
      dependencies. I'd ask to let us tackle that in another patch series (or chalk
      up to nice-have's rather than fires to put out) to separate concerns and
      decrease chances of breakage.
    - While refactoring `get_vtl(void)` and the related code, fixed the hypercall
      output address not to overlap with the input as the Hyper-V TLFS mandates:
      "The input and output parameter lists cannot overlap or cross page boundaries."
      See https://learn.microsoft.com/en-us/virtualization/hyper-v-on-windows/tlfs/hypercall-interface
      for more.
      Some might argue that should've been a topic for a separate patch series;
      I'd counter that the change is well-contained (one line), has no dependencies,
      and makes the code legal.
    - Made the VTL boot code (c)leaner as was suggested.
    - Set DMA cache coherency for the VMBus.
    - Updated DT bindings in the VMBus documentation (separated out into a new patch).
    - Fixed `vmbus_set_irq` to use the API that works both for the ACPI and OF.
    - Reworked setting up the vPCI MSI IRQ domain in the non-ACPI case. The logic
      looks a bit fiddly/ad-hoc as I couldn't find the API that would fit the bill.
      Added comments to explain myself.

[V2]
    https://lore.kernel.org/all/20240514224508.212318-1-romank@linux.microsoft.com/
    - Decreased number of #ifdef's
    - Updated the wording in the commit messages to adhere to the guidlines
    - Sending to the correct set of maintainers and mail lists

[V1]
    https://lore.kernel.org/all/20240510160602.1311352-1-romank@linux.microsoft.com/

Roman Kisel (11):
  arm64: kvm, smccc: Introduce and use API for detectting hypervisor
    presence
  arm64: hyperv: Use SMCCC to detect hypervisor presence
  Drivers: hv: Enable VTL mode for arm64
  Drivers: hv: Provide arch-neutral implementation of get_vtl()
  arm64: hyperv: Initialize the Virtual Trust Level field
  arm64, x86: hyperv: Report the VTL the system boots in
  dt-bindings: microsoft,vmbus: Add interrupts and DMA coherence
  Drivers: hv: vmbus: Get the IRQ number from DeviceTree
  Drivers: hv: vmbus: Introduce hv_get_vmbus_root_device()
  ACPI: irq: Introduce acpi_get_gsi_dispatcher()
  PCI: hv: Get vPCI MSI IRQ domain from DeviceTree

 .../bindings/bus/microsoft,vmbus.yaml         |  8 +-
 arch/arm64/hyperv/mshyperv.c                  | 46 +++++++++--
 arch/arm64/kvm/hypercalls.c                   |  5 +-
 arch/x86/hyperv/hv_init.c                     | 34 --------
 arch/x86/hyperv/hv_vtl.c                      |  2 +-
 drivers/acpi/irq.c                            | 14 +++-
 drivers/firmware/smccc/kvm_guest.c            | 10 +--
 drivers/firmware/smccc/smccc.c                | 19 +++++
 drivers/hv/Kconfig                            | 10 ++-
 drivers/hv/hv_common.c                        | 31 ++++++++
 drivers/hv/vmbus_drv.c                        | 59 ++++++++++++--
 drivers/pci/controller/pci-hyperv.c           | 79 +++++++++++++++++--
 include/asm-generic/mshyperv.h                |  6 ++
 include/hyperv/hvgdk_mini.h                   |  2 +-
 include/linux/acpi.h                          |  5 +-
 include/linux/arm-smccc.h                     | 55 ++++++++++++-
 include/linux/hyperv.h                        |  2 +
 17 files changed, 308 insertions(+), 79 deletions(-)


base-commit: 3a7f7785eae7cf012af128ca9e383c91e4955354
-- 
2.43.0

[PATCH hyperv-next v5 01/11] arm64: kvm, smccc: Introduce and use API for detectting hypervisor presence

[Roman Kisel]

The KVM/arm64 uses SMCCC to detect hypervisor presence. That code is
private, and it follows the SMCCC specification. Other existing and
emerging hypervisor guest implementations can and should use that
standard approach as well.

Factor out a common infrastructure that the guests can use, update KVM
to employ the new API. The cenrtal notion of the SMCCC method is the
UUID of the hypervisor, and the API follows that.

No functional changes. Validated with a KVM/arm64 guest.

Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
---
 arch/arm64/kvm/hypercalls.c        |  5 +--
 drivers/firmware/smccc/kvm_guest.c | 10 ++----
 drivers/firmware/smccc/smccc.c     | 19 +++++++++++
 include/linux/arm-smccc.h          | 55 +++++++++++++++++++++++++++---
 4 files changed, 73 insertions(+), 16 deletions(-)

diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
index 27ce4cb44904..92b9bc1ea8e8 100644
--- a/arch/arm64/kvm/hypercalls.c
+++ b/arch/arm64/kvm/hypercalls.c
@@ -353,10 +353,7 @@ int kvm_smccc_call_handler(struct kvm_vcpu *vcpu)
 			val[0] = gpa;
 		break;
 	case ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID:
-		val[0] = ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_0;
-		val[1] = ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_1;
-		val[2] = ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_2;
-		val[3] = ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_3;
+		UUID_TO_SMCCC_RES(ARM_SMCCC_VENDOR_HYP_UID_KVM, val);
 		break;
 	case ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID:
 		val[0] = smccc_feat->vendor_hyp_bmap;
diff --git a/drivers/firmware/smccc/kvm_guest.c b/drivers/firmware/smccc/kvm_guest.c
index f3319be20b36..b5084b309ea0 100644
--- a/drivers/firmware/smccc/kvm_guest.c
+++ b/drivers/firmware/smccc/kvm_guest.c
@@ -14,17 +14,11 @@ static DECLARE_BITMAP(__kvm_arm_hyp_services, ARM_SMCCC_KVM_NUM_FUNCS) __ro_afte
 
 void __init kvm_init_hyp_services(void)
 {
+	uuid_t kvm_uuid = ARM_SMCCC_VENDOR_HYP_UID_KVM;
 	struct arm_smccc_res res;
 	u32 val[4];
 
-	if (arm_smccc_1_1_get_conduit() != SMCCC_CONDUIT_HVC)
-		return;
-
-	arm_smccc_1_1_invoke(ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID, &res);
-	if (res.a0 != ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_0 ||
-	    res.a1 != ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_1 ||
-	    res.a2 != ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_2 ||
-	    res.a3 != ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_3)
+	if (!arm_smccc_hyp_present(&kvm_uuid))
 		return;
 
 	memset(&res, 0, sizeof(res));
diff --git a/drivers/firmware/smccc/smccc.c b/drivers/firmware/smccc/smccc.c
index a74600d9f2d7..7399f27d58e5 100644
--- a/drivers/firmware/smccc/smccc.c
+++ b/drivers/firmware/smccc/smccc.c
@@ -67,6 +67,25 @@ s32 arm_smccc_get_soc_id_revision(void)
 }
 EXPORT_SYMBOL_GPL(arm_smccc_get_soc_id_revision);
 
+bool arm_smccc_hyp_present(const uuid_t *hyp_uuid)
+{
+	struct arm_smccc_res res = {};
+
+	if (arm_smccc_1_1_get_conduit() != SMCCC_CONDUIT_HVC)
+		return false;
+	arm_smccc_1_1_hvc(ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID, &res);
+	if (res.a0 == SMCCC_RET_NOT_SUPPORTED)
+		return false;
+
+	return ({
+		const uuid_t uuid = SMCCC_RES_TO_UUID(res.a0, res.a1, res.a2, res.a3);
+		const bool present = uuid_equal(&uuid, hyp_uuid);
+
+		present;
+	});
+}
+EXPORT_SYMBOL_GPL(arm_smccc_hyp_present);
+
 static int __init smccc_devices_init(void)
 {
 	struct platform_device *pdev;
diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
index 67f6fdf2e7cd..726f18221f1c 100644
--- a/include/linux/arm-smccc.h
+++ b/include/linux/arm-smccc.h
@@ -7,6 +7,11 @@
 
 #include <linux/args.h>
 #include <linux/init.h>
+
+#ifndef __ASSEMBLER__
+#include <linux/uuid.h>
+#endif
+
 #include <uapi/linux/const.h>
 
 /*
@@ -107,10 +112,10 @@
 			   ARM_SMCCC_FUNC_QUERY_CALL_UID)
 
 /* KVM UID value: 28b46fb6-2ec5-11e9-a9ca-4b564d003a74 */
-#define ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_0	0xb66fb428U
-#define ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_1	0xe911c52eU
-#define ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_2	0x564bcaa9U
-#define ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_3	0x743a004dU
+#define ARM_SMCCC_VENDOR_HYP_UID_KVM UUID_INIT(\
+	0xb66fb428, 0xc52e, 0xe911, \
+	0xa9, 0xca, 0x4b, 0x56, \
+	0x4d, 0x00, 0x3a, 0x74)
 
 /* KVM "vendor specific" services */
 #define ARM_SMCCC_KVM_FUNC_FEATURES		0
@@ -333,6 +338,48 @@ s32 arm_smccc_get_soc_id_version(void);
  */
 s32 arm_smccc_get_soc_id_revision(void);
 
+#ifndef __ASSEMBLER__
+
+/**
+ * arm_smccc_hyp_present(const uuid_t *hyp_uuid)
+ *
+ * Returns `true` if the hypervisor advertises its presence via SMCCC.
+ *
+ * When the function returns `false`, the caller shall not assume that
+ * there is no hypervisor running. Instead, the caller must fall back to
+ * other approaches if any are available.
+ */
+bool arm_smccc_hyp_present(const uuid_t *hyp_uuid);
+
+#define SMCCC_RES_TO_UUID(r0, r1, r2, r3) \
+	UUID_INIT( \
+		cpu_to_le32(lower_32_bits(r0)), \
+		cpu_to_le32(lower_32_bits(r1)) & 0xffff, \
+		cpu_to_le32(lower_32_bits(r1)) >> 16, \
+		cpu_to_le32(lower_32_bits(r2)) & 0xff, \
+		(cpu_to_le32(lower_32_bits(r2)) >> 8) & 0xff, \
+		(cpu_to_le32(lower_32_bits(r2)) >> 16) & 0xff, \
+		(cpu_to_le32(lower_32_bits(r2)) >> 24) & 0xff, \
+		cpu_to_le32(lower_32_bits(r3)) & 0xff, \
+		(cpu_to_le32(lower_32_bits(r3)) >> 8) & 0xff, \
+		(cpu_to_le32(lower_32_bits(r3)) >> 16) & 0xff, \
+		(cpu_to_le32(lower_32_bits(r3)) >> 24) & 0xff \
+	)
+
+#define UUID_TO_SMCCC_RES(uuid_init, regs) do { \
+		const uuid_t uuid = uuid_init; \
+		(regs)[0] = le32_to_cpu((u32)uuid.b[0] | (uuid.b[1] << 8) | \
+						((uuid.b[2]) << 16) | ((uuid.b[3]) << 24)); \
+		(regs)[1] = le32_to_cpu((u32)uuid.b[4] | (uuid.b[5] << 8) | \
+						((uuid.b[6]) << 16) | ((uuid.b[7]) << 24)); \
+		(regs)[2] = le32_to_cpu((u32)uuid.b[8] | (uuid.b[9] << 8) | \
+						((uuid.b[10]) << 16) | ((uuid.b[11]) << 24)); \
+		(regs)[3] = le32_to_cpu((u32)uuid.b[12] | (uuid.b[13] << 8) | \
+						((uuid.b[14]) << 16) | ((uuid.b[15]) << 24)); \
+	} while (0)
+
+#endif /* !__ASSEMBLER__ */
+
 /**
  * struct arm_smccc_res - Result from SMC/HVC call
  * @a0-a3 result values from registers 0 to 3
-- 
2.43.0

[PATCH hyperv-next v5 02/11] arm64: hyperv: Use SMCCC to detect hypervisor presence

[Roman Kisel]

The arm64 Hyper-V startup path relies on ACPI to detect
running under a Hyper-V compatible hypervisor. That
doesn't work on non-ACPI systems.

Hoist the ACPI detection logic into a separate function. Then
use the vendor-specific hypervisor service call (implemented
recently in Hyper-V) via SMCCC in the non-ACPI case.

Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
---
 arch/arm64/hyperv/mshyperv.c | 43 +++++++++++++++++++++++++++++++-----
 1 file changed, 38 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/hyperv/mshyperv.c b/arch/arm64/hyperv/mshyperv.c
index 29fcfd595f48..c647db56fd6b 100644
--- a/arch/arm64/hyperv/mshyperv.c
+++ b/arch/arm64/hyperv/mshyperv.c
@@ -27,6 +27,41 @@ int hv_get_hypervisor_version(union hv_hypervisor_version_info *info)
 	return 0;
 }
 
+static bool __init hyperv_detect_via_acpi(void)
+{
+	if (acpi_disabled)
+		return false;
+#if IS_ENABLED(CONFIG_ACPI)
+	/*
+	 * Hypervisor ID is only available in ACPI v6+, and the
+	 * structure layout was extended in v6 to accommodate that
+	 * new field.
+	 *
+	 * At the very minimum, this check makes sure not to read
+	 * past the FADT structure.
+	 *
+	 * It is also needed to catch running in some unknown
+	 * non-Hyper-V environment that has ACPI 5.x or less.
+	 * In such a case, it can't be Hyper-V.
+	 */
+	if (acpi_gbl_FADT.header.revision < 6)
+		return false;
+	return strncmp((char *)&acpi_gbl_FADT.hypervisor_id, "MsHyperV", 8) == 0;
+#else
+	return false;
+#endif
+}
+
+static bool __init hyperv_detect_via_smccc(void)
+{
+	uuid_t hyperv_uuid = UUID_INIT(
+		0x4d32ba58, 0x4764, 0xcd24,
+		0x75, 0x6c, 0xef, 0x8e,
+		0x24, 0x70, 0x59, 0x16);
+
+	return arm_smccc_hyp_present(&hyperv_uuid);
+}
+
 static int __init hyperv_init(void)
 {
 	struct hv_get_vp_registers_output	result;
@@ -35,13 +70,11 @@ static int __init hyperv_init(void)
 
 	/*
 	 * Allow for a kernel built with CONFIG_HYPERV to be running in
-	 * a non-Hyper-V environment, including on DT instead of ACPI.
+	 * a non-Hyper-V environment.
+	 *
 	 * In such cases, do nothing and return success.
 	 */
-	if (acpi_disabled)
-		return 0;
-
-	if (strncmp((char *)&acpi_gbl_FADT.hypervisor_id, "MsHyperV", 8))
+	if (!hyperv_detect_via_acpi() && !hyperv_detect_via_smccc())
 		return 0;
 
 	/* Setup the guest ID */
-- 
2.43.0

[PATCH hyperv-next v5 03/11] Drivers: hv: Enable VTL mode for arm64

[Roman Kisel]

Kconfig dependencies for arm64 guests on Hyper-V require that be
ACPI enabled, and limit VTL mode to x86/x64. To enable VTL mode
on arm64 as well, update the dependencies. Since VTL mode requires
DeviceTree instead of ACPI, don’t require arm64 guests on Hyper-V
to have ACPI unconditionally.

Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
---
 drivers/hv/Kconfig | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
index 862c47b191af..c37b1a44e580 100644
--- a/drivers/hv/Kconfig
+++ b/drivers/hv/Kconfig
@@ -5,18 +5,20 @@ menu "Microsoft Hyper-V guest support"
 config HYPERV
 	tristate "Microsoft Hyper-V client drivers"
 	depends on (X86 && X86_LOCAL_APIC && HYPERVISOR_GUEST) \
-		|| (ACPI && ARM64 && !CPU_BIG_ENDIAN)
+		|| (ARM64 && !CPU_BIG_ENDIAN)
+	depends on (ACPI || HYPERV_VTL_MODE)
 	select PARAVIRT
 	select X86_HV_CALLBACK_VECTOR if X86
-	select OF_EARLY_FLATTREE if OF
 	help
 	  Select this option to run Linux as a Hyper-V client operating
 	  system.
 
 config HYPERV_VTL_MODE
 	bool "Enable Linux to boot in VTL context"
-	depends on X86_64 && HYPERV
+	depends on (X86_64 || ARM64)
 	depends on SMP
+	select OF_EARLY_FLATTREE
+	select OF
 	default n
 	help
 	  Virtual Secure Mode (VSM) is a set of hypervisor capabilities and
@@ -31,7 +33,7 @@ config HYPERV_VTL_MODE
 
 	  Select this option to build a Linux kernel to run at a VTL other than
 	  the normal VTL0, which currently is only VTL2.  This option
-	  initializes the x86 platform for VTL2, and adds the ability to boot
+	  initializes the kernel to run in VTL2, and adds the ability to boot
 	  secondary CPUs directly into 64-bit context as required for VTLs other
 	  than 0.  A kernel built with this option must run at VTL2, and will
 	  not run as a normal guest.
-- 
2.43.0

[PATCH hyperv-next v5 04/11] Drivers: hv: Provide arch-neutral implementation of get_vtl()

[Roman Kisel]

To run in the VTL mode, Hyper-V drivers have to know what
VTL the system boots in, and the arm64/hyperv code does not
have the means to compute that.

Refactor the code to hoist the function that detects VTL,
make it arch-neutral to be able to employ it to get the VTL
on arm64.

Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
---
 arch/x86/hyperv/hv_init.c      | 34 ----------------------------------
 drivers/hv/hv_common.c         | 31 +++++++++++++++++++++++++++++++
 include/asm-generic/mshyperv.h |  6 ++++++
 include/hyperv/hvgdk_mini.h    |  2 +-
 4 files changed, 38 insertions(+), 35 deletions(-)

diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index 9be1446f5bd3..e204cb9d41af 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -390,40 +390,6 @@ static void __init hv_stimer_setup_percpu_clockev(void)
 		old_setup_percpu_clockev();
 }
 
-#if IS_ENABLED(CONFIG_HYPERV_VTL_MODE)
-static u8 __init get_vtl(void)
-{
-	u64 control = HV_HYPERCALL_REP_COMP_1 | HVCALL_GET_VP_REGISTERS;
-	struct hv_input_get_vp_registers *input;
-	struct hv_output_get_vp_registers *output;
-	unsigned long flags;
-	u64 ret;
-
-	local_irq_save(flags);
-	input = *this_cpu_ptr(hyperv_pcpu_input_arg);
-	output = *this_cpu_ptr(hyperv_pcpu_output_arg);
-
-	memset(input, 0, struct_size(input, names, 1));
-	input->partition_id = HV_PARTITION_ID_SELF;
-	input->vp_index = HV_VP_INDEX_SELF;
-	input->input_vtl.as_uint8 = 0;
-	input->names[0] = HV_REGISTER_VSM_VP_STATUS;
-
-	ret = hv_do_hypercall(control, input, output);
-	if (hv_result_success(ret)) {
-		ret = output->values[0].reg8 & HV_X64_VTL_MASK;
-	} else {
-		pr_err("Failed to get VTL(error: %lld) exiting...\n", ret);
-		BUG();
-	}
-
-	local_irq_restore(flags);
-	return ret;
-}
-#else
-static inline u8 get_vtl(void) { return 0; }
-#endif
-
 /*
  * This function is to be invoked early in the boot sequence after the
  * hypervisor has been detected.
diff --git a/drivers/hv/hv_common.c b/drivers/hv/hv_common.c
index ee3083937b4f..10983e854a4d 100644
--- a/drivers/hv/hv_common.c
+++ b/drivers/hv/hv_common.c
@@ -304,6 +304,37 @@ void __init hv_get_partition_id(void)
 		pr_err("Hyper-V: failed to get partition ID: %#x\n",
 		       hv_result(status));
 }
+#if IS_ENABLED(CONFIG_HYPERV_VTL_MODE)
+u8 __init get_vtl(void)
+{
+	u64 control = HV_HYPERCALL_REP_COMP_1 | HVCALL_GET_VP_REGISTERS;
+	struct hv_input_get_vp_registers *input;
+	struct hv_output_get_vp_registers *output;
+	unsigned long flags;
+	u64 ret;
+
+	local_irq_save(flags);
+	input = *this_cpu_ptr(hyperv_pcpu_input_arg);
+	output = *this_cpu_ptr(hyperv_pcpu_output_arg);
+
+	memset(input, 0, struct_size(input, names, 1));
+	input->partition_id = HV_PARTITION_ID_SELF;
+	input->vp_index = HV_VP_INDEX_SELF;
+	input->input_vtl.as_uint8 = 0;
+	input->names[0] = HV_REGISTER_VSM_VP_STATUS;
+
+	ret = hv_do_hypercall(control, input, output);
+	if (hv_result_success(ret)) {
+		ret = output->values[0].reg8 & HV_VTL_MASK;
+	} else {
+		pr_err("Failed to get VTL(error: %lld) exiting...\n", ret);
+		BUG();
+	}
+
+	local_irq_restore(flags);
+	return ret;
+}
+#endif
 
 int __init hv_common_init(void)
 {
diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyperv.h
index 7adc10a4fa3e..bf897c528976 100644
--- a/include/asm-generic/mshyperv.h
+++ b/include/asm-generic/mshyperv.h
@@ -320,4 +320,10 @@ static inline enum hv_isolation_type hv_get_isolation_type(void)
 }
 #endif /* CONFIG_HYPERV */
 
+#if IS_ENABLED(CONFIG_HYPERV_VTL_MODE)
+u8 __init get_vtl(void);
+#else
+static inline u8 get_vtl(void) { return 0; }
+#endif
+
 #endif
diff --git a/include/hyperv/hvgdk_mini.h b/include/hyperv/hvgdk_mini.h
index 58895883f636..98aa64e8844c 100644
--- a/include/hyperv/hvgdk_mini.h
+++ b/include/hyperv/hvgdk_mini.h
@@ -1202,7 +1202,7 @@ struct hv_send_ipi {	 /* HV_INPUT_SEND_SYNTHETIC_CLUSTER_IPI */
 	u64 cpu_mask;
 } __packed;
 
-#define	HV_X64_VTL_MASK			GENMASK(3, 0)
+#define	HV_VTL_MASK			GENMASK(3, 0)
 
 /* Hyper-V memory host visibility */
 enum hv_mem_host_visibility {
-- 
2.43.0

[PATCH hyperv-next v5 05/11] arm64: hyperv: Initialize the Virtual Trust Level field

[Roman Kisel]

Various parts of the hyperv code need to know what VTL
the kernel runs at, most notably VMBus needs that to
establish communication with the host.

Initialize the Virtual Trust Level field to enable
booting in the Virtual Trust Level.

Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
---
 arch/arm64/hyperv/mshyperv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/hyperv/mshyperv.c b/arch/arm64/hyperv/mshyperv.c
index c647db56fd6b..a7db03f5413d 100644
--- a/arch/arm64/hyperv/mshyperv.c
+++ b/arch/arm64/hyperv/mshyperv.c
@@ -107,6 +107,7 @@ static int __init hyperv_init(void)
 
 	if (ms_hyperv.priv_high & HV_ACCESS_PARTITION_ID)
 		hv_get_partition_id();
+	ms_hyperv.vtl = get_vtl();
 
 	ms_hyperv_late_init();
 
-- 
2.43.0

[PATCH hyperv-next v5 06/11] arm64, x86: hyperv: Report the VTL the system boots in

[Roman Kisel]

The hyperv guest code might run in various Virtual Trust Levels.

Report the level when the kernel boots in the non-default (0)
one.

Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
---
 arch/arm64/hyperv/mshyperv.c | 2 ++
 arch/x86/hyperv/hv_vtl.c     | 2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/hyperv/mshyperv.c b/arch/arm64/hyperv/mshyperv.c
index a7db03f5413d..3bc16dbee758 100644
--- a/arch/arm64/hyperv/mshyperv.c
+++ b/arch/arm64/hyperv/mshyperv.c
@@ -108,6 +108,8 @@ static int __init hyperv_init(void)
 	if (ms_hyperv.priv_high & HV_ACCESS_PARTITION_ID)
 		hv_get_partition_id();
 	ms_hyperv.vtl = get_vtl();
+	if (ms_hyperv.vtl > 0) /* non default VTL */
+		pr_info("Linux runs in Hyper-V Virtual Trust Level %d\n", ms_hyperv.vtl);
 
 	ms_hyperv_late_init();
 
diff --git a/arch/x86/hyperv/hv_vtl.c b/arch/x86/hyperv/hv_vtl.c
index 4e1b1e3b5658..c21bee7e8ff3 100644
--- a/arch/x86/hyperv/hv_vtl.c
+++ b/arch/x86/hyperv/hv_vtl.c
@@ -24,7 +24,7 @@ static bool __init hv_vtl_msi_ext_dest_id(void)
 
 void __init hv_vtl_init_platform(void)
 {
-	pr_info("Linux runs in Hyper-V Virtual Trust Level\n");
+	pr_info("Linux runs in Hyper-V Virtual Trust Level %d\n", ms_hyperv.vtl);
 
 	x86_platform.realmode_reserve = x86_init_noop;
 	x86_platform.realmode_init = x86_init_noop;
-- 
2.43.0

[PATCH hyperv-next v5 07/11] dt-bindings: microsoft,vmbus: Add interrupts and DMA coherence

[Roman Kisel]

To boot on ARM64, VMBus requires configuring interrupts. Missing
DMA coherence property is sub-optimal as the VMBus transations are
cache-coherent.

Add interrupts to be able to boot on ARM64. Add DMA coherence to
avoid doing extra work on maintaining caches on ARM64.

Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
---
 .../devicetree/bindings/bus/microsoft,vmbus.yaml          | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/bus/microsoft,vmbus.yaml b/Documentation/devicetree/bindings/bus/microsoft,vmbus.yaml
index a8d40c766dcd..3ab7d0116626 100644
--- a/Documentation/devicetree/bindings/bus/microsoft,vmbus.yaml
+++ b/Documentation/devicetree/bindings/bus/microsoft,vmbus.yaml
@@ -28,13 +28,16 @@ properties:
 required:
   - compatible
   - ranges
+  - interrupts
   - '#address-cells'
   - '#size-cells'
 
-additionalProperties: false
+additionalProperties: true
 
 examples:
   - |
+    #include <dt-bindings/interrupt-controller/irq.h>
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
     soc {
         #address-cells = <2>;
         #size-cells = <1>;
@@ -49,6 +52,9 @@ examples:
                 #address-cells = <2>;
                 #size-cells = <1>;
                 ranges = <0x0f 0xf0000000 0x0f 0xf0000000 0x10000000>;
+                dma-coherent;
+                interrupt-parent = <&gic>;
+                interrupts = <GIC_PPI 2 IRQ_TYPE_EDGE_RISING>;
             };
         };
     };
-- 
2.43.0

[PATCH hyperv-next v5 08/11] Drivers: hv: vmbus: Get the IRQ number from DeviceTree

[Roman Kisel]

The VMBus driver uses ACPI for interrupt assignment on
arm64 hence it won't function in the VTL mode where only
DeviceTree can be used.

Update the VMBus driver to discover interrupt configuration
from DT.

Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
---
 drivers/hv/vmbus_drv.c | 36 ++++++++++++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)

diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 75eb1390b45c..c8474b48dcd2 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -2345,6 +2345,36 @@ static int vmbus_acpi_add(struct platform_device *pdev)
 }
 #endif
 
+static int __maybe_unused vmbus_set_irq(struct platform_device *pdev)
+{
+	struct irq_data *data;
+	int irq;
+	irq_hw_number_t hwirq;
+
+	irq = platform_get_irq(pdev, 0);
+	if (irq == 0) {
+		pr_err("VMBus interrupt mapping failure\n");
+		return -EINVAL;
+	}
+	if (irq < 0) {
+		pr_err("VMBus interrupt data can't be read from DeviceTree, error %d\n", irq);
+		return irq;
+	}
+
+	data = irq_get_irq_data(irq);
+	if (!data) {
+		pr_err("No interrupt data for VMBus virq %d\n", irq);
+		return -ENODEV;
+	}
+	hwirq = irqd_to_hwirq(data);
+
+	vmbus_irq = irq;
+	vmbus_interrupt = hwirq;
+	pr_debug("VMBus virq %d, hwirq %d\n", vmbus_irq, vmbus_interrupt);
+
+	return 0;
+}
+
 static int vmbus_device_add(struct platform_device *pdev)
 {
 	struct resource **cur_res = &hyperv_mmio;
@@ -2359,6 +2389,12 @@ static int vmbus_device_add(struct platform_device *pdev)
 	if (ret)
 		return ret;
 
+#ifndef HYPERVISOR_CALLBACK_VECTOR
+	ret = vmbus_set_irq(pdev);
+	if (ret)
+		return ret;
+#endif
+
 	for_each_of_range(&parser, &range) {
 		struct resource *res;
 
-- 
2.43.0

[PATCH hyperv-next v5 09/11] Drivers: hv: vmbus: Introduce hv_get_vmbus_root_device()

[Roman Kisel]

The ARM64 PCI code for hyperv needs to know the VMBus root
device, and it is private.

Provide a function that returns it. Rename it from "hv_dev"
as "hv_dev" as a symbol is very overloaded. No functional
changes.

Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
---
 drivers/hv/vmbus_drv.c | 23 +++++++++++++++--------
 include/linux/hyperv.h |  2 ++
 2 files changed, 17 insertions(+), 8 deletions(-)

diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index c8474b48dcd2..7bfafe702963 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -45,7 +45,8 @@ struct vmbus_dynid {
 	struct hv_vmbus_device_id id;
 };
 
-static struct device  *hv_dev;
+/* VMBus Root Device */
+static struct device  *vmbus_root_device;
 
 static int hyperv_cpuhp_online;
 
@@ -80,9 +81,15 @@ static struct resource *fb_mmio;
 static struct resource *hyperv_mmio;
 static DEFINE_MUTEX(hyperv_mmio_lock);
 
+struct device *hv_get_vmbus_root_device(void)
+{
+	return vmbus_root_device;
+}
+EXPORT_SYMBOL_GPL(hv_get_vmbus_root_device);
+
 static int vmbus_exists(void)
 {
-	if (hv_dev == NULL)
+	if (vmbus_root_device == NULL)
 		return -ENODEV;
 
 	return 0;
@@ -861,7 +868,7 @@ static int vmbus_dma_configure(struct device *child_device)
 	 * On x86/x64 coherence is assumed and these calls have no effect.
 	 */
 	hv_setup_dma_ops(child_device,
-		device_get_dma_attr(hv_dev) == DEV_DMA_COHERENT);
+		device_get_dma_attr(vmbus_root_device) == DEV_DMA_COHERENT);
 	return 0;
 }
 
@@ -1930,7 +1937,7 @@ int vmbus_device_register(struct hv_device *child_device_obj)
 		     &child_device_obj->channel->offermsg.offer.if_instance);
 
 	child_device_obj->device.bus = &hv_bus;
-	child_device_obj->device.parent = hv_dev;
+	child_device_obj->device.parent = vmbus_root_device;
 	child_device_obj->device.release = vmbus_device_release;
 
 	child_device_obj->device.dma_parms = &child_device_obj->dma_parms;
@@ -2292,7 +2299,7 @@ static int vmbus_acpi_add(struct platform_device *pdev)
 	struct acpi_device *ancestor;
 	struct acpi_device *device = ACPI_COMPANION(&pdev->dev);
 
-	hv_dev = &device->dev;
+	vmbus_root_device = &device->dev;
 
 	/*
 	 * Older versions of Hyper-V for ARM64 fail to include the _CCA
@@ -2383,7 +2390,7 @@ static int vmbus_device_add(struct platform_device *pdev)
 	struct device_node *np = pdev->dev.of_node;
 	int ret;
 
-	hv_dev = &pdev->dev;
+	vmbus_root_device = &pdev->dev;
 
 	ret = of_range_parser_init(&parser, np);
 	if (ret)
@@ -2702,7 +2709,7 @@ static int __init hv_acpi_init(void)
 	if (ret)
 		return ret;
 
-	if (!hv_dev) {
+	if (!vmbus_root_device) {
 		ret = -ENODEV;
 		goto cleanup;
 	}
@@ -2733,7 +2740,7 @@ static int __init hv_acpi_init(void)
 
 cleanup:
 	platform_driver_unregister(&vmbus_platform_driver);
-	hv_dev = NULL;
+	vmbus_root_device = NULL;
 	return ret;
 }
 
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 7f4f8d8bdf43..1f0851fde041 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -1333,6 +1333,8 @@ static inline void *hv_get_drvdata(struct hv_device *dev)
 	return dev_get_drvdata(&dev->device);
 }
 
+struct device *hv_get_vmbus_root_device(void);
+
 struct hv_ring_buffer_debug_info {
 	u32 current_interrupt_mask;
 	u32 current_read_index;
-- 
2.43.0

[PATCH hyperv-next v5 10/11] ACPI: irq: Introduce acpi_get_gsi_dispatcher()

[Roman Kisel]

Using acpi_irq_create_hierarchy() in the cases where the code
also handles OF leads to code duplication as the ACPI subsystem
doesn't provide means to compute the IRQ domain parent whereas
the OF does.

Introduce acpi_get_gsi_dispatcher() so that the drivers relying
on both ACPI and OF may use irq_domain_create_hierarchy() in the
common code paths.

No functional changes.

Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
---
 drivers/acpi/irq.c   | 14 ++++++++++++--
 include/linux/acpi.h |  5 ++++-
 2 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/irq.c b/drivers/acpi/irq.c
index 1687483ff319..6243db610137 100644
--- a/drivers/acpi/irq.c
+++ b/drivers/acpi/irq.c
@@ -12,7 +12,7 @@
 
 enum acpi_irq_model_id acpi_irq_model;
 
-static struct fwnode_handle *(*acpi_get_gsi_domain_id)(u32 gsi);
+static acpi_gsi_domain_disp_fn acpi_get_gsi_domain_id;
 static u32 (*acpi_gsi_to_irq_fallback)(u32 gsi);
 
 /**
@@ -307,12 +307,22 @@ EXPORT_SYMBOL_GPL(acpi_irq_get);
  *	for a given GSI
  */
 void __init acpi_set_irq_model(enum acpi_irq_model_id model,
-			       struct fwnode_handle *(*fn)(u32))
+	acpi_gsi_domain_disp_fn fn)
 {
 	acpi_irq_model = model;
 	acpi_get_gsi_domain_id = fn;
 }
 
+/**
+ * acpi_get_gsi_dispatcher - Returns dispatcher function that
+ *                           computes the domain fwnode for a
+ *                           given GSI.
+ */
+acpi_gsi_domain_disp_fn acpi_get_gsi_dispatcher(void)
+{
+	return acpi_get_gsi_domain_id;
+}
+
 /**
  * acpi_set_gsi_to_irq_fallback - Register a GSI transfer
  * callback to fallback to arch specified implementation.
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 4e495b29c640..abc51288e867 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -336,8 +336,11 @@ int acpi_register_gsi (struct device *dev, u32 gsi, int triggering, int polarity
 int acpi_gsi_to_irq (u32 gsi, unsigned int *irq);
 int acpi_isa_irq_to_gsi (unsigned isa_irq, u32 *gsi);
 
+typedef struct fwnode_handle *(*acpi_gsi_domain_disp_fn)(u32);
+
 void acpi_set_irq_model(enum acpi_irq_model_id model,
-			struct fwnode_handle *(*)(u32));
+	acpi_gsi_domain_disp_fn fn);
+acpi_gsi_domain_disp_fn acpi_get_gsi_dispatcher(void);
 void acpi_set_gsi_to_irq_fallback(u32 (*)(u32));
 
 struct irq_domain *acpi_irq_create_hierarchy(unsigned int flags,
-- 
2.43.0

[PATCH hyperv-next v5 11/11] PCI: hv: Get vPCI MSI IRQ domain from DeviceTree

[Roman Kisel]

The hyperv-pci driver uses ACPI for MSI IRQ domain configuration on
arm64. It won't be able to do that in the VTL mode where only DeviceTree
can be used.

Update the hyperv-pci driver to get vPCI MSI IRQ domain in the DeviceTree
case, too.

Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
---
 drivers/pci/controller/pci-hyperv.c | 79 ++++++++++++++++++++++++++---
 1 file changed, 73 insertions(+), 6 deletions(-)

diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c
index 6084b38bdda1..9740006a8c73 100644
--- a/drivers/pci/controller/pci-hyperv.c
+++ b/drivers/pci/controller/pci-hyperv.c
@@ -50,6 +50,7 @@
 #include <linux/irqdomain.h>
 #include <linux/acpi.h>
 #include <linux/sizes.h>
+#include <linux/of_irq.h>
 #include <asm/mshyperv.h>
 
 /*
@@ -817,9 +818,17 @@ static int hv_pci_vec_irq_gic_domain_alloc(struct irq_domain *domain,
 	int ret;
 
 	fwspec.fwnode = domain->parent->fwnode;
-	fwspec.param_count = 2;
-	fwspec.param[0] = hwirq;
-	fwspec.param[1] = IRQ_TYPE_EDGE_RISING;
+	if (is_of_node(fwspec.fwnode)) {
+		/* SPI lines for OF translations start at offset 32 */
+		fwspec.param_count = 3;
+		fwspec.param[0] = 0;
+		fwspec.param[1] = hwirq - 32;
+		fwspec.param[2] = IRQ_TYPE_EDGE_RISING;
+	} else {
+		fwspec.param_count = 2;
+		fwspec.param[0] = hwirq;
+		fwspec.param[1] = IRQ_TYPE_EDGE_RISING;
+	}
 
 	ret = irq_domain_alloc_irqs_parent(domain, virq, 1, &fwspec);
 	if (ret)
@@ -887,10 +896,53 @@ static const struct irq_domain_ops hv_pci_domain_ops = {
 	.activate = hv_pci_vec_irq_domain_activate,
 };
 
+#ifdef CONFIG_OF
+
+static struct irq_domain *hv_pci_of_irq_domain_parent(void)
+{
+	struct device_node *parent;
+	struct irq_domain *domain;
+
+	parent = of_irq_find_parent(hv_get_vmbus_root_device()->of_node);
+	domain = NULL;
+	if (parent) {
+		domain = irq_find_host(parent);
+		of_node_put(parent);
+	}
+
+	return domain;
+}
+
+#endif
+
+#ifdef CONFIG_ACPI
+
+static struct irq_domain *hv_pci_acpi_irq_domain_parent(void)
+{
+	struct irq_domain *domain;
+	acpi_gsi_domain_disp_fn gsi_domain_disp_fn;
+
+	if (acpi_irq_model != ACPI_IRQ_MODEL_GIC)
+		return NULL;
+	gsi_domain_disp_fn = acpi_get_gsi_dispatcher();
+	if (!gsi_domain_disp_fn)
+		return NULL;
+	domain = irq_find_matching_fwnode(gsi_domain_disp_fn(0),
+				     DOMAIN_BUS_ANY);
+
+	if (!domain)
+		return NULL;
+
+	return domain;
+}
+
+#endif
+
 static int hv_pci_irqchip_init(void)
 {
 	static struct hv_pci_chip_data *chip_data;
 	struct fwnode_handle *fn = NULL;
+	struct irq_domain *irq_domain_parent = NULL;
 	int ret = -ENOMEM;
 
 	chip_data = kzalloc(sizeof(*chip_data), GFP_KERNEL);
@@ -907,9 +959,24 @@ static int hv_pci_irqchip_init(void)
 	 * way to ensure that all the corresponding devices are also gone and
 	 * no interrupts will be generated.
 	 */
-	hv_msi_gic_irq_domain = acpi_irq_create_hierarchy(0, HV_PCI_MSI_SPI_NR,
-							  fn, &hv_pci_domain_ops,
-							  chip_data);
+#ifdef CONFIG_ACPI
+	if (!acpi_disabled)
+		irq_domain_parent = hv_pci_acpi_irq_domain_parent();
+#endif
+#if defined(CONFIG_OF)
+	if (!irq_domain_parent)
+		irq_domain_parent = hv_pci_of_irq_domain_parent();
+#endif
+	if (!irq_domain_parent) {
+		WARN_ONCE(1, "Invalid firmware configuration for VMBus interrupts\n");
+		ret = -EINVAL;
+		goto free_chip;
+	}
+
+	hv_msi_gic_irq_domain = irq_domain_create_hierarchy(
+		irq_domain_parent, 0, HV_PCI_MSI_SPI_NR,
+		fn, &hv_pci_domain_ops,
+		chip_data);
 
 	if (!hv_msi_gic_irq_domain) {
 		pr_err("Failed to create Hyper-V arm64 vPCI MSI IRQ domain\n");
-- 
2.43.0

Re: [PATCH hyperv-next v5 03/11] Drivers: hv: Enable VTL mode for arm64

[Arnd Bergmann]

On Fri, Mar 7, 2025, at 23:02, Roman Kisel wrote:
> @@ -5,18 +5,20 @@ menu "Microsoft Hyper-V guest support"
>  config HYPERV
>  	tristate "Microsoft Hyper-V client drivers"
>  	depends on (X86 && X86_LOCAL_APIC && HYPERVISOR_GUEST) \
> -		|| (ACPI && ARM64 && !CPU_BIG_ENDIAN)
> +		|| (ARM64 && !CPU_BIG_ENDIAN)
> +	depends on (ACPI || HYPERV_VTL_MODE)
>  	select PARAVIRT
>  	select X86_HV_CALLBACK_VECTOR if X86
> -	select OF_EARLY_FLATTREE if OF
>  	help
>  	  Select this option to run Linux as a Hyper-V client operating
>  	  system.
> 
>  config HYPERV_VTL_MODE
>  	bool "Enable Linux to boot in VTL context"
> -	depends on X86_64 && HYPERV
> +	depends on (X86_64 || ARM64)
>  	depends on SMP
> +	select OF_EARLY_FLATTREE
> +	select OF
>  	default n
>  	help

Having the dependency below the top-level Kconfig entry feels a little
counterintuitive. You could flip that back as it was before by doing

      select HYPERV_VTL_MODE if !ACPI
      depends on ACPI || SMP

in the HYPERV option, leaving the dependency on HYPERV in
HYPERV_VTL_MODE.

Is OF_EARLY_FLATTREE actually needed on x86?

      Arnd

Re: [PATCH hyperv-next v5 01/11] arm64: kvm, smccc: Introduce and use API for detectting hypervisor presence

[Arnd Bergmann]

On Fri, Mar 7, 2025, at 23:02, Roman Kisel wrote:
> The KVM/arm64 uses SMCCC to detect hypervisor presence. That code is
> private, and it follows the SMCCC specification. Other existing and
> emerging hypervisor guest implementations can and should use that
> standard approach as well.
>
> Factor out a common infrastructure that the guests can use, update KVM
> to employ the new API. The cenrtal notion of the SMCCC method is the
> UUID of the hypervisor, and the API follows that.
>
> No functional changes. Validated with a KVM/arm64 guest.
>
> Signed-off-by: Roman Kisel <romank@linux.microsoft.com>

Acked-by: Arnd Bergmann <arnd@arndb.de>

Re: [PATCH hyperv-next v5 08/11] Drivers: hv: vmbus: Get the IRQ number from DeviceTree

[Arnd Bergmann]

On Fri, Mar 7, 2025, at 23:03, Roman Kisel wrote:
> 
> +static int __maybe_unused vmbus_set_irq(struct platform_device *pdev)

Instead of the __maybe_unused annotation here

> 
> +#ifndef HYPERVISOR_CALLBACK_VECTOR
> +	ret = vmbus_set_irq(pdev);
> +	if (ret)
> +		return ret;
> +#endif
> +

you can use 

       if (!__is_defined(HYPERVISOR_CALLBACK_VECTOR))
                  ret = vmbus_set_irq(pdev);

and make it a little more readable.

    Arnd

Re: [PATCH hyperv-next v5 06/11] arm64, x86: hyperv: Report the VTL the system boots in

[Wei Liu]

On Fri, Mar 07, 2025 at 02:02:58PM -0800, Roman Kisel wrote:
> The hyperv guest code might run in various Virtual Trust Levels.
> 
> Report the level when the kernel boots in the non-default (0)
> one.
> 
> Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
> ---
>  arch/arm64/hyperv/mshyperv.c | 2 ++
>  arch/x86/hyperv/hv_vtl.c     | 2 +-
>  2 files changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/hyperv/mshyperv.c b/arch/arm64/hyperv/mshyperv.c
> index a7db03f5413d..3bc16dbee758 100644
> --- a/arch/arm64/hyperv/mshyperv.c
> +++ b/arch/arm64/hyperv/mshyperv.c
> @@ -108,6 +108,8 @@ static int __init hyperv_init(void)
>  	if (ms_hyperv.priv_high & HV_ACCESS_PARTITION_ID)
>  		hv_get_partition_id();
>  	ms_hyperv.vtl = get_vtl();
> +	if (ms_hyperv.vtl > 0) /* non default VTL */

"non-default".

> +		pr_info("Linux runs in Hyper-V Virtual Trust Level %d\n", ms_hyperv.vtl);
>  
>  	ms_hyperv_late_init();
>  
> diff --git a/arch/x86/hyperv/hv_vtl.c b/arch/x86/hyperv/hv_vtl.c
> index 4e1b1e3b5658..c21bee7e8ff3 100644
> --- a/arch/x86/hyperv/hv_vtl.c
> +++ b/arch/x86/hyperv/hv_vtl.c
> @@ -24,7 +24,7 @@ static bool __init hv_vtl_msi_ext_dest_id(void)
>  
>  void __init hv_vtl_init_platform(void)
>  {
> -	pr_info("Linux runs in Hyper-V Virtual Trust Level\n");
> +	pr_info("Linux runs in Hyper-V Virtual Trust Level %d\n", ms_hyperv.vtl);

Where isn't there a check for ms_hyperv.vtl > 0 here?

Please be consistent across different architectures.

>  
>  	x86_platform.realmode_reserve = x86_init_noop;
>  	x86_platform.realmode_init = x86_init_noop;
> -- 
> 2.43.0
> 
> 

Re: [PATCH hyperv-next v5 07/11] dt-bindings: microsoft,vmbus: Add interrupts and DMA coherence

[Krzysztof Kozlowski]

On Fri, Mar 07, 2025 at 02:02:59PM -0800, Roman Kisel wrote:
> To boot on ARM64, VMBus requires configuring interrupts. Missing
> DMA coherence property is sub-optimal as the VMBus transations are
> cache-coherent.
> 
> Add interrupts to be able to boot on ARM64. Add DMA coherence to
> avoid doing extra work on maintaining caches on ARM64.

How do you add it?

> 
> Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
> ---
>  .../devicetree/bindings/bus/microsoft,vmbus.yaml          | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/bus/microsoft,vmbus.yaml b/Documentation/devicetree/bindings/bus/microsoft,vmbus.yaml
> index a8d40c766dcd..3ab7d0116626 100644
> --- a/Documentation/devicetree/bindings/bus/microsoft,vmbus.yaml
> +++ b/Documentation/devicetree/bindings/bus/microsoft,vmbus.yaml
> @@ -28,13 +28,16 @@ properties:
>  required:
>    - compatible
>    - ranges
> +  - interrupts
>    - '#address-cells'
>    - '#size-cells'
>  
> -additionalProperties: false
> +additionalProperties: true

This is neither explained in commit msg nor correct.

Drop the change. You cannot have device bindings ending with 'true'
here - see talks, example-bindings, writing-schema and whatever resource
is there.

Best regards,
Krzysztof

Re: [PATCH hyperv-next v5 09/11] Drivers: hv: vmbus: Introduce hv_get_vmbus_root_device()

[Tianyu Lan]

On Sat, Mar 8, 2025 at 6:05 AM Roman Kisel <romank@linux.microsoft.com> wrote:
>
> The ARM64 PCI code for hyperv needs to know the VMBus root
> device, and it is private.
>
> Provide a function that returns it. Rename it from "hv_dev"
> as "hv_dev" as a symbol is very overloaded. No functional
> changes.
>
> Signed-off-by: Roman Kisel <romank@linux.microsoft.com>

Why change all device's parent to vmbus_root_device?

The ARM64 platform uses the device tree to enumerate vmbus
devices..  Can we find the root device via device tree? vmbus
code on the x86 use ACPI and it seems to work via ACPI.


> ---
>  drivers/hv/vmbus_drv.c | 23 +++++++++++++++--------
>  include/linux/hyperv.h |  2 ++
>  2 files changed, 17 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> index c8474b48dcd2..7bfafe702963 100644
> --- a/drivers/hv/vmbus_drv.c
> +++ b/drivers/hv/vmbus_drv.c
> @@ -45,7 +45,8 @@ struct vmbus_dynid {
>         struct hv_vmbus_device_id id;
>  };
>
> -static struct device  *hv_dev;
> +/* VMBus Root Device */
> +static struct device  *vmbus_root_device;
>
>  static int hyperv_cpuhp_online;
>
> @@ -80,9 +81,15 @@ static struct resource *fb_mmio;
>  static struct resource *hyperv_mmio;
>  static DEFINE_MUTEX(hyperv_mmio_lock);
>
> +struct device *hv_get_vmbus_root_device(void)
> +{
> +       return vmbus_root_device;
> +}
> +EXPORT_SYMBOL_GPL(hv_get_vmbus_root_device);
> +
>  static int vmbus_exists(void)
>  {
> -       if (hv_dev == NULL)
> +       if (vmbus_root_device == NULL)
>                 return -ENODEV;
>
>         return 0;
> @@ -861,7 +868,7 @@ static int vmbus_dma_configure(struct device *child_device)
>          * On x86/x64 coherence is assumed and these calls have no effect.
>          */
>         hv_setup_dma_ops(child_device,
> -               device_get_dma_attr(hv_dev) == DEV_DMA_COHERENT);
> +               device_get_dma_attr(vmbus_root_device) == DEV_DMA_COHERENT);
>         return 0;
>  }
>
> @@ -1930,7 +1937,7 @@ int vmbus_device_register(struct hv_device *child_device_obj)
>                      &child_device_obj->channel->offermsg.offer.if_instance);
>
>         child_device_obj->device.bus = &hv_bus;
> -       child_device_obj->device.parent = hv_dev;
> +       child_device_obj->device.parent = vmbus_root_device;
>         child_device_obj->device.release = vmbus_device_release;
>
>         child_device_obj->device.dma_parms = &child_device_obj->dma_parms;
> @@ -2292,7 +2299,7 @@ static int vmbus_acpi_add(struct platform_device *pdev)
>         struct acpi_device *ancestor;
>         struct acpi_device *device = ACPI_COMPANION(&pdev->dev);
>
> -       hv_dev = &device->dev;
> +       vmbus_root_device = &device->dev;
>
>         /*
>          * Older versions of Hyper-V for ARM64 fail to include the _CCA
> @@ -2383,7 +2390,7 @@ static int vmbus_device_add(struct platform_device *pdev)
>         struct device_node *np = pdev->dev.of_node;
>         int ret;
>
> -       hv_dev = &pdev->dev;
> +       vmbus_root_device = &pdev->dev;
>
>         ret = of_range_parser_init(&parser, np);
>         if (ret)
> @@ -2702,7 +2709,7 @@ static int __init hv_acpi_init(void)
>         if (ret)
>                 return ret;
>
> -       if (!hv_dev) {
> +       if (!vmbus_root_device) {
>                 ret = -ENODEV;
>                 goto cleanup;
>         }
> @@ -2733,7 +2740,7 @@ static int __init hv_acpi_init(void)
>
>  cleanup:
>         platform_driver_unregister(&vmbus_platform_driver);
> -       hv_dev = NULL;
> +       vmbus_root_device = NULL;
>         return ret;
>  }
>
> diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
> index 7f4f8d8bdf43..1f0851fde041 100644
> --- a/include/linux/hyperv.h
> +++ b/include/linux/hyperv.h
> @@ -1333,6 +1333,8 @@ static inline void *hv_get_drvdata(struct hv_device *dev)
>         return dev_get_drvdata(&dev->device);
>  }
>
> +struct device *hv_get_vmbus_root_device(void);
> +
>  struct hv_ring_buffer_debug_info {
>         u32 current_interrupt_mask;
>         u32 current_read_index;
> --
> 2.43.0
>
>


-- 
Thanks
Tianyu Lan

Re: [PATCH hyperv-next v5 04/11] Drivers: hv: Provide arch-neutral implementation of get_vtl()

[Tianyu Lan]

On Sat, Mar 8, 2025 at 6:04 AM Roman Kisel <romank@linux.microsoft.com> wrote:
>
> To run in the VTL mode, Hyper-V drivers have to know what
> VTL the system boots in, and the arm64/hyperv code does not
> have the means to compute that.
>
> Refactor the code to hoist the function that detects VTL,
> make it arch-neutral to be able to employ it to get the VTL
> on arm64.
>
> Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
> Reviewed-by: Michael Kelley <mhklinux@outlook.com>
> ---
Reviewed-by: Tianyu Lan <tiala@microsoft.com>

-- 
Thanks
Tianyu Lan

Re: [PATCH hyperv-next v5 11/11] PCI: hv: Get vPCI MSI IRQ domain from DeviceTree

[Bjorn Helgaas]

On Fri, Mar 07, 2025 at 02:03:03PM -0800, Roman Kisel wrote:
> The hyperv-pci driver uses ACPI for MSI IRQ domain configuration on
> arm64. It won't be able to do that in the VTL mode where only DeviceTree
> can be used.
> 
> Update the hyperv-pci driver to get vPCI MSI IRQ domain in the DeviceTree
> case, too.
> 
> Signed-off-by: Roman Kisel <romank@linux.microsoft.com>

A couple minor comments below, but I don't have any objection to this,
so if it's OK with the pci-hyperv.c folks, it's OK with me.

> +#ifdef CONFIG_OF
> +
> +static struct irq_domain *hv_pci_of_irq_domain_parent(void)
> +{
> +	struct device_node *parent;
> +	struct irq_domain *domain;
> +
> +	parent = of_irq_find_parent(hv_get_vmbus_root_device()->of_node);
> +	domain = NULL;
> +	if (parent) {
> +		domain = irq_find_host(parent);
> +		of_node_put(parent);
> +	}
> +
> +	return domain;

I think this would be a little simpler as:

  parent = of_irq_find_parent(hv_get_vmbus_root_device()->of_node);
  if (!parent)
    return NULL;

  domain = irq_find_host(parent);
  of_node_put(parent);
  return domain;

> +}
> +
> +#endif
> +
> +#ifdef CONFIG_ACPI
> +
> +static struct irq_domain *hv_pci_acpi_irq_domain_parent(void)
> +{
> +	struct irq_domain *domain;
> +	acpi_gsi_domain_disp_fn gsi_domain_disp_fn;
> +
> +	if (acpi_irq_model != ACPI_IRQ_MODEL_GIC)
> +		return NULL;
> +	gsi_domain_disp_fn = acpi_get_gsi_dispatcher();
> +	if (!gsi_domain_disp_fn)
> +		return NULL;
> +	domain = irq_find_matching_fwnode(gsi_domain_disp_fn(0),
> +				     DOMAIN_BUS_ANY);
> +
> +	if (!domain)
> +		return NULL;
> +
> +	return domain;

  if (!domain)
    return NULL;

  return domain;

is the same as:

  return domain;

or even just:

  return irq_find_matching_fwnode(gsi_domain_disp_fn(0), DOMAIN_BUS_ANY);

> +}

Re: [PATCH hyperv-next v5 06/11] arm64, x86: hyperv: Report the VTL the system boots in

[Roman Kisel]

On 3/9/2025 5:31 PM, Wei Liu wrote:
> On Fri, Mar 07, 2025 at 02:02:58PM -0800, Roman Kisel wrote:
>> The hyperv guest code might run in various Virtual Trust Levels.
>>
>> Report the level when the kernel boots in the non-default (0)
>> one.
>>
>> Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
>> ---
>>   arch/arm64/hyperv/mshyperv.c | 2 ++
>>   arch/x86/hyperv/hv_vtl.c     | 2 +-
>>   2 files changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/hyperv/mshyperv.c b/arch/arm64/hyperv/mshyperv.c
>> index a7db03f5413d..3bc16dbee758 100644
>> --- a/arch/arm64/hyperv/mshyperv.c
>> +++ b/arch/arm64/hyperv/mshyperv.c
>> @@ -108,6 +108,8 @@ static int __init hyperv_init(void)
>>   	if (ms_hyperv.priv_high & HV_ACCESS_PARTITION_ID)
>>   		hv_get_partition_id();
>>   	ms_hyperv.vtl = get_vtl();
>> +	if (ms_hyperv.vtl > 0) /* non default VTL */
> 
> "non-default".
> 

Thanks, will fix that!

>> +		pr_info("Linux runs in Hyper-V Virtual Trust Level %d\n", ms_hyperv.vtl);
>>   
>>   	ms_hyperv_late_init();
>>   
>> diff --git a/arch/x86/hyperv/hv_vtl.c b/arch/x86/hyperv/hv_vtl.c
>> index 4e1b1e3b5658..c21bee7e8ff3 100644
>> --- a/arch/x86/hyperv/hv_vtl.c
>> +++ b/arch/x86/hyperv/hv_vtl.c
>> @@ -24,7 +24,7 @@ static bool __init hv_vtl_msi_ext_dest_id(void)
>>   
>>   void __init hv_vtl_init_platform(void)
>>   {
>> -	pr_info("Linux runs in Hyper-V Virtual Trust Level\n");
>> +	pr_info("Linux runs in Hyper-V Virtual Trust Level %d\n", ms_hyperv.vtl);
> 
> Where isn't there a check for ms_hyperv.vtl > 0 here?
> 

On x86, there is

#ifdef CONFIG_HYPERV_VTL_MODE
void __init hv_vtl_init_platform(void);
int __init hv_vtl_early_init(void);
#else
static inline void __init hv_vtl_init_platform(void) {}
static inline int __init hv_vtl_early_init(void) { return 0; }
#endif

> Please be consistent across different architectures.
> 

In the earlier versions of the patch series, I had that piece
from the above mirrored in the arm64, and there was advice on
removing the function as it contained just one statement.
I'll revisit the approach, thanks for your help!

>>   
>>   	x86_platform.realmode_reserve = x86_init_noop;
>>   	x86_platform.realmode_init = x86_init_noop;
>> -- 
>> 2.43.0
>>
>>

-- 
Thank you,
Roman

Re: [PATCH hyperv-next v5 06/11] arm64, x86: hyperv: Report the VTL the system boots in

[Wei Liu]

On Mon, Mar 10, 2025 at 09:42:15AM -0700, Roman Kisel wrote:
> 
> 
> On 3/9/2025 5:31 PM, Wei Liu wrote:
> > On Fri, Mar 07, 2025 at 02:02:58PM -0800, Roman Kisel wrote:
> > > The hyperv guest code might run in various Virtual Trust Levels.
> > > 
> > > Report the level when the kernel boots in the non-default (0)
> > > one.
> > > 
> > > Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
> > > ---
> > >   arch/arm64/hyperv/mshyperv.c | 2 ++
> > >   arch/x86/hyperv/hv_vtl.c     | 2 +-
> > >   2 files changed, 3 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/arch/arm64/hyperv/mshyperv.c b/arch/arm64/hyperv/mshyperv.c
> > > index a7db03f5413d..3bc16dbee758 100644
> > > --- a/arch/arm64/hyperv/mshyperv.c
> > > +++ b/arch/arm64/hyperv/mshyperv.c
> > > @@ -108,6 +108,8 @@ static int __init hyperv_init(void)
> > >   	if (ms_hyperv.priv_high & HV_ACCESS_PARTITION_ID)
> > >   		hv_get_partition_id();
> > >   	ms_hyperv.vtl = get_vtl();
> > > +	if (ms_hyperv.vtl > 0) /* non default VTL */
> > 
> > "non-default".
> > 
> 
> Thanks, will fix that!
> 
> > > +		pr_info("Linux runs in Hyper-V Virtual Trust Level %d\n", ms_hyperv.vtl);
> > >   	ms_hyperv_late_init();
> > > diff --git a/arch/x86/hyperv/hv_vtl.c b/arch/x86/hyperv/hv_vtl.c
> > > index 4e1b1e3b5658..c21bee7e8ff3 100644
> > > --- a/arch/x86/hyperv/hv_vtl.c
> > > +++ b/arch/x86/hyperv/hv_vtl.c
> > > @@ -24,7 +24,7 @@ static bool __init hv_vtl_msi_ext_dest_id(void)
> > >   void __init hv_vtl_init_platform(void)
> > >   {
> > > -	pr_info("Linux runs in Hyper-V Virtual Trust Level\n");
> > > +	pr_info("Linux runs in Hyper-V Virtual Trust Level %d\n", ms_hyperv.vtl);
> > 
> > Where isn't there a check for ms_hyperv.vtl > 0 here?
> > 
> 
> On x86, there is
> 
> #ifdef CONFIG_HYPERV_VTL_MODE
> void __init hv_vtl_init_platform(void);
> int __init hv_vtl_early_init(void);
> #else
> static inline void __init hv_vtl_init_platform(void) {}
> static inline int __init hv_vtl_early_init(void) { return 0; }
> #endif
> 
> > Please be consistent across different architectures.
> > 
> 
> In the earlier versions of the patch series, I had that piece
> from the above mirrored in the arm64, and there was advice on
> removing the function as it contained just one statement.
> I'll revisit the approach, thanks for your help!

As long as the output is consistent across different architectures, I'm
good.

Wei.

> 
> > >   	x86_platform.realmode_reserve = x86_init_noop;
> > >   	x86_platform.realmode_init = x86_init_noop;
> > > -- 
> > > 2.43.0
> > > 
> > > 
> 
> -- 
> Thank you,
> Roman
> 

Re: [PATCH hyperv-next v5 07/11] dt-bindings: microsoft,vmbus: Add interrupts and DMA coherence

[Roman Kisel]

On 3/10/2025 2:28 AM, Krzysztof Kozlowski wrote:
> On Fri, Mar 07, 2025 at 02:02:59PM -0800, Roman Kisel wrote:
>> To boot on ARM64, VMBus requires configuring interrupts. Missing
>> DMA coherence property is sub-optimal as the VMBus transations are
>> cache-coherent.
>>
>> Add interrupts to be able to boot on ARM64. Add DMA coherence to
>> avoid doing extra work on maintaining caches on ARM64.
> 
> How do you add it?
> 

I added properties to the node. Should I fix the description, or I am
misunderstanding the question?

>>
>> Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
>> ---
>>   .../devicetree/bindings/bus/microsoft,vmbus.yaml          | 8 +++++++-
>>   1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/bus/microsoft,vmbus.yaml b/Documentation/devicetree/bindings/bus/microsoft,vmbus.yaml
>> index a8d40c766dcd..3ab7d0116626 100644
>> --- a/Documentation/devicetree/bindings/bus/microsoft,vmbus.yaml
>> +++ b/Documentation/devicetree/bindings/bus/microsoft,vmbus.yaml
>> @@ -28,13 +28,16 @@ properties:
>>   required:
>>     - compatible
>>     - ranges
>> +  - interrupts
>>     - '#address-cells'
>>     - '#size-cells'
>>   
>> -additionalProperties: false
>> +additionalProperties: true
> 
> This is neither explained in commit msg nor correct.
> 

Not explained, as there is no good explanation as described below.

> Drop the change. You cannot have device bindings ending with 'true'
> here - see talks, example-bindings, writing-schema and whatever resource
> is there.
> 

Thanks, I'll put more effort into bringing this into a better form!
If you have time, could you comment on the below?

The Documentation says

   * additionalProperties: true
     Rare case, used for schemas implementing common set of properties.
Such schemas are supposed to be referenced by other schemas, which then 
use 'unevaluatedProperties: false'.  Typically bus or common-part schemas.

This is a bus so I added that line to the YAML, and I saw it in many
other YAML files. Without that line, there was a warning from the local
DT validation described in the Documentation about not having pin
controls which was weird, and adding

"additionalProperties: true"

fixed the warnings (didn't debug much though). As a side note, there was
a similar warning coming from another YAML during running DT schema
validation as described in the Documentation so maybe warnings are fine.

> Best regards,
> Krzysztof
> 

-- 
Thank you,
Roman

Re: [PATCH hyperv-next v5 09/11] Drivers: hv: vmbus: Introduce hv_get_vmbus_root_device()

[Roman Kisel]

On 3/10/2025 6:41 AM, Tianyu Lan wrote:
> On Sat, Mar 8, 2025 at 6:05 AM Roman Kisel <romank@linux.microsoft.com> wrote:
>>
>> The ARM64 PCI code for hyperv needs to know the VMBus root
>> device, and it is private.
>>
>> Provide a function that returns it. Rename it from "hv_dev"
>> as "hv_dev" as a symbol is very overloaded. No functional
>> changes.
>>
>> Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
> 
> Why change all device's parent to vmbus_root_device?
> 

No changes from my account of the code. Please let me know if I am
misunderstanding the question.

> The ARM64 platform uses the device tree to enumerate vmbus
> devices..  Can we find the root device via device tree? vmbus
> code on the x86 use ACPI and it seems to work via ACPI.
> 
> 

Right, we find it from the DT as shown in the next patch:

+static struct irq_domain *hv_pci_of_irq_domain_parent(void)
+{
+	struct device_node *parent;
+	struct irq_domain *domain;
+
+	parent = of_irq_find_parent(hv_get_vmbus_root_device()->of_node);
+	domain = NULL;
+	if (parent) {
+		domain = irq_find_host(parent);
+		of_node_put(parent);
+	}
+
+	return domain;
+}
+

and later use it for `irq_create_hierarchy()`. Please let me know
if I missed anything in your question.

>> ---
>>   drivers/hv/vmbus_drv.c | 23 +++++++++++++++--------
>>   include/linux/hyperv.h |  2 ++
>>   2 files changed, 17 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
>> index c8474b48dcd2..7bfafe702963 100644
>> --- a/drivers/hv/vmbus_drv.c
>> +++ b/drivers/hv/vmbus_drv.c
>> @@ -45,7 +45,8 @@ struct vmbus_dynid {
>>          struct hv_vmbus_device_id id;
>>   };
>>
>> -static struct device  *hv_dev;
>> +/* VMBus Root Device */
>> +static struct device  *vmbus_root_device;
>>
>>   static int hyperv_cpuhp_online;
>>
>> @@ -80,9 +81,15 @@ static struct resource *fb_mmio;
>>   static struct resource *hyperv_mmio;
>>   static DEFINE_MUTEX(hyperv_mmio_lock);
>>
>> +struct device *hv_get_vmbus_root_device(void)
>> +{
>> +       return vmbus_root_device;
>> +}
>> +EXPORT_SYMBOL_GPL(hv_get_vmbus_root_device);
>> +
>>   static int vmbus_exists(void)
>>   {
>> -       if (hv_dev == NULL)
>> +       if (vmbus_root_device == NULL)
>>                  return -ENODEV;
>>
>>          return 0;
>> @@ -861,7 +868,7 @@ static int vmbus_dma_configure(struct device *child_device)
>>           * On x86/x64 coherence is assumed and these calls have no effect.
>>           */
>>          hv_setup_dma_ops(child_device,
>> -               device_get_dma_attr(hv_dev) == DEV_DMA_COHERENT);
>> +               device_get_dma_attr(vmbus_root_device) == DEV_DMA_COHERENT);
>>          return 0;
>>   }
>>
>> @@ -1930,7 +1937,7 @@ int vmbus_device_register(struct hv_device *child_device_obj)
>>                       &child_device_obj->channel->offermsg.offer.if_instance);
>>
>>          child_device_obj->device.bus = &hv_bus;
>> -       child_device_obj->device.parent = hv_dev;
>> +       child_device_obj->device.parent = vmbus_root_device;
>>          child_device_obj->device.release = vmbus_device_release;
>>
>>          child_device_obj->device.dma_parms = &child_device_obj->dma_parms;
>> @@ -2292,7 +2299,7 @@ static int vmbus_acpi_add(struct platform_device *pdev)
>>          struct acpi_device *ancestor;
>>          struct acpi_device *device = ACPI_COMPANION(&pdev->dev);
>>
>> -       hv_dev = &device->dev;
>> +       vmbus_root_device = &device->dev;
>>
>>          /*
>>           * Older versions of Hyper-V for ARM64 fail to include the _CCA
>> @@ -2383,7 +2390,7 @@ static int vmbus_device_add(struct platform_device *pdev)
>>          struct device_node *np = pdev->dev.of_node;
>>          int ret;
>>
>> -       hv_dev = &pdev->dev;
>> +       vmbus_root_device = &pdev->dev;
>>
>>          ret = of_range_parser_init(&parser, np);
>>          if (ret)
>> @@ -2702,7 +2709,7 @@ static int __init hv_acpi_init(void)
>>          if (ret)
>>                  return ret;
>>
>> -       if (!hv_dev) {
>> +       if (!vmbus_root_device) {
>>                  ret = -ENODEV;
>>                  goto cleanup;
>>          }
>> @@ -2733,7 +2740,7 @@ static int __init hv_acpi_init(void)
>>
>>   cleanup:
>>          platform_driver_unregister(&vmbus_platform_driver);
>> -       hv_dev = NULL;
>> +       vmbus_root_device = NULL;
>>          return ret;
>>   }
>>
>> diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
>> index 7f4f8d8bdf43..1f0851fde041 100644
>> --- a/include/linux/hyperv.h
>> +++ b/include/linux/hyperv.h
>> @@ -1333,6 +1333,8 @@ static inline void *hv_get_drvdata(struct hv_device *dev)
>>          return dev_get_drvdata(&dev->device);
>>   }
>>
>> +struct device *hv_get_vmbus_root_device(void);
>> +
>>   struct hv_ring_buffer_debug_info {
>>          u32 current_interrupt_mask;
>>          u32 current_read_index;
>> --
>> 2.43.0
>>
>>
> 
> 

-- 
Thank you,
Roman

Re: [PATCH hyperv-next v5 11/11] PCI: hv: Get vPCI MSI IRQ domain from DeviceTree

[Roman Kisel]

On 3/10/2025 9:41 AM, Bjorn Helgaas wrote:
> On Fri, Mar 07, 2025 at 02:03:03PM -0800, Roman Kisel wrote:
>> The hyperv-pci driver uses ACPI for MSI IRQ domain configuration on
>> arm64. It won't be able to do that in the VTL mode where only DeviceTree
>> can be used.
>>
>> Update the hyperv-pci driver to get vPCI MSI IRQ domain in the DeviceTree
>> case, too.
>>
>> Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
> 
> A couple minor comments below, but I don't have any objection to this,
> so if it's OK with the pci-hyperv.c folks, it's OK with me.
> 

Bjorn, thanks a lot for your help and guidance! I'll be most happy to
incorporate your suggestions into the next version of the series :)

>> +#ifdef CONFIG_OF
>> +
>> +static struct irq_domain *hv_pci_of_irq_domain_parent(void)
>> +{
>> +	struct device_node *parent;
>> +	struct irq_domain *domain;
>> +
>> +	parent = of_irq_find_parent(hv_get_vmbus_root_device()->of_node);
>> +	domain = NULL;
>> +	if (parent) {
>> +		domain = irq_find_host(parent);
>> +		of_node_put(parent);
>> +	}
>> +
>> +	return domain;
> 
> I think this would be a little simpler as:
> 
>    parent = of_irq_find_parent(hv_get_vmbus_root_device()->of_node);
>    if (!parent)
>      return NULL;
> 
>    domain = irq_find_host(parent);
>    of_node_put(parent);
>    return domain;
> 
>> +}
>> +
>> +#endif
>> +
>> +#ifdef CONFIG_ACPI
>> +
>> +static struct irq_domain *hv_pci_acpi_irq_domain_parent(void)
>> +{
>> +	struct irq_domain *domain;
>> +	acpi_gsi_domain_disp_fn gsi_domain_disp_fn;
>> +
>> +	if (acpi_irq_model != ACPI_IRQ_MODEL_GIC)
>> +		return NULL;
>> +	gsi_domain_disp_fn = acpi_get_gsi_dispatcher();
>> +	if (!gsi_domain_disp_fn)
>> +		return NULL;
>> +	domain = irq_find_matching_fwnode(gsi_domain_disp_fn(0),
>> +				     DOMAIN_BUS_ANY);
>> +
>> +	if (!domain)
>> +		return NULL;
>> +
>> +	return domain;
> 
>    if (!domain)
>      return NULL;
> 
>    return domain;
> 
> is the same as:
> 
>    return domain;
> 
> or even just:
> 
>    return irq_find_matching_fwnode(gsi_domain_disp_fn(0), DOMAIN_BUS_ANY);
> 
>> +}

-- 
Thank you,
Roman

Re: [PATCH hyperv-next v5 06/11] arm64, x86: hyperv: Report the VTL the system boots in

[Roman Kisel]

On 3/10/2025 9:53 AM, Wei Liu wrote:
> On Mon, Mar 10, 2025 at 09:42:15AM -0700, Roman Kisel wrote:

[...]

>>
>>> Please be consistent across different architectures.
>>>
>>
>> In the earlier versions of the patch series, I had that piece
>> from the above mirrored in the arm64, and there was advice on
>> removing the function as it contained just one statement.
>> I'll revisit the approach, thanks for your help!
> 
> As long as the output is consistent across different architectures, I'm
> good.

I should add a comment most likely to save people some time grepping
the code as the line does look like should always print that. IOW
not printing for VTL0 is obscured by the preprocessor/#define cruft.

> 
> Wei.
> 
>>
>>>>    	x86_platform.realmode_reserve = x86_init_noop;
>>>>    	x86_platform.realmode_init = x86_init_noop;
>>>> -- 
>>>> 2.43.0
>>>>
>>>>
>>
>> -- 
>> Thank you,
>> Roman
>>

-- 
Thank you,
Roman

Re: [PATCH hyperv-next v5 03/11] Drivers: hv: Enable VTL mode for arm64

[Roman Kisel]

On 3/8/2025 1:05 PM, Arnd Bergmann wrote:
> On Fri, Mar 7, 2025, at 23:02, Roman Kisel wrote:
>> @@ -5,18 +5,20 @@ menu "Microsoft Hyper-V guest support"
>>   config HYPERV
>>   	tristate "Microsoft Hyper-V client drivers"
>>   	depends on (X86 && X86_LOCAL_APIC && HYPERVISOR_GUEST) \
>> -		|| (ACPI && ARM64 && !CPU_BIG_ENDIAN)
>> +		|| (ARM64 && !CPU_BIG_ENDIAN)
>> +	depends on (ACPI || HYPERV_VTL_MODE)
>>   	select PARAVIRT
>>   	select X86_HV_CALLBACK_VECTOR if X86
>> -	select OF_EARLY_FLATTREE if OF
>>   	help
>>   	  Select this option to run Linux as a Hyper-V client operating
>>   	  system.
>>
>>   config HYPERV_VTL_MODE
>>   	bool "Enable Linux to boot in VTL context"
>> -	depends on X86_64 && HYPERV
>> +	depends on (X86_64 || ARM64)
>>   	depends on SMP
>> +	select OF_EARLY_FLATTREE
>> +	select OF
>>   	default n
>>   	help
> 
> Having the dependency below the top-level Kconfig entry feels a little
> counterintuitive. You could flip that back as it was before by doing
> 
>        select HYPERV_VTL_MODE if !ACPI
>        depends on ACPI || SMP
> 
> in the HYPERV option, leaving the dependency on HYPERV in
> HYPERV_VTL_MODE.
> 

I was implementing Michael's suggestion, and might've gone a bit
overboard, my bad. I'll fix this, thanks a lot for reviewing!

> Is OF_EARLY_FLATTREE actually needed on x86?
> 

No, it is not needed on x86. It is only needed when VTL mode is used.

>        Arnd

-- 
Thank you,
Roman

Re: [PATCH hyperv-next v5 08/11] Drivers: hv: vmbus: Get the IRQ number from DeviceTree

[Roman Kisel]

On 3/8/2025 1:11 PM, Arnd Bergmann wrote:
> On Fri, Mar 7, 2025, at 23:03, Roman Kisel wrote:
>>
>> +static int __maybe_unused vmbus_set_irq(struct platform_device *pdev)
> 
> Instead of the __maybe_unused annotation here
> 
>>
>> +#ifndef HYPERVISOR_CALLBACK_VECTOR
>> +	ret = vmbus_set_irq(pdev);
>> +	if (ret)
>> +		return ret;
>> +#endif
>> +
> 
> you can use
> 
>         if (!__is_defined(HYPERVISOR_CALLBACK_VECTOR))
>                    ret = vmbus_set_irq(pdev);
> 
> and make it a little more readable.
> 

Thanks you very much, will update! Very neat :)

>      Arnd

-- 
Thank you,
Roman

Re: [PATCH hyperv-next v5 07/11] dt-bindings: microsoft,vmbus: Add interrupts and DMA coherence

[Krzysztof Kozlowski]

On 10/03/2025 18:05, Roman Kisel wrote:
> 
> 
> On 3/10/2025 2:28 AM, Krzysztof Kozlowski wrote:
>> On Fri, Mar 07, 2025 at 02:02:59PM -0800, Roman Kisel wrote:
>>> To boot on ARM64, VMBus requires configuring interrupts. Missing
>>> DMA coherence property is sub-optimal as the VMBus transations are
>>> cache-coherent.
>>>
>>> Add interrupts to be able to boot on ARM64. Add DMA coherence to
>>> avoid doing extra work on maintaining caches on ARM64.
>>
>> How do you add it?
>>
> 
> I added properties to the node. Should I fix the description, or I am
> misunderstanding the question?

I saw interrupts in the schema, but I did not see dma-coherence. I also
did not see any DTS patches here, so I don't understand what node you
are referring to.

> 
>>>
>>> Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
>>> ---
>>>   .../devicetree/bindings/bus/microsoft,vmbus.yaml          | 8 +++++++-
>>>   1 file changed, 7 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/bus/microsoft,vmbus.yaml b/Documentation/devicetree/bindings/bus/microsoft,vmbus.yaml
>>> index a8d40c766dcd..3ab7d0116626 100644
>>> --- a/Documentation/devicetree/bindings/bus/microsoft,vmbus.yaml
>>> +++ b/Documentation/devicetree/bindings/bus/microsoft,vmbus.yaml
>>> @@ -28,13 +28,16 @@ properties:
>>>   required:
>>>     - compatible
>>>     - ranges
>>> +  - interrupts
>>>     - '#address-cells'
>>>     - '#size-cells'
>>>   
>>> -additionalProperties: false
>>> +additionalProperties: true
>>
>> This is neither explained in commit msg nor correct.
>>
> 
> Not explained, as there is no good explanation as described below.
> 
>> Drop the change. You cannot have device bindings ending with 'true'
>> here - see talks, example-bindings, writing-schema and whatever resource
>> is there.
>>
> 
> Thanks, I'll put more effort into bringing this into a better form!
> If you have time, could you comment on the below?
> 
> The Documentation says
> 
>    * additionalProperties: true
>      Rare case, used for schemas implementing common set of properties.
> Such schemas are supposed to be referenced by other schemas, which then 
> use 'unevaluatedProperties: false'.  Typically bus or common-part schemas.
> 
> This is a bus so I added that line to the YAML, and I saw it in many

If this is a bus, then where is schema using it for
bus-attached-devices? You cannot have bus without devices.

You *must* fulfill that part:
"Such schemas are supposed to be referenced by other schemas, which then"

instead of calling it bus...

Please upstream bindings for the bus devices and extend the example here
with these devices.

Or this is not bus (calling something vmpony does not make it a pony).


Best regards,
Krzysztof

Re: [PATCH hyperv-next v5 07/11] dt-bindings: microsoft,vmbus: Add interrupts and DMA coherence

[Roman Kisel]

On 3/10/2025 10:40 AM, Krzysztof Kozlowski wrote:
> On 10/03/2025 18:05, Roman Kisel wrote:
>>
>>
>> On 3/10/2025 2:28 AM, Krzysztof Kozlowski wrote:
>>> On Fri, Mar 07, 2025 at 02:02:59PM -0800, Roman Kisel wrote:
>>>> To boot on ARM64, VMBus requires configuring interrupts. Missing
>>>> DMA coherence property is sub-optimal as the VMBus transations are
>>>> cache-coherent.
>>>>
>>>> Add interrupts to be able to boot on ARM64. Add DMA coherence to
>>>> avoid doing extra work on maintaining caches on ARM64.
>>>
>>> How do you add it?
>>>
>>
>> I added properties to the node. Should I fix the description, or I am
>> misunderstanding the question?
> 
> I saw interrupts in the schema, but I did not see dma-coherence. I also
> did not see any DTS patches here, so I don't understand what node you
> are referring to.
> 

I will refer to talks, example-bindings, writing-schema you've suggested
to waste your time less. It appears there is some fundamental flaw in my
understanding of how these YAML files work so much so that I cannot even
write a commit description that can be understood, for the 5th time in
the row, sorry about that.

>>
>>>>
>>>> Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
>>>> ---
>>>>    .../devicetree/bindings/bus/microsoft,vmbus.yaml          | 8 +++++++-
>>>>    1 file changed, 7 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/bus/microsoft,vmbus.yaml b/Documentation/devicetree/bindings/bus/microsoft,vmbus.yaml
>>>> index a8d40c766dcd..3ab7d0116626 100644
>>>> --- a/Documentation/devicetree/bindings/bus/microsoft,vmbus.yaml
>>>> +++ b/Documentation/devicetree/bindings/bus/microsoft,vmbus.yaml
>>>> @@ -28,13 +28,16 @@ properties:
>>>>    required:
>>>>      - compatible
>>>>      - ranges
>>>> +  - interrupts
>>>>      - '#address-cells'
>>>>      - '#size-cells'
>>>>    
>>>> -additionalProperties: false
>>>> +additionalProperties: true
>>>
>>> This is neither explained in commit msg nor correct.
>>>
>>
>> Not explained, as there is no good explanation as described below.
>>
>>> Drop the change. You cannot have device bindings ending with 'true'
>>> here - see talks, example-bindings, writing-schema and whatever resource
>>> is there.
>>>
>>
>> Thanks, I'll put more effort into bringing this into a better form!
>> If you have time, could you comment on the below?
>>
>> The Documentation says
>>
>>     * additionalProperties: true
>>       Rare case, used for schemas implementing common set of properties.
>> Such schemas are supposed to be referenced by other schemas, which then
>> use 'unevaluatedProperties: false'.  Typically bus or common-part schemas.
>>
>> This is a bus so I added that line to the YAML, and I saw it in many
> 
> If this is a bus, then where is schema using it for
> bus-attached-devices? You cannot have bus without devices.
> 
> You *must* fulfill that part:
> "Such schemas are supposed to be referenced by other schemas, which then"
> 
> instead of calling it bus...
> 

It is modeled as a bus in the kernel:
https://www.kernel.org/doc/html/latest/virt/hyperv/vmbus.html

> Please upstream bindings for the bus devices and extend the example here
> with these devices.

The set of synthetic devices that reside on the bus isn't fixed, and
they don't require description neither in ACPI nor in DT as
the devices negotiate their MMIO regions through the hyperv driver.

Perhaps, it is not as much bus as expected by the YAML files.

> 
> Or this is not bus (calling something vmpony does not make it a pony).
> 
 > > Best regards,
> Krzysztof

-- 
Thank you,
Roman

RE: [PATCH hyperv-next v5 03/11] Drivers: hv: Enable VTL mode for arm64

[Michael Kelley]

From: Arnd Bergmann <arnd@arndb.de> Sent: Saturday, March 8, 2025 1:05 PM
> 
> On Fri, Mar 7, 2025, at 23:02, Roman Kisel wrote:
> > @@ -5,18 +5,20 @@ menu "Microsoft Hyper-V guest support"
> >  config HYPERV
> >  	tristate "Microsoft Hyper-V client drivers"
> >  	depends on (X86 && X86_LOCAL_APIC && HYPERVISOR_GUEST) \
> > -		|| (ACPI && ARM64 && !CPU_BIG_ENDIAN)
> > +		|| (ARM64 && !CPU_BIG_ENDIAN)
> > +	depends on (ACPI || HYPERV_VTL_MODE)
> >  	select PARAVIRT
> >  	select X86_HV_CALLBACK_VECTOR if X86
> > -	select OF_EARLY_FLATTREE if OF
> >  	help
> >  	  Select this option to run Linux as a Hyper-V client operating
> >  	  system.
> >
> >  config HYPERV_VTL_MODE
> >  	bool "Enable Linux to boot in VTL context"
> > -	depends on X86_64 && HYPERV
> > +	depends on (X86_64 || ARM64)
> >  	depends on SMP
> > +	select OF_EARLY_FLATTREE
> > +	select OF
> >  	default n
> >  	help
> 
> Having the dependency below the top-level Kconfig entry feels a little
> counterintuitive. You could flip that back as it was before by doing
> 
>       select HYPERV_VTL_MODE if !ACPI
>       depends on ACPI || SMP
> 
> in the HYPERV option, leaving the dependency on HYPERV in
> HYPERV_VTL_MODE.

I would argue that we don't ever want to implicitly select
HYPERV_VTL_MODE because of some other config setting or
lack thereof.  VTL mode is enough of a special case that it should
only be explicitly selected. If someone omits ACPI, then HYPERV
should not be selectable unless HYPERV_VTL_MODE is explicitly
selected.

The last line of the comment for HYPERV_VTL_MODE says
"A kernel built with this option must run at VTL2, and will not run
as a normal guest."  In other words, don't choose this unless you
100% know that VTL2 is what you want.

Michael

> 
> Is OF_EARLY_FLATTREE actually needed on x86?
> 
>       Arnd

RE: [PATCH hyperv-next v5 01/11] arm64: kvm, smccc: Introduce and use API for detectting hypervisor presence

[Michael Kelley]

From: Roman Kisel <romank@linux.microsoft.com> Sent: Friday, March 7, 2025 2:03 PM
> 

In the Subject line,

s/detectting/detecting/

> The KVM/arm64 uses SMCCC to detect hypervisor presence. That code is
> private, and it follows the SMCCC specification. Other existing and
> emerging hypervisor guest implementations can and should use that
> standard approach as well.
> 
> Factor out a common infrastructure that the guests can use, update KVM
> to employ the new API. The cenrtal notion of the SMCCC method is the

s/cenrtal/central/

> UUID of the hypervisor, and the API follows that.
> 
> No functional changes. Validated with a KVM/arm64 guest.
> 
> Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
> ---
>  arch/arm64/kvm/hypercalls.c        |  5 +--
>  drivers/firmware/smccc/kvm_guest.c | 10 ++----
>  drivers/firmware/smccc/smccc.c     | 19 +++++++++++
>  include/linux/arm-smccc.h          | 55 +++++++++++++++++++++++++++---
>  4 files changed, 73 insertions(+), 16 deletions(-)
> 
> diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> index 27ce4cb44904..92b9bc1ea8e8 100644
> --- a/arch/arm64/kvm/hypercalls.c
> +++ b/arch/arm64/kvm/hypercalls.c
> @@ -353,10 +353,7 @@ int kvm_smccc_call_handler(struct kvm_vcpu *vcpu)
>  			val[0] = gpa;
>  		break;
>  	case ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID:
> -		val[0] = ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_0;
> -		val[1] = ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_1;
> -		val[2] = ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_2;
> -		val[3] = ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_3;
> +		UUID_TO_SMCCC_RES(ARM_SMCCC_VENDOR_HYP_UID_KVM, val);
>  		break;
>  	case ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID:
>  		val[0] = smccc_feat->vendor_hyp_bmap;
> diff --git a/drivers/firmware/smccc/kvm_guest.c b/drivers/firmware/smccc/kvm_guest.c
> index f3319be20b36..b5084b309ea0 100644
> --- a/drivers/firmware/smccc/kvm_guest.c
> +++ b/drivers/firmware/smccc/kvm_guest.c
> @@ -14,17 +14,11 @@ static DECLARE_BITMAP(__kvm_arm_hyp_services,
> ARM_SMCCC_KVM_NUM_FUNCS) __ro_afte
> 
>  void __init kvm_init_hyp_services(void)
>  {
> +	uuid_t kvm_uuid = ARM_SMCCC_VENDOR_HYP_UID_KVM;
>  	struct arm_smccc_res res;
>  	u32 val[4];
> 
> -	if (arm_smccc_1_1_get_conduit() != SMCCC_CONDUIT_HVC)
> -		return;
> -
> -	arm_smccc_1_1_invoke(ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID, &res);
> -	if (res.a0 != ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_0 ||
> -	    res.a1 != ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_1 ||
> -	    res.a2 != ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_2 ||
> -	    res.a3 != ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_3)
> +	if (!arm_smccc_hyp_present(&kvm_uuid))
>  		return;
> 
>  	memset(&res, 0, sizeof(res));
> diff --git a/drivers/firmware/smccc/smccc.c b/drivers/firmware/smccc/smccc.c
> index a74600d9f2d7..7399f27d58e5 100644
> --- a/drivers/firmware/smccc/smccc.c
> +++ b/drivers/firmware/smccc/smccc.c
> @@ -67,6 +67,25 @@ s32 arm_smccc_get_soc_id_revision(void)
>  }
>  EXPORT_SYMBOL_GPL(arm_smccc_get_soc_id_revision);
> 
> +bool arm_smccc_hyp_present(const uuid_t *hyp_uuid)
> +{
> +	struct arm_smccc_res res = {};
> +
> +	if (arm_smccc_1_1_get_conduit() != SMCCC_CONDUIT_HVC)
> +		return false;
> +	arm_smccc_1_1_hvc(ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID, &res);
> +	if (res.a0 == SMCCC_RET_NOT_SUPPORTED)
> +		return false;
> +
> +	return ({
> +		const uuid_t uuid = SMCCC_RES_TO_UUID(res.a0, res.a1, res.a2, res.a3);
> +		const bool present = uuid_equal(&uuid, hyp_uuid);
> +
> +		present;
> +	});
> +}
> +EXPORT_SYMBOL_GPL(arm_smccc_hyp_present);
> +
>  static int __init smccc_devices_init(void)
>  {
>  	struct platform_device *pdev;
> diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
> index 67f6fdf2e7cd..726f18221f1c 100644
> --- a/include/linux/arm-smccc.h
> +++ b/include/linux/arm-smccc.h
> @@ -7,6 +7,11 @@
> 
>  #include <linux/args.h>
>  #include <linux/init.h>
> +
> +#ifndef __ASSEMBLER__
> +#include <linux/uuid.h>
> +#endif
> +
>  #include <uapi/linux/const.h>
> 
>  /*
> @@ -107,10 +112,10 @@
>  			   ARM_SMCCC_FUNC_QUERY_CALL_UID)
> 
>  /* KVM UID value: 28b46fb6-2ec5-11e9-a9ca-4b564d003a74 */
> -#define ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_0	0xb66fb428U
> -#define ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_1	0xe911c52eU
> -#define ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_2	0x564bcaa9U
> -#define ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_3	0x743a004dU
> +#define ARM_SMCCC_VENDOR_HYP_UID_KVM UUID_INIT(\
> +	0xb66fb428, 0xc52e, 0xe911, \
> +	0xa9, 0xca, 0x4b, 0x56, \
> +	0x4d, 0x00, 0x3a, 0x74)
> 
>  /* KVM "vendor specific" services */
>  #define ARM_SMCCC_KVM_FUNC_FEATURES		0
> @@ -333,6 +338,48 @@ s32 arm_smccc_get_soc_id_version(void);
>   */
>  s32 arm_smccc_get_soc_id_revision(void);
> 
> +#ifndef __ASSEMBLER__
> +
> +/**
> + * arm_smccc_hyp_present(const uuid_t *hyp_uuid)
> + *
> + * Returns `true` if the hypervisor advertises its presence via SMCCC.
> + *
> + * When the function returns `false`, the caller shall not assume that
> + * there is no hypervisor running. Instead, the caller must fall back to
> + * other approaches if any are available.
> + */
> +bool arm_smccc_hyp_present(const uuid_t *hyp_uuid);
> +
> +#define SMCCC_RES_TO_UUID(r0, r1, r2, r3) \
> +	UUID_INIT( \
> +		cpu_to_le32(lower_32_bits(r0)), \
> +		cpu_to_le32(lower_32_bits(r1)) & 0xffff, \
> +		cpu_to_le32(lower_32_bits(r1)) >> 16, \
> +		cpu_to_le32(lower_32_bits(r2)) & 0xff, \
> +		(cpu_to_le32(lower_32_bits(r2)) >> 8) & 0xff, \
> +		(cpu_to_le32(lower_32_bits(r2)) >> 16) & 0xff, \
> +		(cpu_to_le32(lower_32_bits(r2)) >> 24) & 0xff, \
> +		cpu_to_le32(lower_32_bits(r3)) & 0xff, \
> +		(cpu_to_le32(lower_32_bits(r3)) >> 8) & 0xff, \
> +		(cpu_to_le32(lower_32_bits(r3)) >> 16) & 0xff, \
> +		(cpu_to_le32(lower_32_bits(r3)) >> 24) & 0xff \
> +	)
> +
> +#define UUID_TO_SMCCC_RES(uuid_init, regs) do { \
> +		const uuid_t uuid = uuid_init; \
> +		(regs)[0] = le32_to_cpu((u32)uuid.b[0] | (uuid.b[1] << 8) | \
> +						((uuid.b[2]) << 16) | ((uuid.b[3]) << 24));
> \
> +		(regs)[1] = le32_to_cpu((u32)uuid.b[4] | (uuid.b[5] << 8) | \
> +						((uuid.b[6]) << 16) | ((uuid.b[7]) << 24));
> \
> +		(regs)[2] = le32_to_cpu((u32)uuid.b[8] | (uuid.b[9] << 8) | \
> +						((uuid.b[10]) << 16) | ((uuid.b[11]) <<
> 24)); \
> +		(regs)[3] = le32_to_cpu((u32)uuid.b[12] | (uuid.b[13] << 8) | \
> +						((uuid.b[14]) << 16) | ((uuid.b[15]) <<
> 24)); \
> +	} while (0)
> +
> +#endif /* !__ASSEMBLER__ */
> +
>  /**
>   * struct arm_smccc_res - Result from SMC/HVC call
>   * @a0-a3 result values from registers 0 to 3
> --
> 2.43.0
> 

Re: [PATCH hyperv-next v5 07/11] dt-bindings: microsoft,vmbus: Add interrupts and DMA coherence

[Krzysztof Kozlowski]

On 10/03/2025 19:07, Roman Kisel wrote:
> 
> It is modeled as a bus in the kernel:
> https://www.kernel.org/doc/html/latest/virt/hyperv/vmbus.html
> 
>> Please upstream bindings for the bus devices and extend the example here
>> with these devices.
> 
> The set of synthetic devices that reside on the bus isn't fixed, and
> they don't require description neither in ACPI nor in DT as
> the devices negotiate their MMIO regions through the hyperv driver.
> 
> Perhaps, it is not as much bus as expected by the YAML files.

OK, then this is not really a bus from the bindings point of view. It is
a device schema which should end with additionalProperties: false.

If you have report about that pinctrl-0, it means you have undocumented
properties in your DTS. Maybe that's the dma-coherence you mentioned in
the commit msg.


Best regards,
Krzysztof

RE: [PATCH hyperv-next v5 02/11] arm64: hyperv: Use SMCCC to detect hypervisor presence

[Michael Kelley]

From: Roman Kisel <romank@linux.microsoft.com> Sent: Friday, March 7, 2025 2:03 PM
> 
> The arm64 Hyper-V startup path relies on ACPI to detect
> running under a Hyper-V compatible hypervisor. That
> doesn't work on non-ACPI systems.
> 
> Hoist the ACPI detection logic into a separate function. Then
> use the vendor-specific hypervisor service call (implemented
> recently in Hyper-V) via SMCCC in the non-ACPI case.
> 
> Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
> ---
>  arch/arm64/hyperv/mshyperv.c | 43 +++++++++++++++++++++++++++++++-----
>  1 file changed, 38 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm64/hyperv/mshyperv.c b/arch/arm64/hyperv/mshyperv.c
> index 29fcfd595f48..c647db56fd6b 100644
> --- a/arch/arm64/hyperv/mshyperv.c
> +++ b/arch/arm64/hyperv/mshyperv.c
> @@ -27,6 +27,41 @@ int hv_get_hypervisor_version(union hv_hypervisor_version_info
> *info)
>  	return 0;
>  }
> 
> +static bool __init hyperv_detect_via_acpi(void)
> +{
> +	if (acpi_disabled)
> +		return false;
> +#if IS_ENABLED(CONFIG_ACPI)
> +	/*
> +	 * Hypervisor ID is only available in ACPI v6+, and the
> +	 * structure layout was extended in v6 to accommodate that
> +	 * new field.
> +	 *
> +	 * At the very minimum, this check makes sure not to read
> +	 * past the FADT structure.
> +	 *
> +	 * It is also needed to catch running in some unknown
> +	 * non-Hyper-V environment that has ACPI 5.x or less.
> +	 * In such a case, it can't be Hyper-V.
> +	 */
> +	if (acpi_gbl_FADT.header.revision < 6)
> +		return false;
> +	return strncmp((char *)&acpi_gbl_FADT.hypervisor_id, "MsHyperV", 8) == 0;
> +#else
> +	return false;
> +#endif
> +}
> +
> +static bool __init hyperv_detect_via_smccc(void)
> +{
> +	uuid_t hyperv_uuid = UUID_INIT(
> +		0x4d32ba58, 0x4764, 0xcd24,
> +		0x75, 0x6c, 0xef, 0x8e,
> +		0x24, 0x70, 0x59, 0x16);
> +
> +	return arm_smccc_hyp_present(&hyperv_uuid);
> +}
> +
>  static int __init hyperv_init(void)
>  {
>  	struct hv_get_vp_registers_output	result;
> @@ -35,13 +70,11 @@ static int __init hyperv_init(void)
> 
>  	/*
>  	 * Allow for a kernel built with CONFIG_HYPERV to be running in
> -	 * a non-Hyper-V environment, including on DT instead of ACPI.
> +	 * a non-Hyper-V environment.
> +	 *
>  	 * In such cases, do nothing and return success.
>  	 */
> -	if (acpi_disabled)
> -		return 0;
> -
> -	if (strncmp((char *)&acpi_gbl_FADT.hypervisor_id, "MsHyperV", 8))
> +	if (!hyperv_detect_via_acpi() && !hyperv_detect_via_smccc())
>  		return 0;
> 
>  	/* Setup the guest ID */
> --
> 2.43.0
> 

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

Re: [PATCH hyperv-next v5 03/11] Drivers: hv: Enable VTL mode for arm64

[Arnd Bergmann]

On Mon, Mar 10, 2025, at 22:01, Michael Kelley wrote:
> From: Arnd Bergmann <arnd@arndb.de> Sent: Saturday, March 8, 2025 1:05 PM
>> >  config HYPERV_VTL_MODE
>> >  	bool "Enable Linux to boot in VTL context"
>> > -	depends on X86_64 && HYPERV
>> > +	depends on (X86_64 || ARM64)
>> >  	depends on SMP
>> > +	select OF_EARLY_FLATTREE
>> > +	select OF
>> >  	default n
>> >  	help
>> 
>> Having the dependency below the top-level Kconfig entry feels a little
>> counterintuitive. You could flip that back as it was before by doing
>> 
>>       select HYPERV_VTL_MODE if !ACPI
>>       depends on ACPI || SMP
>> 
>> in the HYPERV option, leaving the dependency on HYPERV in
>> HYPERV_VTL_MODE.
>
> I would argue that we don't ever want to implicitly select
> HYPERV_VTL_MODE because of some other config setting or
> lack thereof.  VTL mode is enough of a special case that it should
> only be explicitly selected. If someone omits ACPI, then HYPERV
> should not be selectable unless HYPERV_VTL_MODE is explicitly
> selected.
>
> The last line of the comment for HYPERV_VTL_MODE says
> "A kernel built with this option must run at VTL2, and will not run
> as a normal guest."  In other words, don't choose this unless you
> 100% know that VTL2 is what you want.

It sounds like the latter is the real problem: enabling a feature
should never prevent something else from working. Can you describe
what VTL context is and why it requires an exception to a rather
fundamental rule here? If you build a kernel that runs on every
single piece of arm64 hardware and every hypervisor, why can't
you add HYPERV_VTL_MODE to that as an option?

      Arnd

Re: [PATCH hyperv-next v5 07/11] dt-bindings: microsoft,vmbus: Add interrupts and DMA coherence

[Roman Kisel]

On 3/10/2025 2:17 PM, Krzysztof Kozlowski wrote:
> On 10/03/2025 19:07, Roman Kisel wrote:
>>
>> It is modeled as a bus in the kernel:
>> https://www.kernel.org/doc/html/latest/virt/hyperv/vmbus.html
>>
>>> Please upstream bindings for the bus devices and extend the example here
>>> with these devices.
>>
>> The set of synthetic devices that reside on the bus isn't fixed, and
>> they don't require description neither in ACPI nor in DT as
>> the devices negotiate their MMIO regions through the hyperv driver.
>>
>> Perhaps, it is not as much bus as expected by the YAML files.
> 
> OK, then this is not really a bus from the bindings point of view. It is
> a device schema which should end with additionalProperties: false.
> 
> If you have report about that pinctrl-0, it means you have undocumented
> properties in your DTS. Maybe that's the dma-coherence you mentioned in
> the commit msg.
> 

Much appreciated! I started reviewing the learning materials you
mentioned, and I think I already see where my understanding went
sideways: I perceived the example as the central part of the bindings
whereas it seems to be just what the name suggests: an example. Yet,
the example shall conform to the *schema* iiuc, and that is what the
tooling validates.

Hopefully, I am starting to be getting what this is all about :)
Thanks for your help again!

I've worked out what makes (more) sense (to me at least):

 From 475fb74b49dc4987ca8b9117186941d848f0aacd Mon Sep 17 00:00:00 2001
From: Roman Kisel <romank@linux.microsoft.com>
Date: Mon, 10 Mar 2025 14:39:41 -0700
Subject: [PATCH] dt-bindings: microsoft,vmbus: Add interrupt and DMA
   coherence properties

To boot in the VTL mode, VMBus on arm64 needs interrupt description
which the binding documentation lacks. The transactions on the bus are
DMA coherent which is not mentioned as well.

Add the interrupt property and the DMA coherence property to the VMBus
binding. Update the example to match that. Fix typos.

Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
---
  .../bindings/bus/microsoft,vmbus.yaml           | 17 +++++++++++++++--
  1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/bus/microsoft,vmbus.yaml 
b/Documentation/devicetree/bindings/bus/microsoft,vmbus.yaml
index a8d40c766dcd..b175ad01f219 100644
--- a/Documentation/devicetree/bindings/bus/microsoft,vmbus.yaml
+++ b/Documentation/devicetree/bindings/bus/microsoft,vmbus.yaml
@@ -10,8 +10,8 @@ maintainers:
    - Saurabh Sengar <ssengar@linux.microsoft.com>

  description:
-  VMBus is a software bus that implement the protocols for communication
-  between the root or host OS and guest OSs (virtual machines).
+  VMBus is a software bus that implements the protocols for communication
+  between the root or host OS and guest OS'es (virtual machines).

  properties:
    compatible:
@@ -25,9 +25,17 @@ properties:
    '#size-cells':
      const: 1

+  dma-coherent: true
+
+  interrupts:
+    maxItems: 1
+    description: |
+      This interrupt signals a message from the host.
+
  required:
    - compatible
    - ranges
+  - interrupts
    - '#address-cells'
    - '#size-cells'

@@ -35,6 +43,8 @@ additionalProperties: false

  examples:
    - |
+    #include <dt-bindings/interrupt-controller/irq.h>
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
      soc {
          #address-cells = <2>;
          #size-cells = <1>;
@@ -49,6 +59,9 @@ examples:
                  #address-cells = <2>;
                  #size-cells = <1>;
                  ranges = <0x0f 0xf0000000 0x0f 0xf0000000 0x10000000>;
+                dma-coherent;
+                interrupt-parent = <&gic>;
+                interrupts = <GIC_PPI 2 IRQ_TYPE_EDGE_RISING>;
              };
          };
      };
-- 
2.43.0


> 
> Best regards,
> Krzysztof

-- 
Thank you,
Roman

Re: [PATCH hyperv-next v5 01/11] arm64: kvm, smccc: Introduce and use API for detectting hypervisor presence

[Roman Kisel]

On 3/10/2025 2:16 PM, Michael Kelley wrote:
> From: Roman Kisel <romank@linux.microsoft.com> Sent: Friday, March 7, 2025 2:03 PM
>>
> 
> In the Subject line,
> 
> s/detectting/detecting/

[...]

> s/cenrtal/central/
> 

My bad, will fix! Thanks for spotting that, I'll be sure to have
the spellchecker on.

-- 
Thank you,
Roman

RE: [PATCH hyperv-next v5 03/11] Drivers: hv: Enable VTL mode for arm64

[Michael Kelley]

From: Arnd Bergmann <arnd@arndb.de> Sent: Monday, March 10, 2025 2:21 PM
> 
> On Mon, Mar 10, 2025, at 22:01, Michael Kelley wrote:
> > From: Arnd Bergmann <arnd@arndb.de> Sent: Saturday, March 8, 2025 1:05 PM
> >> >  config HYPERV_VTL_MODE
> >> >  	bool "Enable Linux to boot in VTL context"
> >> > -	depends on X86_64 && HYPERV
> >> > +	depends on (X86_64 || ARM64)
> >> >  	depends on SMP
> >> > +	select OF_EARLY_FLATTREE
> >> > +	select OF
> >> >  	default n
> >> >  	help
> >>
> >> Having the dependency below the top-level Kconfig entry feels a little
> >> counterintuitive. You could flip that back as it was before by doing
> >>
> >>       select HYPERV_VTL_MODE if !ACPI
> >>       depends on ACPI || SMP
> >>
> >> in the HYPERV option, leaving the dependency on HYPERV in
> >> HYPERV_VTL_MODE.
> >
> > I would argue that we don't ever want to implicitly select
> > HYPERV_VTL_MODE because of some other config setting or
> > lack thereof.  VTL mode is enough of a special case that it should
> > only be explicitly selected. If someone omits ACPI, then HYPERV
> > should not be selectable unless HYPERV_VTL_MODE is explicitly
> > selected.
> >
> > The last line of the comment for HYPERV_VTL_MODE says
> > "A kernel built with this option must run at VTL2, and will not run
> > as a normal guest."  In other words, don't choose this unless you
> > 100% know that VTL2 is what you want.
> 
> It sounds like the latter is the real problem: enabling a feature
> should never prevent something else from working. Can you describe
> what VTL context is and why it requires an exception to a rather
> fundamental rule here? If you build a kernel that runs on every
> single piece of arm64 hardware and every hypervisor, why can't
> you add HYPERV_VTL_MODE to that as an option?
> 

VTL = Virtual Trust Level, and VSM = Virtual Secure Mode, are Hyper-V's
terminology for offering multiple execution environments with
hierarchical trust in the context of a single VM. A normal guest
operating system runs at VTL 0, and there are no other VTLs in use.
But in some environments, additional software may run as a paravisor
layer between the normal guest OS and the hypervisor. This software
runs at some other VTL > 0, and has a higher privilege level within
the VM than software running at VTL 0 (which is the lowest privilege).
VTL 2 is used today in the Azure cloud with CoCo VMs to run a
paravisor, and there may be other uses in the future. See [1] if you
want more details on VSM and VTLs. Also [2] for the CoCo VM use
case.

Ideally, a Linux kernel image could detect at runtime what VTL it is
running at, and "do the right thing". Unfortunately, on x86 Linux this
has proved difficult (or perhaps impossible) because the amount of
boot-time setup required to ask the question about the current VTL
is significant. The idiosyncrasies and historical baggage of x86 requires
that Linux do some x86-specific initialization steps for VTL > 0
before the question can be asked. Hence the introduction of
CONFIG_HYPERV_VTL_MODE, and the behavior that when it is
selected, the kernel image won't run normally in VTL 0.

I'll go out on a limb and say that I suspect on arm64 a runtime
determination based on querying the VTL *could* be made (though
I'm not the person writing the code). But taking advantage of that
on arm64 produces an undesirable dichotomy with x86.

Roman may have further thoughts on the topic, but that's
what I know about how we got here.

Michael

[1] https://learn.microsoft.com/en-us/virtualization/hyper-v-on-windows/tlfs/vsm
[2] https://techcommunity.microsoft.com/blog/windowsosplatform/openhcl-the-new-open-source-paravisor/4273172

RE: [PATCH hyperv-next v5 05/11] arm64: hyperv: Initialize the Virtual Trust Level field

[Michael Kelley]

From: Roman Kisel <romank@linux.microsoft.com> Sent: Friday, March 7, 2025 2:03 PM
> 
> Various parts of the hyperv code need to know what VTL
> the kernel runs at, most notably VMBus needs that to
> establish communication with the host.
> 
> Initialize the Virtual Trust Level field to enable
> booting in the Virtual Trust Level.
> 
> Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
> ---
>  arch/arm64/hyperv/mshyperv.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm64/hyperv/mshyperv.c b/arch/arm64/hyperv/mshyperv.c
> index c647db56fd6b..a7db03f5413d 100644
> --- a/arch/arm64/hyperv/mshyperv.c
> +++ b/arch/arm64/hyperv/mshyperv.c
> @@ -107,6 +107,7 @@ static int __init hyperv_init(void)
> 
>  	if (ms_hyperv.priv_high & HV_ACCESS_PARTITION_ID)
>  		hv_get_partition_id();
> +	ms_hyperv.vtl = get_vtl();
> 
>  	ms_hyperv_late_init();
> 
> --
> 2.43.0
> 

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

RE: [PATCH hyperv-next v5 08/11] Drivers: hv: vmbus: Get the IRQ number from DeviceTree

[Michael Kelley]

From: Roman Kisel <romank@linux.microsoft.com> Sent: Friday, March 7, 2025 2:03 PM
> 
> The VMBus driver uses ACPI for interrupt assignment on
> arm64 hence it won't function in the VTL mode where only
> DeviceTree can be used.
> 
> Update the VMBus driver to discover interrupt configuration
> from DT.
> 
> Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
> Reviewed-by: Michael Kelley <mhklinux@outlook.com>
> ---
>  drivers/hv/vmbus_drv.c | 36 ++++++++++++++++++++++++++++++++++++
>  1 file changed, 36 insertions(+)
> 
> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> index 75eb1390b45c..c8474b48dcd2 100644
> --- a/drivers/hv/vmbus_drv.c
> +++ b/drivers/hv/vmbus_drv.c
> @@ -2345,6 +2345,36 @@ static int vmbus_acpi_add(struct platform_device *pdev)
>  }
>  #endif
> 
> +static int __maybe_unused vmbus_set_irq(struct platform_device *pdev)
> +{
> +	struct irq_data *data;
> +	int irq;
> +	irq_hw_number_t hwirq;
> +
> +	irq = platform_get_irq(pdev, 0);
> +	if (irq == 0) {
> +		pr_err("VMBus interrupt mapping failure\n");
> +		return -EINVAL;
> +	}
> +	if (irq < 0) {
> +		pr_err("VMBus interrupt data can't be read from DeviceTree, error %d\n", irq);
> +		return irq;
> +	}
> +
> +	data = irq_get_irq_data(irq);
> +	if (!data) {
> +		pr_err("No interrupt data for VMBus virq %d\n", irq);
> +		return -ENODEV;
> +	}
> +	hwirq = irqd_to_hwirq(data);
> +
> +	vmbus_irq = irq;
> +	vmbus_interrupt = hwirq;
> +	pr_debug("VMBus virq %d, hwirq %d\n", vmbus_irq, vmbus_interrupt);
> +
> +	return 0;
> +}
> +
>  static int vmbus_device_add(struct platform_device *pdev)
>  {
>  	struct resource **cur_res = &hyperv_mmio;
> @@ -2359,6 +2389,12 @@ static int vmbus_device_add(struct platform_device *pdev)
>  	if (ret)
>  		return ret;
> 
> +#ifndef HYPERVISOR_CALLBACK_VECTOR
> +	ret = vmbus_set_irq(pdev);
> +	if (ret)
> +		return ret;
> +#endif
> +
>  	for_each_of_range(&parser, &range) {
>  		struct resource *res;
> 
> --
> 2.43.0
> 

Modulo Arnd's suggestion for avoiding the #ifndef, 

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

RE: [PATCH hyperv-next v5 09/11] Drivers: hv: vmbus: Introduce hv_get_vmbus_root_device()

[Michael Kelley]

From: Roman Kisel <romank@linux.microsoft.com> Sent: Friday, March 7, 2025 2:03 PM
> 
> The ARM64 PCI code for hyperv needs to know the VMBus root
> device, and it is private.
> 
> Provide a function that returns it. Rename it from "hv_dev"
> as "hv_dev" as a symbol is very overloaded. No functional
> changes.
> 
> Signed-off-by: Roman Kisel <romank@linux.microsoft.com>

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

> ---
>  drivers/hv/vmbus_drv.c | 23 +++++++++++++++--------
>  include/linux/hyperv.h |  2 ++
>  2 files changed, 17 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> index c8474b48dcd2..7bfafe702963 100644
> --- a/drivers/hv/vmbus_drv.c
> +++ b/drivers/hv/vmbus_drv.c
> @@ -45,7 +45,8 @@ struct vmbus_dynid {
>  	struct hv_vmbus_device_id id;
>  };
> 
> -static struct device  *hv_dev;
> +/* VMBus Root Device */
> +static struct device  *vmbus_root_device;
> 
>  static int hyperv_cpuhp_online;
> 
> @@ -80,9 +81,15 @@ static struct resource *fb_mmio;
>  static struct resource *hyperv_mmio;
>  static DEFINE_MUTEX(hyperv_mmio_lock);
> 
> +struct device *hv_get_vmbus_root_device(void)
> +{
> +	return vmbus_root_device;
> +}
> +EXPORT_SYMBOL_GPL(hv_get_vmbus_root_device);
> +
>  static int vmbus_exists(void)
>  {
> -	if (hv_dev == NULL)
> +	if (vmbus_root_device == NULL)
>  		return -ENODEV;
> 
>  	return 0;
> @@ -861,7 +868,7 @@ static int vmbus_dma_configure(struct device *child_device)
>  	 * On x86/x64 coherence is assumed and these calls have no effect.
>  	 */
>  	hv_setup_dma_ops(child_device,
> -		device_get_dma_attr(hv_dev) == DEV_DMA_COHERENT);
> +		device_get_dma_attr(vmbus_root_device) == DEV_DMA_COHERENT);
>  	return 0;
>  }
> 
> @@ -1930,7 +1937,7 @@ int vmbus_device_register(struct hv_device *child_device_obj)
>  		     &child_device_obj->channel->offermsg.offer.if_instance);
> 
>  	child_device_obj->device.bus = &hv_bus;
> -	child_device_obj->device.parent = hv_dev;
> +	child_device_obj->device.parent = vmbus_root_device;
>  	child_device_obj->device.release = vmbus_device_release;
> 
>  	child_device_obj->device.dma_parms = &child_device_obj->dma_parms;
> @@ -2292,7 +2299,7 @@ static int vmbus_acpi_add(struct platform_device *pdev)
>  	struct acpi_device *ancestor;
>  	struct acpi_device *device = ACPI_COMPANION(&pdev->dev);
> 
> -	hv_dev = &device->dev;
> +	vmbus_root_device = &device->dev;
> 
>  	/*
>  	 * Older versions of Hyper-V for ARM64 fail to include the _CCA
> @@ -2383,7 +2390,7 @@ static int vmbus_device_add(struct platform_device *pdev)
>  	struct device_node *np = pdev->dev.of_node;
>  	int ret;
> 
> -	hv_dev = &pdev->dev;
> +	vmbus_root_device = &pdev->dev;
> 
>  	ret = of_range_parser_init(&parser, np);
>  	if (ret)
> @@ -2702,7 +2709,7 @@ static int __init hv_acpi_init(void)
>  	if (ret)
>  		return ret;
> 
> -	if (!hv_dev) {
> +	if (!vmbus_root_device) {
>  		ret = -ENODEV;
>  		goto cleanup;
>  	}
> @@ -2733,7 +2740,7 @@ static int __init hv_acpi_init(void)
> 
>  cleanup:
>  	platform_driver_unregister(&vmbus_platform_driver);
> -	hv_dev = NULL;
> +	vmbus_root_device = NULL;
>  	return ret;
>  }
> 
> diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
> index 7f4f8d8bdf43..1f0851fde041 100644
> --- a/include/linux/hyperv.h
> +++ b/include/linux/hyperv.h
> @@ -1333,6 +1333,8 @@ static inline void *hv_get_drvdata(struct hv_device *dev)
>  	return dev_get_drvdata(&dev->device);
>  }
> 
> +struct device *hv_get_vmbus_root_device(void);
> +
>  struct hv_ring_buffer_debug_info {
>  	u32 current_interrupt_mask;
>  	u32 current_read_index;
> --
> 2.43.0
> 

RE: [PATCH hyperv-next v5 10/11] ACPI: irq: Introduce acpi_get_gsi_dispatcher()

[Michael Kelley]

From: Roman Kisel <romank@linux.microsoft.com> Sent: Friday, March 7, 2025 2:03 PM
> 
> Using acpi_irq_create_hierarchy() in the cases where the code
> also handles OF leads to code duplication as the ACPI subsystem
> doesn't provide means to compute the IRQ domain parent whereas
> the OF does.
> 
> Introduce acpi_get_gsi_dispatcher() so that the drivers relying
> on both ACPI and OF may use irq_domain_create_hierarchy() in the
> common code paths.
> 
> No functional changes.
> 
> Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
> ---
>  drivers/acpi/irq.c   | 14 ++++++++++++--
>  include/linux/acpi.h |  5 ++++-
>  2 files changed, 16 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/acpi/irq.c b/drivers/acpi/irq.c
> index 1687483ff319..6243db610137 100644
> --- a/drivers/acpi/irq.c
> +++ b/drivers/acpi/irq.c
> @@ -12,7 +12,7 @@
> 
>  enum acpi_irq_model_id acpi_irq_model;
> 
> -static struct fwnode_handle *(*acpi_get_gsi_domain_id)(u32 gsi);
> +static acpi_gsi_domain_disp_fn acpi_get_gsi_domain_id;
>  static u32 (*acpi_gsi_to_irq_fallback)(u32 gsi);
> 
>  /**
> @@ -307,12 +307,22 @@ EXPORT_SYMBOL_GPL(acpi_irq_get);
>   *	for a given GSI
>   */
>  void __init acpi_set_irq_model(enum acpi_irq_model_id model,
> -			       struct fwnode_handle *(*fn)(u32))
> +	acpi_gsi_domain_disp_fn fn)
>  {
>  	acpi_irq_model = model;
>  	acpi_get_gsi_domain_id = fn;
>  }
> 
> +/**
> + * acpi_get_gsi_dispatcher - Returns dispatcher function that
> + *                           computes the domain fwnode for a
> + *                           given GSI.
> + */
> +acpi_gsi_domain_disp_fn acpi_get_gsi_dispatcher(void)
> +{
> +	return acpi_get_gsi_domain_id;
> +}

This new function is needed by pci-hyperv.c. It will
need to be marked as EXPORT_SYMBOL_GPL since
pci-hyperv.c can be built as a module.

> +
>  /**
>   * acpi_set_gsi_to_irq_fallback - Register a GSI transfer
>   * callback to fallback to arch specified implementation.
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 4e495b29c640..abc51288e867 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -336,8 +336,11 @@ int acpi_register_gsi (struct device *dev, u32 gsi, int triggering, int
> polarity
>  int acpi_gsi_to_irq (u32 gsi, unsigned int *irq);
>  int acpi_isa_irq_to_gsi (unsigned isa_irq, u32 *gsi);
> 
> +typedef struct fwnode_handle *(*acpi_gsi_domain_disp_fn)(u32);
> +
>  void acpi_set_irq_model(enum acpi_irq_model_id model,
> -			struct fwnode_handle *(*)(u32));
> +	acpi_gsi_domain_disp_fn fn);
> +acpi_gsi_domain_disp_fn acpi_get_gsi_dispatcher(void);
>  void acpi_set_gsi_to_irq_fallback(u32 (*)(u32));
> 
>  struct irq_domain *acpi_irq_create_hierarchy(unsigned int flags,
> --
> 2.43.0
> 

I'm not at all expert in ACPI code and IRQ domains, but the changes
here look reasonable to me. Modulo adding the EXPORT_SYMBOL_GPL,

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

RE: [PATCH hyperv-next v5 11/11] PCI: hv: Get vPCI MSI IRQ domain from DeviceTree

[Michael Kelley]

From: Roman Kisel <romank@linux.microsoft.com> Sent: Friday, March 7, 2025 2:03 PM
> 
> The hyperv-pci driver uses ACPI for MSI IRQ domain configuration on
> arm64. It won't be able to do that in the VTL mode where only DeviceTree
> can be used.
> 
> Update the hyperv-pci driver to get vPCI MSI IRQ domain in the DeviceTree
> case, too.
> 
> Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
> ---
>  drivers/pci/controller/pci-hyperv.c | 79 ++++++++++++++++++++++++++---
>  1 file changed, 73 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c
> index 6084b38bdda1..9740006a8c73 100644
> --- a/drivers/pci/controller/pci-hyperv.c
> +++ b/drivers/pci/controller/pci-hyperv.c
> @@ -50,6 +50,7 @@
>  #include <linux/irqdomain.h>
>  #include <linux/acpi.h>
>  #include <linux/sizes.h>
> +#include <linux/of_irq.h>
>  #include <asm/mshyperv.h>
> 
>  /*
> @@ -817,9 +818,17 @@ static int hv_pci_vec_irq_gic_domain_alloc(struct irq_domain *domain,
>  	int ret;
> 
>  	fwspec.fwnode = domain->parent->fwnode;
> -	fwspec.param_count = 2;
> -	fwspec.param[0] = hwirq;
> -	fwspec.param[1] = IRQ_TYPE_EDGE_RISING;
> +	if (is_of_node(fwspec.fwnode)) {
> +		/* SPI lines for OF translations start at offset 32 */
> +		fwspec.param_count = 3;
> +		fwspec.param[0] = 0;
> +		fwspec.param[1] = hwirq - 32;
> +		fwspec.param[2] = IRQ_TYPE_EDGE_RISING;
> +	} else {
> +		fwspec.param_count = 2;
> +		fwspec.param[0] = hwirq;
> +		fwspec.param[1] = IRQ_TYPE_EDGE_RISING;
> +	}
> 
>  	ret = irq_domain_alloc_irqs_parent(domain, virq, 1, &fwspec);
>  	if (ret)
> @@ -887,10 +896,53 @@ static const struct irq_domain_ops hv_pci_domain_ops = {
>  	.activate = hv_pci_vec_irq_domain_activate,
>  };
> 
> +#ifdef CONFIG_OF
> +
> +static struct irq_domain *hv_pci_of_irq_domain_parent(void)
> +{
> +	struct device_node *parent;
> +	struct irq_domain *domain;
> +
> +	parent = of_irq_find_parent(hv_get_vmbus_root_device()->of_node);
> +	domain = NULL;
> +	if (parent) {
> +		domain = irq_find_host(parent);
> +		of_node_put(parent);
> +	}
> +
> +	return domain;
> +}

You could insert the following and avoid the #ifdef's in hv_pci_irqchip_init():

#else
static struct irq_domain *hv_pci_of_irq_domain_parent(void) {return NULL;}

> +
> +#endif
> +
> +#ifdef CONFIG_ACPI
> +
> +static struct irq_domain *hv_pci_acpi_irq_domain_parent(void)
> +{
> +	struct irq_domain *domain;
> +	acpi_gsi_domain_disp_fn gsi_domain_disp_fn;
> +
> +	if (acpi_irq_model != ACPI_IRQ_MODEL_GIC)
> +		return NULL;
> +	gsi_domain_disp_fn = acpi_get_gsi_dispatcher();
> +	if (!gsi_domain_disp_fn)
> +		return NULL;
> +	domain = irq_find_matching_fwnode(gsi_domain_disp_fn(0),
> +				     DOMAIN_BUS_ANY);
> +
> +	if (!domain)
> +		return NULL;
> +
> +	return domain;
> +}

Same here:

#else
static struct irq_domain *hv_pci_acpi_irq_domain_parent(void) {return NULL;}

I don't know if it's better or not. Just a suggestion -- keep what you have if
you prefer.

> +
> +#endif
> +
>  static int hv_pci_irqchip_init(void)
>  {
>  	static struct hv_pci_chip_data *chip_data;
>  	struct fwnode_handle *fn = NULL;
> +	struct irq_domain *irq_domain_parent = NULL;
>  	int ret = -ENOMEM;
> 
>  	chip_data = kzalloc(sizeof(*chip_data), GFP_KERNEL);
> @@ -907,9 +959,24 @@ static int hv_pci_irqchip_init(void)
>  	 * way to ensure that all the corresponding devices are also gone and
>  	 * no interrupts will be generated.
>  	 */
> -	hv_msi_gic_irq_domain = acpi_irq_create_hierarchy(0, HV_PCI_MSI_SPI_NR,
> -							  fn, &hv_pci_domain_ops,
> -							  chip_data);
> +#ifdef CONFIG_ACPI
> +	if (!acpi_disabled)
> +		irq_domain_parent = hv_pci_acpi_irq_domain_parent();
> +#endif
> +#if defined(CONFIG_OF)
> +	if (!irq_domain_parent)
> +		irq_domain_parent = hv_pci_of_irq_domain_parent();
> +#endif
> +	if (!irq_domain_parent) {
> +		WARN_ONCE(1, "Invalid firmware configuration for VMBus interrupts\n");
> +		ret = -EINVAL;
> +		goto free_chip;
> +	}
> +
> +	hv_msi_gic_irq_domain = irq_domain_create_hierarchy(
> +		irq_domain_parent, 0, HV_PCI_MSI_SPI_NR,
> +		fn, &hv_pci_domain_ops,
> +		chip_data);
> 
>  	if (!hv_msi_gic_irq_domain) {
>  		pr_err("Failed to create Hyper-V arm64 vPCI MSI IRQ domain\n");
> --
> 2.43.0
> 

Overall, I think the code looks right, though I'm not an expert in this area. I'll
give my Reviewed-by: once Bjorn's coding suggestions are incorporated.

Michael

Re: [PATCH hyperv-next v5 01/11] arm64: kvm, smccc: Introduce and use API for detectting hypervisor presence

[kernel test robot]

Hi Roman,

kernel test robot noticed the following build warnings:

[auto build test WARNING on 3a7f7785eae7cf012af128ca9e383c91e4955354]

url:    https://github.com/intel-lab-lkp/linux/commits/Roman-Kisel/arm64-kvm-smccc-Introduce-and-use-API-for-detectting-hypervisor-presence/20250308-060639
base:   3a7f7785eae7cf012af128ca9e383c91e4955354
patch link:    https://lore.kernel.org/r/20250307220304.247725-2-romank%40linux.microsoft.com
patch subject: [PATCH hyperv-next v5 01/11] arm64: kvm, smccc: Introduce and use API for detectting hypervisor presence
config: arm64-randconfig-r131-20250312 (https://download.01.org/0day-ci/archive/20250312/202503122113.trcjnau3-lkp@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 14.2.0
reproduce: (https://download.01.org/0day-ci/archive/20250312/202503122113.trcjnau3-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202503122113.trcjnau3-lkp@intel.com/

sparse warnings: (new ones prefixed by >>)
   drivers/firmware/smccc/smccc.c:19:21: sparse: sparse: symbol 'smccc_soc_id_version' was not declared. Should it be static?
   drivers/firmware/smccc/smccc.c:20:21: sparse: sparse: symbol 'smccc_soc_id_revision' was not declared. Should it be static?
>> drivers/firmware/smccc/smccc.c:81:37: sparse: sparse: restricted __le32 degrades to integer
>> drivers/firmware/smccc/smccc.c:81:37: sparse: sparse: restricted __le32 degrades to integer
>> drivers/firmware/smccc/smccc.c:81:37: sparse: sparse: restricted __le32 degrades to integer
>> drivers/firmware/smccc/smccc.c:81:37: sparse: sparse: restricted __le32 degrades to integer
>> drivers/firmware/smccc/smccc.c:81:37: sparse: sparse: restricted __le32 degrades to integer
>> drivers/firmware/smccc/smccc.c:81:37: sparse: sparse: restricted __le32 degrades to integer
>> drivers/firmware/smccc/smccc.c:81:37: sparse: sparse: restricted __le32 degrades to integer
>> drivers/firmware/smccc/smccc.c:81:37: sparse: sparse: restricted __le32 degrades to integer
>> drivers/firmware/smccc/smccc.c:81:37: sparse: sparse: restricted __le32 degrades to integer
>> drivers/firmware/smccc/smccc.c:81:37: sparse: sparse: restricted __le32 degrades to integer
>> drivers/firmware/smccc/smccc.c:81:37: sparse: sparse: restricted __le32 degrades to integer
>> drivers/firmware/smccc/smccc.c:81:37: sparse: sparse: restricted __le32 degrades to integer
>> drivers/firmware/smccc/smccc.c:81:37: sparse: sparse: restricted __le32 degrades to integer
>> drivers/firmware/smccc/smccc.c:81:37: sparse: sparse: restricted __le32 degrades to integer
>> drivers/firmware/smccc/smccc.c:81:37: sparse: sparse: restricted __le32 degrades to integer
>> drivers/firmware/smccc/smccc.c:81:37: sparse: sparse: restricted __le32 degrades to integer

vim +81 drivers/firmware/smccc/smccc.c

    69	
    70	bool arm_smccc_hyp_present(const uuid_t *hyp_uuid)
    71	{
    72		struct arm_smccc_res res = {};
    73	
    74		if (arm_smccc_1_1_get_conduit() != SMCCC_CONDUIT_HVC)
    75			return false;
    76		arm_smccc_1_1_hvc(ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID, &res);
    77		if (res.a0 == SMCCC_RET_NOT_SUPPORTED)
    78			return false;
    79	
    80		return ({
  > 81			const uuid_t uuid = SMCCC_RES_TO_UUID(res.a0, res.a1, res.a2, res.a3);
    82			const bool present = uuid_equal(&uuid, hyp_uuid);
    83	
    84			present;
    85		});
    86	}
    87	EXPORT_SYMBOL_GPL(arm_smccc_hyp_present);
    88	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH hyperv-next v5 03/11] Drivers: hv: Enable VTL mode for arm64

[Roman Kisel]

On 3/10/2025 3:18 PM, Michael Kelley wrote:
> From: Arnd Bergmann <arnd@arndb.de> Sent: Monday, March 10, 2025 2:21 PM
>>
>> On Mon, Mar 10, 2025, at 22:01, Michael Kelley wrote:
>>> From: Arnd Bergmann <arnd@arndb.de> Sent: Saturday, March 8, 2025 1:05 PM
>>>>>   config HYPERV_VTL_MODE
>>>>>   	bool "Enable Linux to boot in VTL context"
>>>>> -	depends on X86_64 && HYPERV
>>>>> +	depends on (X86_64 || ARM64)
>>>>>   	depends on SMP
>>>>> +	select OF_EARLY_FLATTREE
>>>>> +	select OF
>>>>>   	default n
>>>>>   	help
>>>>
>>>> Having the dependency below the top-level Kconfig entry feels a little
>>>> counterintuitive. You could flip that back as it was before by doing
>>>>
>>>>        select HYPERV_VTL_MODE if !ACPI
>>>>        depends on ACPI || SMP
>>>>
>>>> in the HYPERV option, leaving the dependency on HYPERV in
>>>> HYPERV_VTL_MODE.
>>>
>>> I would argue that we don't ever want to implicitly select
>>> HYPERV_VTL_MODE because of some other config setting or
>>> lack thereof.  VTL mode is enough of a special case that it should
>>> only be explicitly selected. If someone omits ACPI, then HYPERV
>>> should not be selectable unless HYPERV_VTL_MODE is explicitly
>>> selected.
>>>
>>> The last line of the comment for HYPERV_VTL_MODE says
>>> "A kernel built with this option must run at VTL2, and will not run
>>> as a normal guest."  In other words, don't choose this unless you
>>> 100% know that VTL2 is what you want.
>>
>> It sounds like the latter is the real problem: enabling a feature
>> should never prevent something else from working. Can you describe
>> what VTL context is and why it requires an exception to a rather
>> fundamental rule here? If you build a kernel that runs on every
>> single piece of arm64 hardware and every hypervisor, why can't
>> you add HYPERV_VTL_MODE to that as an option?
>>

In the VTL mode, we're running the kernel as secure firmware inside the
guest (one might see VTL2 working as Intel SMM or Secure World on ARM).

[...]

> 
> Ideally, a Linux kernel image could detect at runtime what VTL it is
> running at, and "do the right thing". Unfortunately, on x86 Linux this
> has proved difficult (or perhaps impossible) because the amount of
> boot-time setup required to ask the question about the current VTL
> is significant. The idiosyncrasies and historical baggage of x86 requires
> that Linux do some x86-specific initialization steps for VTL > 0
> before the question can be asked. Hence the introduction of
> CONFIG_HYPERV_VTL_MODE, and the behavior that when it is
> selected, the kernel image won't run normally in VTL 0.
> 
> I'll go out on a limb and say that I suspect on arm64 a runtime
> determination based on querying the VTL *could* be made (though
> I'm not the person writing the code). But taking advantage of that
> on arm64 produces an undesirable dichotomy with x86.

On arm64 that is much easier, I agree. On x86 we'd need a kludge of

static void __naked __init __aligned(4096) early_hvcall_pg(void)
{
	/*
	 * Fill the early hvcall page with `0xF1` aka `INT1` to catch
	 * programming errors. The hypervisor will overlay the page with
	 * the vendor-specific code sequences to make hypercalls on x86(_64).
	 */
	asm (".skip 4096, 0xf1");
}

static u8 __init early_hvcall_pg_input[4096] 
__attribute__((aligned(4096)));
static u8 __init early_hvcall_pg_output[4096] 
__attribute__((aligned(4096)));

static void __init early_connect_to_hv(void)
{
	union hv_x64_msr_hypercall_contents hypercall_msr;
	u64 guest_id;

	guest_id = hv_generate_guest_id(LINUX_VERSION_CODE);
	wrmsrl(HV_X64_MSR_GUEST_OS_ID, guest_id);
	rdmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
	hypercall_msr.enable = 1;
	hypercall_msr.guest_physical_address = 
__phys_to_pfn(virt_to_phys(early_hvcall_pg));
	wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
}

or variations thereof.

What's very nice about arm64 in this case at least, it's got SMCCC, hvc,
OF/DT and a history of options of being power-efficient and embedded.
Conversely, on x86(_64) the code sequences for hyeprcalls vary from the
first vendor to the second one so we have to have the hvcall page to
make this regular in the code. Support for OF/DT on x86 was added for
Intel set top boxes (MID, ~2015 iirc), and it took a bit of huffing and
puffing to make that work for us on the large/NUMA systems (and there
might be something about supporting x2apic that had to be figured out).

All told, we can have nicer things in our arm64 code yet diverging the
code much from x86(_64) is not very desirable. I am not sure yet what
the tradeoff should be, and my knowledge of Kconfig is rather basic.
Certainly I cannot propose to arm64 maintainers that we'd like to do
quirky things in Kconfig because of x86(-64), legacy specs, etc.

Perhaps, we could go back to the V2's option of

  config HYPERV
  	tristate "Microsoft Hyper-V client drivers"
  	depends on (X86 && X86_LOCAL_APIC && HYPERVISOR_GUEST) \
-		|| (ACPI && ARM64 && !CPU_BIG_ENDIAN)
+		|| (ARM64 && !CPU_BIG_ENDIAN)
  	select PARAVIRT
  	select X86_HV_CALLBACK_VECTOR if X86
  	select OF_EARLY_FLATTREE if OF
@@ -15,7 +15,7 @@ config HYPERV

  config HYPERV_VTL_MODE
  	bool "Enable Linux to boot in VTL context"
-	depends on X86_64 && HYPERV
+	depends on HYPERV
  	depends on SMP
  	default n
  	help
@@ -31,7 +31,7 @@ config HYPERV_VTL_MODE

  	  Select this option to build a Linux kernel to run at a VTL other than
  	  the normal VTL0, which currently is only VTL2.  This option
-	  initializes the x86 platform for VTL2, and adds the ability to boot
+	  initializes the kernel to run in VTL2, and adds the ability to boot
  	  secondary CPUs directly into 64-bit context as required for VTLs other
  	  than 0.  A kernel built with this option must run at VTL2, and will
  	  not run as a normal guest.

That's a minimal extension, its surprise factor is very low. It has not
been seen to cause issues. If no one has strong opinions against that,
I'd send that in V6.

> 
> Roman may have further thoughts on the topic, but that's
> what I know about how we got here.
> 
> Michael
> 
> [1] https://learn.microsoft.com/en-us/virtualization/hyper-v-on-windows/tlfs/vsm
> [2] https://techcommunity.microsoft.com/blog/windowsosplatform/openhcl-the-new-open-source-paravisor/4273172

-- 
Thank you,
Roman

Re: [PATCH hyperv-next v5 03/11] Drivers: hv: Enable VTL mode for arm64

[Arnd Bergmann]

On Wed, Mar 12, 2025, at 19:33, Roman Kisel wrote:
> On 3/10/2025 3:18 PM, Michael Kelley wrote:
>
> That's a minimal extension, its surprise factor is very low. It has not
> been seen to cause issues. If no one has strong opinions against that,
> I'd send that in V6.
>

Works for me. Thanks for your detailed explanations.

       Arnd

Re: [PATCH hyperv-next v5 03/11] Drivers: hv: Enable VTL mode for arm64

[Wei Liu]

On Wed, Mar 12, 2025 at 11:33:11AM -0700, Roman Kisel wrote:
> 
> 
> On 3/10/2025 3:18 PM, Michael Kelley wrote:
> > From: Arnd Bergmann <arnd@arndb.de> Sent: Monday, March 10, 2025 2:21 PM
> > > 
> > > On Mon, Mar 10, 2025, at 22:01, Michael Kelley wrote:
> > > > From: Arnd Bergmann <arnd@arndb.de> Sent: Saturday, March 8, 2025 1:05 PM
> > > > > >   config HYPERV_VTL_MODE
> > > > > >   	bool "Enable Linux to boot in VTL context"
> > > > > > -	depends on X86_64 && HYPERV
> > > > > > +	depends on (X86_64 || ARM64)
> > > > > >   	depends on SMP
> > > > > > +	select OF_EARLY_FLATTREE
> > > > > > +	select OF
> > > > > >   	default n
> > > > > >   	help
> > > > > 
> > > > > Having the dependency below the top-level Kconfig entry feels a little
> > > > > counterintuitive. You could flip that back as it was before by doing
> > > > > 
> > > > >        select HYPERV_VTL_MODE if !ACPI
> > > > >        depends on ACPI || SMP
> > > > > 
> > > > > in the HYPERV option, leaving the dependency on HYPERV in
> > > > > HYPERV_VTL_MODE.
> > > > 
> > > > I would argue that we don't ever want to implicitly select
> > > > HYPERV_VTL_MODE because of some other config setting or
> > > > lack thereof.  VTL mode is enough of a special case that it should
> > > > only be explicitly selected. If someone omits ACPI, then HYPERV
> > > > should not be selectable unless HYPERV_VTL_MODE is explicitly
> > > > selected.
> > > > 
> > > > The last line of the comment for HYPERV_VTL_MODE says
> > > > "A kernel built with this option must run at VTL2, and will not run
> > > > as a normal guest."  In other words, don't choose this unless you
> > > > 100% know that VTL2 is what you want.
> > > 
> > > It sounds like the latter is the real problem: enabling a feature
> > > should never prevent something else from working. Can you describe
> > > what VTL context is and why it requires an exception to a rather
> > > fundamental rule here? If you build a kernel that runs on every
> > > single piece of arm64 hardware and every hypervisor, why can't
> > > you add HYPERV_VTL_MODE to that as an option?
> > > 
> 
> In the VTL mode, we're running the kernel as secure firmware inside the
> guest (one might see VTL2 working as Intel SMM or Secure World on ARM).
> 
> [...]
> 
> > 
> > Ideally, a Linux kernel image could detect at runtime what VTL it is
> > running at, and "do the right thing". Unfortunately, on x86 Linux this
> > has proved difficult (or perhaps impossible) because the amount of
> > boot-time setup required to ask the question about the current VTL
> > is significant. The idiosyncrasies and historical baggage of x86 requires
> > that Linux do some x86-specific initialization steps for VTL > 0
> > before the question can be asked. Hence the introduction of
> > CONFIG_HYPERV_VTL_MODE, and the behavior that when it is
> > selected, the kernel image won't run normally in VTL 0.
> > 
> > I'll go out on a limb and say that I suspect on arm64 a runtime
> > determination based on querying the VTL *could* be made (though
> > I'm not the person writing the code). But taking advantage of that
> > on arm64 produces an undesirable dichotomy with x86.
> 
> On arm64 that is much easier, I agree. On x86 we'd need a kludge of
> 
> static void __naked __init __aligned(4096) early_hvcall_pg(void)
> {
> 	/*
> 	 * Fill the early hvcall page with `0xF1` aka `INT1` to catch
> 	 * programming errors. The hypervisor will overlay the page with
> 	 * the vendor-specific code sequences to make hypercalls on x86(_64).
> 	 */
> 	asm (".skip 4096, 0xf1");
> }
> 
> static u8 __init early_hvcall_pg_input[4096] __attribute__((aligned(4096)));
> static u8 __init early_hvcall_pg_output[4096]
> __attribute__((aligned(4096)));
> 
> static void __init early_connect_to_hv(void)
> {
> 	union hv_x64_msr_hypercall_contents hypercall_msr;
> 	u64 guest_id;
> 
> 	guest_id = hv_generate_guest_id(LINUX_VERSION_CODE);
> 	wrmsrl(HV_X64_MSR_GUEST_OS_ID, guest_id);
> 	rdmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
> 	hypercall_msr.enable = 1;
> 	hypercall_msr.guest_physical_address =
> __phys_to_pfn(virt_to_phys(early_hvcall_pg));
> 	wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
> }
> 
> or variations thereof.

OT here but what's stopping us from doing this on x86?

It seems to me there is some value in setting up the hypercall page as
early as possible. The same page can be used through the lifetime of the
partition. The early input and output pages should be reclaimed.

Also, since the hypervisor will insert an overlay page, it makes sense
to not allocate a page from Linux at all. When I ported Xen to run as
a guest on Hyper-V, I used that approach. The setup worked just fine.

All being said, things work today, so I'm in no hurry to change things.

Wei.

Re: [PATCH hyperv-next v5 01/11] arm64: kvm, smccc: Introduce and use API for detectting hypervisor presence

[kernel test robot]

Hi Roman,

kernel test robot noticed the following build warnings:

[auto build test WARNING on 3a7f7785eae7cf012af128ca9e383c91e4955354]

url:    https://github.com/intel-lab-lkp/linux/commits/Roman-Kisel/arm64-kvm-smccc-Introduce-and-use-API-for-detectting-hypervisor-presence/20250308-060639
base:   3a7f7785eae7cf012af128ca9e383c91e4955354
patch link:    https://lore.kernel.org/r/20250307220304.247725-2-romank%40linux.microsoft.com
patch subject: [PATCH hyperv-next v5 01/11] arm64: kvm, smccc: Introduce and use API for detectting hypervisor presence
config: arm64-randconfig-r131-20250312 (https://download.01.org/0day-ci/archive/20250313/202503130604.s2xx8AY1-lkp@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 14.2.0
reproduce: (https://download.01.org/0day-ci/archive/20250313/202503130604.s2xx8AY1-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202503130604.s2xx8AY1-lkp@intel.com/

sparse warnings: (new ones prefixed by >>)
   drivers/firmware/smccc/smccc.c:19:21: sparse: sparse: symbol 'smccc_soc_id_version' was not declared. Should it be static?
   drivers/firmware/smccc/smccc.c:20:21: sparse: sparse: symbol 'smccc_soc_id_revision' was not declared. Should it be static?
>> drivers/firmware/smccc/smccc.c:81:37: sparse: sparse: restricted __le32 degrades to integer
>> drivers/firmware/smccc/smccc.c:81:37: sparse: sparse: restricted __le32 degrades to integer
>> drivers/firmware/smccc/smccc.c:81:37: sparse: sparse: restricted __le32 degrades to integer
>> drivers/firmware/smccc/smccc.c:81:37: sparse: sparse: restricted __le32 degrades to integer
>> drivers/firmware/smccc/smccc.c:81:37: sparse: sparse: restricted __le32 degrades to integer
>> drivers/firmware/smccc/smccc.c:81:37: sparse: sparse: restricted __le32 degrades to integer
>> drivers/firmware/smccc/smccc.c:81:37: sparse: sparse: restricted __le32 degrades to integer
>> drivers/firmware/smccc/smccc.c:81:37: sparse: sparse: restricted __le32 degrades to integer
>> drivers/firmware/smccc/smccc.c:81:37: sparse: sparse: restricted __le32 degrades to integer
>> drivers/firmware/smccc/smccc.c:81:37: sparse: sparse: restricted __le32 degrades to integer
>> drivers/firmware/smccc/smccc.c:81:37: sparse: sparse: restricted __le32 degrades to integer
>> drivers/firmware/smccc/smccc.c:81:37: sparse: sparse: restricted __le32 degrades to integer
>> drivers/firmware/smccc/smccc.c:81:37: sparse: sparse: restricted __le32 degrades to integer
>> drivers/firmware/smccc/smccc.c:81:37: sparse: sparse: restricted __le32 degrades to integer
>> drivers/firmware/smccc/smccc.c:81:37: sparse: sparse: restricted __le32 degrades to integer
>> drivers/firmware/smccc/smccc.c:81:37: sparse: sparse: restricted __le32 degrades to integer

vim +81 drivers/firmware/smccc/smccc.c

    69	
    70	bool arm_smccc_hyp_present(const uuid_t *hyp_uuid)
    71	{
    72		struct arm_smccc_res res = {};
    73	
    74		if (arm_smccc_1_1_get_conduit() != SMCCC_CONDUIT_HVC)
    75			return false;
    76		arm_smccc_1_1_hvc(ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID, &res);
    77		if (res.a0 == SMCCC_RET_NOT_SUPPORTED)
    78			return false;
    79	
    80		return ({
  > 81			const uuid_t uuid = SMCCC_RES_TO_UUID(res.a0, res.a1, res.a2, res.a3);
    82			const bool present = uuid_equal(&uuid, hyp_uuid);
    83	
    84			present;
    85		});
    86	}
    87	EXPORT_SYMBOL_GPL(arm_smccc_hyp_present);
    88	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH hyperv-next v5 03/11] Drivers: hv: Enable VTL mode for arm64

[Roman Kisel]

On 3/12/2025 1:25 PM, Arnd Bergmann wrote:
> On Wed, Mar 12, 2025, at 19:33, Roman Kisel wrote:
>> On 3/10/2025 3:18 PM, Michael Kelley wrote:
>>
>> That's a minimal extension, its surprise factor is very low. It has not
>> been seen to cause issues. If no one has strong opinions against that,
>> I'd send that in V6.
>>
> 
> Works for me. Thanks for your detailed explanations.
> 

Thank you for your review very much!

>         Arnd

-- 
Thank you,
Roman

Re: [PATCH hyperv-next v5 03/11] Drivers: hv: Enable VTL mode for arm64

[Roman Kisel]

On 3/12/2025 1:31 PM, Wei Liu wrote:
> On Wed, Mar 12, 2025 at 11:33:11AM -0700, Roman Kisel wrote:
>>
>>
>> On 3/10/2025 3:18 PM, Michael Kelley wrote:
>>> From: Arnd Bergmann <arnd@arndb.de> Sent: Monday, March 10, 2025 2:21 PM
>>>>
>>>> On Mon, Mar 10, 2025, at 22:01, Michael Kelley wrote:
>>>>> From: Arnd Bergmann <arnd@arndb.de> Sent: Saturday, March 8, 2025 1:05 PM
>>>>>>>    config HYPERV_VTL_MODE
>>>>>>>    	bool "Enable Linux to boot in VTL context"
>>>>>>> -	depends on X86_64 && HYPERV
>>>>>>> +	depends on (X86_64 || ARM64)
>>>>>>>    	depends on SMP
>>>>>>> +	select OF_EARLY_FLATTREE
>>>>>>> +	select OF
>>>>>>>    	default n
>>>>>>>    	help
>>>>>>
>>>>>> Having the dependency below the top-level Kconfig entry feels a little
>>>>>> counterintuitive. You could flip that back as it was before by doing
>>>>>>
>>>>>>         select HYPERV_VTL_MODE if !ACPI
>>>>>>         depends on ACPI || SMP
>>>>>>
>>>>>> in the HYPERV option, leaving the dependency on HYPERV in
>>>>>> HYPERV_VTL_MODE.
>>>>>
>>>>> I would argue that we don't ever want to implicitly select
>>>>> HYPERV_VTL_MODE because of some other config setting or
>>>>> lack thereof.  VTL mode is enough of a special case that it should
>>>>> only be explicitly selected. If someone omits ACPI, then HYPERV
>>>>> should not be selectable unless HYPERV_VTL_MODE is explicitly
>>>>> selected.
>>>>>
>>>>> The last line of the comment for HYPERV_VTL_MODE says
>>>>> "A kernel built with this option must run at VTL2, and will not run
>>>>> as a normal guest."  In other words, don't choose this unless you
>>>>> 100% know that VTL2 is what you want.
>>>>
>>>> It sounds like the latter is the real problem: enabling a feature
>>>> should never prevent something else from working. Can you describe
>>>> what VTL context is and why it requires an exception to a rather
>>>> fundamental rule here? If you build a kernel that runs on every
>>>> single piece of arm64 hardware and every hypervisor, why can't
>>>> you add HYPERV_VTL_MODE to that as an option?
>>>>
>>
>> In the VTL mode, we're running the kernel as secure firmware inside the
>> guest (one might see VTL2 working as Intel SMM or Secure World on ARM).
>>
>> [...]
>>
>>>
>>> Ideally, a Linux kernel image could detect at runtime what VTL it is
>>> running at, and "do the right thing". Unfortunately, on x86 Linux this
>>> has proved difficult (or perhaps impossible) because the amount of
>>> boot-time setup required to ask the question about the current VTL
>>> is significant. The idiosyncrasies and historical baggage of x86 requires
>>> that Linux do some x86-specific initialization steps for VTL > 0
>>> before the question can be asked. Hence the introduction of
>>> CONFIG_HYPERV_VTL_MODE, and the behavior that when it is
>>> selected, the kernel image won't run normally in VTL 0.
>>>
>>> I'll go out on a limb and say that I suspect on arm64 a runtime
>>> determination based on querying the VTL *could* be made (though
>>> I'm not the person writing the code). But taking advantage of that
>>> on arm64 produces an undesirable dichotomy with x86.
>>
>> On arm64 that is much easier, I agree. On x86 we'd need a kludge of
>>
>> static void __naked __init __aligned(4096) early_hvcall_pg(void)
>> {
>> 	/*
>> 	 * Fill the early hvcall page with `0xF1` aka `INT1` to catch
>> 	 * programming errors. The hypervisor will overlay the page with
>> 	 * the vendor-specific code sequences to make hypercalls on x86(_64).
>> 	 */
>> 	asm (".skip 4096, 0xf1");
>> }
>>
>> static u8 __init early_hvcall_pg_input[4096] __attribute__((aligned(4096)));
>> static u8 __init early_hvcall_pg_output[4096]
>> __attribute__((aligned(4096)));
>>
>> static void __init early_connect_to_hv(void)
>> {
>> 	union hv_x64_msr_hypercall_contents hypercall_msr;
>> 	u64 guest_id;
>>
>> 	guest_id = hv_generate_guest_id(LINUX_VERSION_CODE);
>> 	wrmsrl(HV_X64_MSR_GUEST_OS_ID, guest_id);
>> 	rdmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
>> 	hypercall_msr.enable = 1;
>> 	hypercall_msr.guest_physical_address =
>> __phys_to_pfn(virt_to_phys(early_hvcall_pg));
>> 	wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
>> }
>>
>> or variations thereof.
> 
> OT here but what's stopping us from doing this on x86?
> 

At the first glance, seems like nothing I think. For the conf scenarios
like TDX and SEV-SNP, due to the early hvcall I/O pages above allocated
in BSS, might need to mark the pages as decrypted and zero them out so
they look like proper BSS section (the page contents are scrambled after
flipping the page encryption bit iirc).

> It seems to me there is some value in setting up the hypercall page as
> early as possible. The same page can be used through the lifetime of the
> partition. The early input and output pages should be reclaimed.
> 

Wholeheartedly agree!

> Also, since the hypervisor will insert an overlay page, it makes sense
> to not allocate a page from Linux at all. When I ported Xen to run as
> a guest on Hyper-V, I used that approach. The setup worked just fine.
> 
> All being said, things work today, so I'm in no hurry to change things.
> 

I'll try fleshing this out soon-ish if no one beats me to that :)

> Wei.

-- 
Thank you,
Roman

RE: [PATCH hyperv-next v5 03/11] Drivers: hv: Enable VTL mode for arm64

[Michael Kelley]

From: Roman Kisel <romank@linux.microsoft.com> Sent: Wednesday, March 12, 2025 2:21 PM
> 
> On 3/12/2025 1:25 PM, Arnd Bergmann wrote:
> > On Wed, Mar 12, 2025, at 19:33, Roman Kisel wrote:
> >>
> >> That's a minimal extension, its surprise factor is very low. It has not
> >> been seen to cause issues. If no one has strong opinions against that,
> >> I'd send that in V6.
> >>
> >
> > Works for me. Thanks for your detailed explanations.
> >
> 
> Thank you for your review very much!
> 

My original concern [1] with this minimal change is that it allows building
a normal Linux kernel (i.e., not for VTL 2) for Hyper-V with CONFIG_ACPI=n.
Such a kernel will not run in a Hyper-V VM since ACPI is required unless
building for and running in VTL 2. Current upstream code disallows
CONFIG_HYPERV=y with CONFIG_ACPI=n.

However, I don't want to make too big of a deal about now allowing this
misconfiguration. Arguably it's not likely to happen, and the solution is
"don't do that".  So if we want to go back to the minimal set of changes to
drivers/hv/Kconfig as Roman proposes, I won't object further. I just want
to sure everyone is clear on the tradeoffs.

Michael

[1] https://lore.kernel.org/linux-hyperv/SN6PR02MB4157E15EFE263BBA3D8DFC51D4EC2@SN6PR02MB4157.namprd02.prod.outlook.com/

Re: [PATCH hyperv-next v5 08/11] Drivers: hv: vmbus: Get the IRQ number from DeviceTree

[Dan Carpenter]

Hi Roman,

kernel test robot noticed the following build warnings:

url:    https://github.com/intel-lab-lkp/linux/commits/Roman-Kisel/arm64-kvm-smccc-Introduce-and-use-API-for-detectting-hypervisor-presence/20250308-060639
base:   3a7f7785eae7cf012af128ca9e383c91e4955354
patch link:    https://lore.kernel.org/r/20250307220304.247725-9-romank%40linux.microsoft.com
patch subject: [PATCH hyperv-next v5 08/11] Drivers: hv: vmbus: Get the IRQ number from DeviceTree
config: arm64-randconfig-r071-20250312 (https://download.01.org/0day-ci/archive/20250313/202503132345.uKNehsnm-lkp@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 14.2.0

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
| Closes: https://lore.kernel.org/r/202503132345.uKNehsnm-lkp@intel.com/

smatch warnings:
drivers/hv/vmbus_drv.c:2355 vmbus_set_irq() warn: platform_get_irq() does not return zero

vim +2355 drivers/hv/vmbus_drv.c

2e494cbd89c51d1 Roman Kisel    2025-03-07  2348  static int __maybe_unused vmbus_set_irq(struct platform_device *pdev)
2e494cbd89c51d1 Roman Kisel    2025-03-07  2349  {
2e494cbd89c51d1 Roman Kisel    2025-03-07  2350  	struct irq_data *data;
2e494cbd89c51d1 Roman Kisel    2025-03-07  2351  	int irq;
2e494cbd89c51d1 Roman Kisel    2025-03-07  2352  	irq_hw_number_t hwirq;
2e494cbd89c51d1 Roman Kisel    2025-03-07  2353  
2e494cbd89c51d1 Roman Kisel    2025-03-07  2354  	irq = platform_get_irq(pdev, 0);
2e494cbd89c51d1 Roman Kisel    2025-03-07 @2355  	if (irq == 0) {
2e494cbd89c51d1 Roman Kisel    2025-03-07  2356  		pr_err("VMBus interrupt mapping failure\n");
2e494cbd89c51d1 Roman Kisel    2025-03-07  2357  		return -EINVAL;

You can delete this if statement.  It's dead code.  See the comment
next to platform_get_irq().  I wrote a blog about the history of
this:
https://staticthinking.wordpress.com/2023/08/07/writing-a-check-for-zero-irq-error-codes/

2e494cbd89c51d1 Roman Kisel    2025-03-07  2358  	}
2e494cbd89c51d1 Roman Kisel    2025-03-07  2359  	if (irq < 0) {
2e494cbd89c51d1 Roman Kisel    2025-03-07  2360  		pr_err("VMBus interrupt data can't be read from DeviceTree, error %d\n", irq);
2e494cbd89c51d1 Roman Kisel    2025-03-07  2361  		return irq;
2e494cbd89c51d1 Roman Kisel    2025-03-07  2362  	}
2e494cbd89c51d1 Roman Kisel    2025-03-07  2363  
2e494cbd89c51d1 Roman Kisel    2025-03-07  2364  	data = irq_get_irq_data(irq);
2e494cbd89c51d1 Roman Kisel    2025-03-07  2365  	if (!data) {
2e494cbd89c51d1 Roman Kisel    2025-03-07  2366  		pr_err("No interrupt data for VMBus virq %d\n", irq);
2e494cbd89c51d1 Roman Kisel    2025-03-07  2367  		return -ENODEV;
2e494cbd89c51d1 Roman Kisel    2025-03-07  2368  	}
2e494cbd89c51d1 Roman Kisel    2025-03-07  2369  	hwirq = irqd_to_hwirq(data);
2e494cbd89c51d1 Roman Kisel    2025-03-07  2370  
2e494cbd89c51d1 Roman Kisel    2025-03-07  2371  	vmbus_irq = irq;
2e494cbd89c51d1 Roman Kisel    2025-03-07  2372  	vmbus_interrupt = hwirq;
2e494cbd89c51d1 Roman Kisel    2025-03-07  2373  	pr_debug("VMBus virq %d, hwirq %d\n", vmbus_irq, vmbus_interrupt);
2e494cbd89c51d1 Roman Kisel    2025-03-07  2374  
2e494cbd89c51d1 Roman Kisel    2025-03-07  2375  	return 0;
2e494cbd89c51d1 Roman Kisel    2025-03-07  2376  }

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH hyperv-next v5 08/11] Drivers: hv: vmbus: Get the IRQ number from DeviceTree

[Roman Kisel]

On 3/13/2025 11:31 AM, Dan Carpenter wrote:
> Hi Roman,

Hi Dan,

Appreciate helping with that very much!

-- 
Thank you,
Roman

> 
> kernel test robot noticed the following build warnings:
> 
> url:    https://github.com/intel-lab-lkp/linux/commits/Roman-Kisel/arm64-kvm-smccc-Introduce-and-use-API-for-detectting-hypervisor-presence/20250308-060639
> base:   3a7f7785eae7cf012af128ca9e383c91e4955354
> patch link:    https://lore.kernel.org/r/20250307220304.247725-9-romank%40linux.microsoft.com
> patch subject: [PATCH hyperv-next v5 08/11] Drivers: hv: vmbus: Get the IRQ number from DeviceTree
> config: arm64-randconfig-r071-20250312 (https://download.01.org/0day-ci/archive/20250313/202503132345.uKNehsnm-lkp@intel.com/config)
> compiler: aarch64-linux-gcc (GCC) 14.2.0
> 
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
> | Closes: https://lore.kernel.org/r/202503132345.uKNehsnm-lkp@intel.com/
> 
> smatch warnings:
> drivers/hv/vmbus_drv.c:2355 vmbus_set_irq() warn: platform_get_irq() does not return zero
> 
> vim +2355 drivers/hv/vmbus_drv.c
> 
> 2e494cbd89c51d1 Roman Kisel    2025-03-07  2348  static int __maybe_unused vmbus_set_irq(struct platform_device *pdev)
> 2e494cbd89c51d1 Roman Kisel    2025-03-07  2349  {
> 2e494cbd89c51d1 Roman Kisel    2025-03-07  2350  	struct irq_data *data;
> 2e494cbd89c51d1 Roman Kisel    2025-03-07  2351  	int irq;
> 2e494cbd89c51d1 Roman Kisel    2025-03-07  2352  	irq_hw_number_t hwirq;
> 2e494cbd89c51d1 Roman Kisel    2025-03-07  2353
> 2e494cbd89c51d1 Roman Kisel    2025-03-07  2354  	irq = platform_get_irq(pdev, 0);
> 2e494cbd89c51d1 Roman Kisel    2025-03-07 @2355  	if (irq == 0) {
> 2e494cbd89c51d1 Roman Kisel    2025-03-07  2356  		pr_err("VMBus interrupt mapping failure\n");
> 2e494cbd89c51d1 Roman Kisel    2025-03-07  2357  		return -EINVAL;
> 
> You can delete this if statement.  It's dead code.  See the comment
> next to platform_get_irq().  I wrote a blog about the history of
> this:
> https://staticthinking.wordpress.com/2023/08/07/writing-a-check-for-zero-irq-error-codes/
> 
> 2e494cbd89c51d1 Roman Kisel    2025-03-07  2358  	}
> 2e494cbd89c51d1 Roman Kisel    2025-03-07  2359  	if (irq < 0) {
> 2e494cbd89c51d1 Roman Kisel    2025-03-07  2360  		pr_err("VMBus interrupt data can't be read from DeviceTree, error %d\n", irq);
> 2e494cbd89c51d1 Roman Kisel    2025-03-07  2361  		return irq;
> 2e494cbd89c51d1 Roman Kisel    2025-03-07  2362  	}
> 2e494cbd89c51d1 Roman Kisel    2025-03-07  2363
> 2e494cbd89c51d1 Roman Kisel    2025-03-07  2364  	data = irq_get_irq_data(irq);
> 2e494cbd89c51d1 Roman Kisel    2025-03-07  2365  	if (!data) {
> 2e494cbd89c51d1 Roman Kisel    2025-03-07  2366  		pr_err("No interrupt data for VMBus virq %d\n", irq);
> 2e494cbd89c51d1 Roman Kisel    2025-03-07  2367  		return -ENODEV;
> 2e494cbd89c51d1 Roman Kisel    2025-03-07  2368  	}
> 2e494cbd89c51d1 Roman Kisel    2025-03-07  2369  	hwirq = irqd_to_hwirq(data);
> 2e494cbd89c51d1 Roman Kisel    2025-03-07  2370
> 2e494cbd89c51d1 Roman Kisel    2025-03-07  2371  	vmbus_irq = irq;
> 2e494cbd89c51d1 Roman Kisel    2025-03-07  2372  	vmbus_interrupt = hwirq;
> 2e494cbd89c51d1 Roman Kisel    2025-03-07  2373  	pr_debug("VMBus virq %d, hwirq %d\n", vmbus_irq, vmbus_interrupt);
> 2e494cbd89c51d1 Roman Kisel    2025-03-07  2374
> 2e494cbd89c51d1 Roman Kisel    2025-03-07  2375  	return 0;
> 2e494cbd89c51d1 Roman Kisel    2025-03-07  2376  }
> 

Re: [PATCH hyperv-next v5 08/11] Drivers: hv: vmbus: Get the IRQ number from DeviceTree

[Rob Herring]

On Fri, Mar 7, 2025 at 4:03 PM Roman Kisel <romank@linux.microsoft.com> wrote:
>
> The VMBus driver uses ACPI for interrupt assignment on
> arm64 hence it won't function in the VTL mode where only
> DeviceTree can be used.
>
> Update the VMBus driver to discover interrupt configuration
> from DT.
>
> Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
> Reviewed-by: Michael Kelley <mhklinux@outlook.com>
> ---
>  drivers/hv/vmbus_drv.c | 36 ++++++++++++++++++++++++++++++++++++
>  1 file changed, 36 insertions(+)
>
> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> index 75eb1390b45c..c8474b48dcd2 100644
> --- a/drivers/hv/vmbus_drv.c
> +++ b/drivers/hv/vmbus_drv.c
> @@ -2345,6 +2345,36 @@ static int vmbus_acpi_add(struct platform_device *pdev)
>  }
>  #endif
>
> +static int __maybe_unused vmbus_set_irq(struct platform_device *pdev)
> +{
> +       struct irq_data *data;
> +       int irq;
> +       irq_hw_number_t hwirq;
> +
> +       irq = platform_get_irq(pdev, 0);
> +       if (irq == 0) {
> +               pr_err("VMBus interrupt mapping failure\n");
> +               return -EINVAL;
> +       }
> +       if (irq < 0) {
> +               pr_err("VMBus interrupt data can't be read from DeviceTree, error %d\n", irq);
> +               return irq;
> +       }

I don't think why you couldn't get the interrupt is important. Just
check for (irq <= 0) and be done with it. I'm not even sure if
returning 0 is possible now. There's a long history to that and
NO_IRQ.

Rob

Re: [PATCH hyperv-next v5 08/11] Drivers: hv: vmbus: Get the IRQ number from DeviceTree

[Roman Kisel]

On 3/13/2025 11:44 AM, Rob Herring wrote:
> On Fri, Mar 7, 2025 at 4:03 PM Roman Kisel <romank@linux.microsoft.com> wrote:

[...]

>> +       irq = platform_get_irq(pdev, 0);
>> +       if (irq == 0) {
>> +               pr_err("VMBus interrupt mapping failure\n");
>> +               return -EINVAL;
>> +       }
>> +       if (irq < 0) {
>> +               pr_err("VMBus interrupt data can't be read from DeviceTree, error %d\n", irq);
>> +               return irq;
>> +       }
> 
> I don't think why you couldn't get the interrupt is important. Just
> check for (irq <= 0) and be done with it. I'm not even sure if
> returning 0 is possible now. There's a long history to that and
> NO_IRQ.
> 

That will certainly make the code look much better!
Thank you very much for the idea!

> Rob

-- 
Thank you,
Roman