From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 9CFFA1D6DB5;
	Thu, 23 Apr 2026 12:42:18 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=13.77.154.182
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1776948139; cv=none; b=Pz5ESn3mvPsP5MDgE7nN6ZdFHOw+eTBsUh0dWHPTJejPwWUeqjv3R52VYAuERZQofzX72Z2OnbwwTL3HtF+PEfVB8n10ZklUrRfFbT5hBWuTa1lqu4IOKUnkrnBpGEvDa9ILHhBbHKMx6g6qnqmTbxEqVKeWtTn1UiHRmDyVS8Y=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1776948139; c=relaxed/simple;
	bh=Vgj24s9696zJBAVdUi9THjoSD0kpubPlii50eml5bcU=;
	h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=IQQbbKnfhYC7QnABYMfPsU45AkG5yKeK6S04AFHAw8pcHVyVmvE4QM97XueIgoVHxOTz/Fiz/CZcd2zrz4wBXsQVkqUfUEiItrw7LEsW0J0bjeULszOmu0TiXzCvLlgijqz7mgbQO6qrRHLNjtyWAwR8quf8f1HSEP5MthayDxU=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com; spf=pass smtp.mailfrom=linux.microsoft.com; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b=AGSGwzpn; arc=none smtp.client-ip=13.77.154.182
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="AGSGwzpn"
Received: from CPC-namja-026ON.redmond.corp.microsoft.com (unknown [4.213.232.18])
	by linux.microsoft.com (Postfix) with ESMTPSA id B04AF20B7165;
	Thu, 23 Apr 2026 05:42:10 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com B04AF20B7165
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1776948138;
	bh=nTetde5U51KiR0eBV+LXcTB7GkxgrKWa+3floMLhHNY=;
	h=From:To:Cc:Subject:Date:From;
	b=AGSGwzpn5SgYbJuozOHPeZnNYZQ9uldpmU9A4lC05mLwq5usd/PIzxpuo5lFM9Sfq
	 Xipd4Nv8Nh8GqNV4AwN6AnGqg9CPyCH0gsyxjRn+rL9ykb0o2w2fyRDuy3g6JYa3hP
	 95HqlLPXYHJi9PzX/wV6jI4WAvQWWXbN/Eu9+Ec8=
From: Naman Jain <namjain@linux.microsoft.com>
To: "K . Y . Srinivasan" <kys@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	Wei Liu <wei.liu@kernel.org>,
	Dexuan Cui <decui@microsoft.com>,
	Long Li <longli@microsoft.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Thomas Gleixner <tglx@kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org,
	"H . Peter Anvin" <hpa@zytor.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Paul Walmsley <pjw@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Alexandre Ghiti <alex@ghiti.fr>,
	Michael Kelley <mhklinux@outlook.com>
Cc: Marc Zyngier <maz@kernel.org>,
	Timothy Hayes <timothy.hayes@arm.com>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Sascha Bischoff <sascha.bischoff@arm.com>,
	mrigendrachaubey <mrigendra.chaubey@gmail.com>,
	Naman Jain <namjain@linux.microsoft.com>,
	linux-hyperv@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	linux-arch@vger.kernel.org,
	linux-riscv@lists.infradead.org,
	vdso@mailbox.org,
	ssengar@linux.microsoft.com
Subject: [PATCH v2 00/15] Add arm64 support in MSHV_VTL
Date: Thu, 23 Apr 2026 12:41:50 +0000
Message-ID: <20260423124206.2410879-1-namjain@linux.microsoft.com>
X-Mailer: git-send-email 2.43.0
Precedence: bulk
X-Mailing-List: linux-arch@vger.kernel.org
List-Id: <linux-arch.vger.kernel.org>
List-Subscribe: <mailto:linux-arch+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-arch+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The series adds support for ARM64 to mshv_vtl driver.
For this, common Hyper-V code is refactored, necessary support is added,
mshv_vtl_main.c is refactored and then finally support is added in
Kconfig.

Changes since v1:
https://lore.kernel.org/all/20260316121241.910764-1-namjain@linux.microsoft.com/

Patch 1: arm64: smp: Export arch_smp_send_reschedule for mshv_vtl module
* Changed prefix in subject (Michael)
* Sashiko - no issues

Patch 2:
* Add #include <linux/io.h> in hv_common.c (Michael)
* Remove ms_hyperv.hints change from non TDX case,
  as it won't matter in failure case (Michael)
* Add ms_hyperv.hints &=
  ~HV_X64_ENLIGHTENED_VMCS_RECOMMENDED for TDX
  case, to maintain parity with existing code.
  (Sashiko)
* Handle synic_eventring_tail -ENOMEM issue by
  returning early (Michael|Sashiko)
* Only 4k page is used here, so add dependency on
  PAGE_SIZE_4KB for MSHV_VTL as well in a later
  Kconfig patch (Sashiko|Michael)
* Use HV_HYP_PAGE_SIZE instead of PAGE_SIZE to avoid
  page size mismatch issues (Sashiko)
* s/"vmalloc_to_pfn(*hvp)"/
  "page_to_hvpfn(vmalloc_to_page(*hvp))" in
  hv_common.c (Sashiko|Michael)
* s/GFP_KERNEL/flags in __vmalloc. (Sashiko|Michael)
* Limit code to 80 lines in hv_common_cpu_init (Mukesh R.)
* Move arch based definition of
  HV_VP_ASSIST_PAGE_ADDRESS_SHIFT to
  hvgdk_mini.h (Michael)
* Added a comment about x64 vmalloc_to_pfn(*hvp)) (Michael)
* Move remaining hv_vp_assist_page code from
  arch/x86/include/asm/mshyperv.h to
  include/asm-generic/mshyperv.h (Michael)
* s/HV_SYN_REG_VP_ASSIST_PAGE/HV_MSR_VP_ASSIST_PAGE (Michael)

Patch 3:
* Rework the code and remove these new APIs. Move
  the vmbus_handler global variable and
  hv_setup_vmbus_handler()/hv_remove_vmbus_handler()
  from arch/x86 to drivers/hv/hv_common.c so that
  the same APIs can be used to setup per-cpu vmbus
  handlers as well for arm64. (Michael)

Patch 4:
* Sashiko's comments are generic and outside the
  scope of the refactoring this patch is doing.
  Will take it up separately.

Patch 6:
* Sashiko's comment regarding race condition is false positive.
* Regarding memory leak on cpu offline - online -
  beyond the scope of this series, I will fix it
  separately.

Patch 7:
* Subject s/"arch: arm64:"/"arm64: hyperv:" (Michael)
* Changed commit msg as per Michael's suggestion
* Add kernel_neon_begin(), kernel_neon_end() calls (Sashiko)
* Removed Note prefix from comments (Michael)
* Added compile time check for cpu context to be
  within 1024 bytes of mshv_vtl_run
* Moved the declarations of mshv_vtl_return_call to generic file

Patch 8:
* Split the patch into three patches - number 8-10 (Michael)
* Moved hv_vtl_configure_reg_page declaration to asm-generic header
* Sashiko's other reviews are for existing code,
  I will take them separately

Patch 9: (now patch 11)
No changes required for Sashiko's comments as most
of such controls are intentionally designated to
OpenVMM to keep kernel driver simpler.

Patch 10: (now patch 13)
* Remove hv_setup_percpu_vmbus_handler invocations,
  after redesign in previous patchsets (Michael)
* Simplified mshv_vtl_get_vsm_regs() by moving arch
  specific code (for x86) to hv_vtl -
  mshv_vtl_return_call_init(). This removes arch
  checks in mshv_vtl driver. Add a separate patch
  for this (now patch 12)
* Other Sachiko's reviews are related to existing
  code - can be taken up separately

Patch 11 (now patch 15):
* Only 4k page is supported, so add dependency on
  PAGE_SIZE_4KB for MSHV_VTL (Sashiko|Mihael)
* Remove "Kconfig: " from subject line. (Michael)

New patch 14:
Add a Kconfig dependency on 4K PAGE_SIZE for
MSHV_VTL to manage assumptions in MSHV_VTL driver

Change prefix in subjects as per below naming convention:
mshv_vtl_main changes - "mshv_vtl: "
arch/arm64 Hyper-V changes - "arm64: hyperv: "
arch/x86 Hyper-V changes - "x86/hyperv: "

Add Reviewed-by on already reviewed patches.

Naman Jain (15):
  arm64: smp: Export arch_smp_send_reschedule for mshv_vtl module
  Drivers: hv: Move hv_vp_assist_page to common files
  Drivers: hv: Move vmbus_handler to common code
  mshv_vtl: Refactor the driver for ARM64 support to be added
  Drivers: hv: Export vmbus_interrupt for mshv_vtl module
  mshv_vtl: Make sint vector architecture neutral
  arm64: hyperv: Add support for mshv_vtl_return_call
  Drivers: hv: Move hv_call_(get|set)_vp_registers() declarations
  Drivers: hv: mshv_vtl: Move hv_vtl_configure_reg_page() to x86
  arm64: hyperv: Add hv_vtl_configure_reg_page() stub
  mshv_vtl: Let userspace do VSM configuration
  mshv_vtl: Move VSM code page offset logic to x86 files
  mshv_vtl: Add remaining support for arm64
  Drivers: hv: Add 4K page dependency in MSHV_VTL
  Drivers: hv: Add ARM64 support for MSHV_VTL in Kconfig

 arch/arm64/hyperv/Makefile        |   1 +
 arch/arm64/hyperv/hv_vtl.c        | 165 ++++++++++++++++++++++++
 arch/arm64/include/asm/mshyperv.h |  25 ++++
 arch/arm64/kernel/smp.c           |   1 +
 arch/x86/hyperv/hv_init.c         |  88 +------------
 arch/x86/hyperv/hv_vtl.c          | 149 ++++++++++++++++++++-
 arch/x86/include/asm/mshyperv.h   |  21 +--
 arch/x86/kernel/cpu/mshyperv.c    |  12 --
 drivers/hv/Kconfig                |   7 +-
 drivers/hv/hv_common.c            | 103 ++++++++++++++-
 drivers/hv/mshv.h                 |   8 --
 drivers/hv/mshv_vtl.h             |   3 +
 drivers/hv/mshv_vtl_main.c        | 208 +++---------------------------
 drivers/hv/vmbus_drv.c            |  18 +--
 include/asm-generic/mshyperv.h    |  62 +++++++++
 include/hyperv/hvgdk_mini.h       |   6 +-
 16 files changed, 550 insertions(+), 327 deletions(-)
 create mode 100644 arch/arm64/hyperv/hv_vtl.c

-- 
2.43.0


From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 856A91D6DB5;
	Thu, 23 Apr 2026 12:42:26 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=13.77.154.182
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1776948147; cv=none; b=NDt9bhw/yk9A7BlfK4MrxWSeWExcOHHwd0RApk7fOOjEBuGMqooCXc9F7wfzIPh18oSNfZSuXS19dAjSOw123ODuJlypo5lJ42EUa6BfecnJ2qfhwsKg8BAZt5aSOVxTgg+3xoji2Tl7FKpYriOeS5Yc3KDIadStbDZkXwHMjCI=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1776948147; c=relaxed/simple;
	bh=gNYAnUIiKY0dORHx1+xnjVbI2nukScfNAsanmDS/YPk=;
	h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
	 MIME-Version; b=j5nF7G6UhEepofKNgrhIXycabAV3AiWxsFqCONSkZpEGeU3z0fTJkTm8W8TwCey5yVHF2e9sMctRuexwnSmsiHv42ZsalQTYRRn7xu+8++J8qzBw1CDHDvuhjNRL+QWqSK3wIIifiqYS3p+zAQ59K11P2lK6SCJfxqOt5rSLGow=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com; spf=pass smtp.mailfrom=linux.microsoft.com; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b=sdJr3BxS; arc=none smtp.client-ip=13.77.154.182
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="sdJr3BxS"
Received: from CPC-namja-026ON.redmond.corp.microsoft.com (unknown [4.213.232.18])
	by linux.microsoft.com (Postfix) with ESMTPSA id 2833120B7168;
	Thu, 23 Apr 2026 05:42:18 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 2833120B7168
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1776948146;
	bh=I2iUOz06N9pWMf1bIo71EnFA9O21Frf4P70pvQqdric=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=sdJr3BxSKfa5DEwVFAHUFBYZT3CYc4MAfq8UWukagegS/A86yvkIHkLGL8iNV/AmX
	 sZQvA8TInk618z9cr/L8VcWhIK1vnpLV8JbFypwHHhnWweLdVlRRK6x4v0dVdtqL1i
	 5HUfRb7io3Hlx8KeTctmRzzkcsl9Mi34N8U1zmHM=
From: Naman Jain <namjain@linux.microsoft.com>
To: "K . Y . Srinivasan" <kys@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	Wei Liu <wei.liu@kernel.org>,
	Dexuan Cui <decui@microsoft.com>,
	Long Li <longli@microsoft.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Thomas Gleixner <tglx@kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org,
	"H . Peter Anvin" <hpa@zytor.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Paul Walmsley <pjw@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Alexandre Ghiti <alex@ghiti.fr>,
	Michael Kelley <mhklinux@outlook.com>
Cc: Marc Zyngier <maz@kernel.org>,
	Timothy Hayes <timothy.hayes@arm.com>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Sascha Bischoff <sascha.bischoff@arm.com>,
	mrigendrachaubey <mrigendra.chaubey@gmail.com>,
	Naman Jain <namjain@linux.microsoft.com>,
	linux-hyperv@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	linux-arch@vger.kernel.org,
	linux-riscv@lists.infradead.org,
	vdso@mailbox.org,
	ssengar@linux.microsoft.com
Subject: [PATCH v2 01/15] arm64: smp: Export arch_smp_send_reschedule for mshv_vtl module
Date: Thu, 23 Apr 2026 12:41:51 +0000
Message-ID: <20260423124206.2410879-2-namjain@linux.microsoft.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260423124206.2410879-1-namjain@linux.microsoft.com>
References: <20260423124206.2410879-1-namjain@linux.microsoft.com>
Precedence: bulk
X-Mailing-List: linux-arch@vger.kernel.org
List-Id: <linux-arch.vger.kernel.org>
List-Subscribe: <mailto:linux-arch+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-arch+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

mshv_vtl_main.c calls smp_send_reschedule() which expands to
arch_smp_send_reschedule(). When CONFIG_MSHV_VTL=m, the module cannot
access this symbol since it is not exported on arm64.

smp_send_reschedule() is used in mshv_vtl_cancel() to interrupt a vCPU
thread running on another CPU. When a vCPU is looping in
mshv_vtl_ioctl_return_to_lower_vtl(), it checks a per-CPU cancel flag
before each VTL0 entry. Setting cancel=1 alone is not enough if the
target CPU thread is sleeping - the IPI from smp_send_reschedule() kicks
the remote CPU out of idle/sleep so it re-checks the cancel flag and
exits the loop promptly.

Other architectures (riscv, loongarch, powerpc) already export this
symbol. Add the same EXPORT_SYMBOL_GPL for arm64. This is required
for adding arm64 support in MSHV_VTL.

Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Reviewed-by: Roman Kisel <vdso@mailbox.org>
Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
---
 arch/arm64/kernel/smp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 1aa324104afb..26b1a4456ceb 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -1152,6 +1152,7 @@ void arch_smp_send_reschedule(int cpu)
 {
 	smp_cross_call(cpumask_of(cpu), IPI_RESCHEDULE);
 }
+EXPORT_SYMBOL_GPL(arch_smp_send_reschedule);
 
 #ifdef CONFIG_ARM64_ACPI_PARKING_PROTOCOL
 void arch_send_wakeup_ipi(unsigned int cpu)
-- 
2.43.0


From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id AD6243EDAD3;
	Thu, 23 Apr 2026 12:42:37 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=13.77.154.182
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1776948160; cv=none; b=aOyMAl5Q0PFdlL5HesnAUq5yDHaCXtIZ2Nk3iHRNPBzIETNnRMyrszJW+QTZCT1AvCYcPTSBSIU7uSuYhfiPMaj2ljwFx47AvO9MQEhvvRvZjv8EqDjEfVT15xiR+Gs1myQSb5xcH/Nw/rxMPoaM06FiXzKD0oyC82A6H95YLic=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1776948160; c=relaxed/simple;
	bh=AwpLL0nVqMOd1fFjfITtLnfNhWNRGgzT/57tqpuFJcU=;
	h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
	 MIME-Version; b=Nbw2Ccg2PhIApQqeY5Ungp4K2SEvBkJxULJobK98I096pK+8uXyhmw+vD7EuQNUX9TVDHiJMQsWk/kOdDsFDVq5A6l1UUH1posXNXA6CaJVeSIPHr8+fPpZHYONEkZoKhXBiDu4ekGgZfPdQ5z961jiwERhbFiMhyEAQ1aBUCtY=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com; spf=pass smtp.mailfrom=linux.microsoft.com; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b=gUlDmye2; arc=none smtp.client-ip=13.77.154.182
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="gUlDmye2"
Received: from CPC-namja-026ON.redmond.corp.microsoft.com (unknown [4.213.232.18])
	by linux.microsoft.com (Postfix) with ESMTPSA id 3897E20B7169;
	Thu, 23 Apr 2026 05:42:27 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 3897E20B7169
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1776948154;
	bh=zLzms2JDLRJRnvdbHRjSQjPRubfamtoDlwMUbgfve34=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=gUlDmye22rkeSlONYLXTNUDycGTkKyaZAW9hKnGf/4dlX2h/INs0GEIPhuIU0A4Br
	 Y/EzKEDkmn2j7HHcwARzseniD46X07CpcUXz+UTJzepzrklDfpFLTwH1Fi73l8V6z2
	 3graOJdNxm6PWIjh1jCyDaWhrMiYI2ByxcFZCMEI=
From: Naman Jain <namjain@linux.microsoft.com>
To: "K . Y . Srinivasan" <kys@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	Wei Liu <wei.liu@kernel.org>,
	Dexuan Cui <decui@microsoft.com>,
	Long Li <longli@microsoft.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Thomas Gleixner <tglx@kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org,
	"H . Peter Anvin" <hpa@zytor.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Paul Walmsley <pjw@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Alexandre Ghiti <alex@ghiti.fr>,
	Michael Kelley <mhklinux@outlook.com>
Cc: Marc Zyngier <maz@kernel.org>,
	Timothy Hayes <timothy.hayes@arm.com>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Sascha Bischoff <sascha.bischoff@arm.com>,
	mrigendrachaubey <mrigendra.chaubey@gmail.com>,
	Naman Jain <namjain@linux.microsoft.com>,
	linux-hyperv@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	linux-arch@vger.kernel.org,
	linux-riscv@lists.infradead.org,
	vdso@mailbox.org,
	ssengar@linux.microsoft.com
Subject: [PATCH v2 02/15] Drivers: hv: Move hv_vp_assist_page to common files
Date: Thu, 23 Apr 2026 12:41:52 +0000
Message-ID: <20260423124206.2410879-3-namjain@linux.microsoft.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260423124206.2410879-1-namjain@linux.microsoft.com>
References: <20260423124206.2410879-1-namjain@linux.microsoft.com>
Precedence: bulk
X-Mailing-List: linux-arch@vger.kernel.org
List-Id: <linux-arch.vger.kernel.org>
List-Subscribe: <mailto:linux-arch+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-arch+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Move the logic to initialize and export hv_vp_assist_page from x86
architecture code to Hyper-V common code to allow it to be used for
upcoming arm64 support in MSHV_VTL driver.
Note: This change also improves error handling - if VP assist page
allocation fails, hyperv_init() now returns early instead of
continuing with partial initialization.

Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
Reviewed-by: Roman Kisel <vdso@mailbox.org>
Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
---
 arch/x86/hyperv/hv_init.c       | 88 +-----------------------------
 arch/x86/include/asm/mshyperv.h | 14 -----
 drivers/hv/hv_common.c          | 94 ++++++++++++++++++++++++++++++++-
 include/asm-generic/mshyperv.h  | 16 ++++++
 include/hyperv/hvgdk_mini.h     |  6 ++-
 5 files changed, 115 insertions(+), 103 deletions(-)

diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index 323adc93f2dc..75a98b5e451b 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -81,9 +81,6 @@ union hv_ghcb * __percpu *hv_ghcb_pg;
 /* Storage to save the hypercall page temporarily for hibernation */
 static void *hv_hypercall_pg_saved;
 
-struct hv_vp_assist_page **hv_vp_assist_page;
-EXPORT_SYMBOL_GPL(hv_vp_assist_page);
-
 static int hyperv_init_ghcb(void)
 {
 	u64 ghcb_gpa;
@@ -117,59 +114,12 @@ static int hyperv_init_ghcb(void)
 
 static int hv_cpu_init(unsigned int cpu)
 {
-	union hv_vp_assist_msr_contents msr = { 0 };
-	struct hv_vp_assist_page **hvp;
 	int ret;
 
 	ret = hv_common_cpu_init(cpu);
 	if (ret)
 		return ret;
 
-	if (!hv_vp_assist_page)
-		return 0;
-
-	hvp = &hv_vp_assist_page[cpu];
-	if (hv_root_partition()) {
-		/*
-		 * For root partition we get the hypervisor provided VP assist
-		 * page, instead of allocating a new page.
-		 */
-		rdmsrq(HV_X64_MSR_VP_ASSIST_PAGE, msr.as_uint64);
-		*hvp = memremap(msr.pfn << HV_X64_MSR_VP_ASSIST_PAGE_ADDRESS_SHIFT,
-				PAGE_SIZE, MEMREMAP_WB);
-	} else {
-		/*
-		 * The VP assist page is an "overlay" page (see Hyper-V TLFS's
-		 * Section 5.2.1 "GPA Overlay Pages"). Here it must be zeroed
-		 * out to make sure we always write the EOI MSR in
-		 * hv_apic_eoi_write() *after* the EOI optimization is disabled
-		 * in hv_cpu_die(), otherwise a CPU may not be stopped in the
-		 * case of CPU offlining and the VM will hang.
-		 */
-		if (!*hvp) {
-			*hvp = __vmalloc(PAGE_SIZE, GFP_KERNEL | __GFP_ZERO);
-
-			/*
-			 * Hyper-V should never specify a VM that is a Confidential
-			 * VM and also running in the root partition. Root partition
-			 * is blocked to run in Confidential VM. So only decrypt assist
-			 * page in non-root partition here.
-			 */
-			if (*hvp && !ms_hyperv.paravisor_present && hv_isolation_type_snp()) {
-				WARN_ON_ONCE(set_memory_decrypted((unsigned long)(*hvp), 1));
-				memset(*hvp, 0, PAGE_SIZE);
-			}
-		}
-
-		if (*hvp)
-			msr.pfn = vmalloc_to_pfn(*hvp);
-
-	}
-	if (!WARN_ON(!(*hvp))) {
-		msr.enable = 1;
-		wrmsrq(HV_X64_MSR_VP_ASSIST_PAGE, msr.as_uint64);
-	}
-
 	/* Allow Hyper-V stimer vector to be injected from Hypervisor. */
 	if (ms_hyperv.misc_features & HV_STIMER_DIRECT_MODE_AVAILABLE)
 		apic_update_vector(cpu, HYPERV_STIMER0_VECTOR, true);
@@ -286,23 +236,6 @@ static int hv_cpu_die(unsigned int cpu)
 
 	hv_common_cpu_die(cpu);
 
-	if (hv_vp_assist_page && hv_vp_assist_page[cpu]) {
-		union hv_vp_assist_msr_contents msr = { 0 };
-		if (hv_root_partition()) {
-			/*
-			 * For root partition the VP assist page is mapped to
-			 * hypervisor provided page, and thus we unmap the
-			 * page here and nullify it, so that in future we have
-			 * correct page address mapped in hv_cpu_init.
-			 */
-			memunmap(hv_vp_assist_page[cpu]);
-			hv_vp_assist_page[cpu] = NULL;
-			rdmsrq(HV_X64_MSR_VP_ASSIST_PAGE, msr.as_uint64);
-			msr.enable = 0;
-		}
-		wrmsrq(HV_X64_MSR_VP_ASSIST_PAGE, msr.as_uint64);
-	}
-
 	if (hv_reenlightenment_cb == NULL)
 		return 0;
 
@@ -460,21 +393,6 @@ void __init hyperv_init(void)
 	if (hv_common_init())
 		return;
 
-	/*
-	 * The VP assist page is useless to a TDX guest: the only use we
-	 * would have for it is lazy EOI, which can not be used with TDX.
-	 */
-	if (hv_isolation_type_tdx())
-		hv_vp_assist_page = NULL;
-	else
-		hv_vp_assist_page = kzalloc_objs(*hv_vp_assist_page, nr_cpu_ids);
-	if (!hv_vp_assist_page) {
-		ms_hyperv.hints &= ~HV_X64_ENLIGHTENED_VMCS_RECOMMENDED;
-
-		if (!hv_isolation_type_tdx())
-			goto common_free;
-	}
-
 	if (ms_hyperv.paravisor_present && hv_isolation_type_snp()) {
 		/* Negotiate GHCB Version. */
 		if (!hv_ghcb_negotiate_protocol())
@@ -483,7 +401,7 @@ void __init hyperv_init(void)
 
 		hv_ghcb_pg = alloc_percpu(union hv_ghcb *);
 		if (!hv_ghcb_pg)
-			goto free_vp_assist_page;
+			goto free_ghcb_page;
 	}
 
 	cpuhp = cpuhp_setup_state(CPUHP_AP_HYPERV_ONLINE, "x86/hyperv_init:online",
@@ -613,10 +531,6 @@ void __init hyperv_init(void)
 	cpuhp_remove_state(CPUHP_AP_HYPERV_ONLINE);
 free_ghcb_page:
 	free_percpu(hv_ghcb_pg);
-free_vp_assist_page:
-	kfree(hv_vp_assist_page);
-	hv_vp_assist_page = NULL;
-common_free:
 	hv_common_free();
 }
 
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index f64393e853ee..95b452387969 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -155,16 +155,6 @@ static inline u64 hv_do_fast_hypercall16(u16 code, u64 input1, u64 input2)
 	return _hv_do_fast_hypercall16(control, input1, input2);
 }
 
-extern struct hv_vp_assist_page **hv_vp_assist_page;
-
-static inline struct hv_vp_assist_page *hv_get_vp_assist_page(unsigned int cpu)
-{
-	if (!hv_vp_assist_page)
-		return NULL;
-
-	return hv_vp_assist_page[cpu];
-}
-
 void __init hyperv_init(void);
 void hyperv_setup_mmu_ops(void);
 void set_hv_tscchange_cb(void (*cb)(void));
@@ -254,10 +244,6 @@ static inline void hyperv_setup_mmu_ops(void) {}
 static inline void set_hv_tscchange_cb(void (*cb)(void)) {}
 static inline void clear_hv_tscchange_cb(void) {}
 static inline void hyperv_stop_tsc_emulation(void) {};
-static inline struct hv_vp_assist_page *hv_get_vp_assist_page(unsigned int cpu)
-{
-	return NULL;
-}
 static inline int hyperv_flush_guest_mapping(u64 as) { return -1; }
 static inline int hyperv_flush_guest_mapping_range(u64 as,
 		hyperv_fill_flush_list_func fill_func, void *data)
diff --git a/drivers/hv/hv_common.c b/drivers/hv/hv_common.c
index 6b67ac616789..e8633bc51d56 100644
--- a/drivers/hv/hv_common.c
+++ b/drivers/hv/hv_common.c
@@ -28,7 +28,11 @@
 #include <linux/slab.h>
 #include <linux/dma-map-ops.h>
 #include <linux/set_memory.h>
+#include <linux/vmalloc.h>
+#include <linux/io.h>
+#include <linux/hyperv.h>
 #include <hyperv/hvhdk.h>
+#include <hyperv/hvgdk.h>
 #include <asm/mshyperv.h>
 
 u64 hv_current_partition_id = HV_PARTITION_ID_SELF;
@@ -78,6 +82,8 @@ static struct ctl_table_header *hv_ctl_table_hdr;
 u8 * __percpu *hv_synic_eventring_tail;
 EXPORT_SYMBOL_GPL(hv_synic_eventring_tail);
 
+struct hv_vp_assist_page **hv_vp_assist_page;
+EXPORT_SYMBOL_GPL(hv_vp_assist_page);
 /*
  * Hyper-V specific initialization and shutdown code that is
  * common across all architectures.  Called from architecture
@@ -92,6 +98,9 @@ void __init hv_common_free(void)
 	if (ms_hyperv.misc_features & HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE)
 		hv_kmsg_dump_unregister();
 
+	kfree(hv_vp_assist_page);
+	hv_vp_assist_page = NULL;
+
 	kfree(hv_vp_index);
 	hv_vp_index = NULL;
 
@@ -394,6 +403,23 @@ int __init hv_common_init(void)
 	for (i = 0; i < nr_cpu_ids; i++)
 		hv_vp_index[i] = VP_INVAL;
 
+	/*
+	 * The VP assist page is useless to a TDX guest: the only use we
+	 * would have for it is lazy EOI, which can not be used with TDX.
+	 */
+	if (hv_isolation_type_tdx()) {
+		hv_vp_assist_page = NULL;
+#ifdef CONFIG_X86_64
+		ms_hyperv.hints &= ~HV_X64_ENLIGHTENED_VMCS_RECOMMENDED;
+#endif
+	} else {
+		hv_vp_assist_page = kzalloc_objs(*hv_vp_assist_page, nr_cpu_ids);
+		if (!hv_vp_assist_page) {
+			hv_common_free();
+			return -ENOMEM;
+		}
+	}
+
 	return 0;
 }
 
@@ -471,6 +497,8 @@ void __init ms_hyperv_late_init(void)
 
 int hv_common_cpu_init(unsigned int cpu)
 {
+	union hv_vp_assist_msr_contents msr = { 0 };
+	struct hv_vp_assist_page **hvp;
 	void **inputarg, **outputarg;
 	u8 **synic_eventring_tail;
 	u64 msr_vp_index;
@@ -539,7 +567,53 @@ int hv_common_cpu_init(unsigned int cpu)
 						sizeof(u8), flags);
 		/* No need to unwind any of the above on failure here */
 		if (unlikely(!*synic_eventring_tail))
-			ret = -ENOMEM;
+			return -ENOMEM;
+	}
+
+	if (!hv_vp_assist_page)
+		return ret;
+
+	hvp = &hv_vp_assist_page[cpu];
+	if (hv_root_partition()) {
+		/*
+		 * For root partition we get the hypervisor provided VP assist
+		 * page, instead of allocating a new page.
+		 */
+		msr.as_uint64 = hv_get_msr(HV_MSR_VP_ASSIST_PAGE);
+		*hvp = memremap(msr.pfn << HV_VP_ASSIST_PAGE_ADDRESS_SHIFT,
+				HV_HYP_PAGE_SIZE, MEMREMAP_WB);
+	} else {
+		/*
+		 * The VP assist page is an "overlay" page (see Hyper-V TLFS's
+		 * Section 5.2.1 "GPA Overlay Pages"). Here it must be zeroed
+		 * out to make sure that on x86/x64, we always write the EOI MSR in
+		 * hv_apic_eoi_write() *after* the EOI optimization is disabled
+		 * in hv_cpu_die(), otherwise a CPU may not be stopped in the
+		 * case of CPU offlining and the VM will hang.
+		 */
+		if (!*hvp) {
+			*hvp = __vmalloc(HV_HYP_PAGE_SIZE, flags | __GFP_ZERO);
+
+			/*
+			 * Hyper-V should never specify a VM that is a Confidential
+			 * VM and also running in the root partition. Root partition
+			 * is blocked to run in Confidential VM. So only decrypt assist
+			 * page in non-root partition here.
+			 */
+			if (*hvp &&
+			    !ms_hyperv.paravisor_present &&
+			    hv_isolation_type_snp()) {
+				WARN_ON_ONCE(set_memory_decrypted((unsigned long)(*hvp), 1));
+				memset(*hvp, 0, HV_HYP_PAGE_SIZE);
+			}
+		}
+
+		if (*hvp)
+			msr.pfn = page_to_hvpfn(vmalloc_to_page(*hvp));
+	}
+	if (!WARN_ON(!(*hvp))) {
+		msr.enable = 1;
+		hv_set_msr(HV_MSR_VP_ASSIST_PAGE, msr.as_uint64);
 	}
 
 	return ret;
@@ -566,6 +640,24 @@ int hv_common_cpu_die(unsigned int cpu)
 		*synic_eventring_tail = NULL;
 	}
 
+	if (hv_vp_assist_page && hv_vp_assist_page[cpu]) {
+		union hv_vp_assist_msr_contents msr = { 0 };
+
+		if (hv_root_partition()) {
+			/*
+			 * For root partition the VP assist page is mapped to
+			 * hypervisor provided page, and thus we unmap the
+			 * page here and nullify it, so that in future we have
+			 * correct page address mapped in hv_cpu_init.
+			 */
+			memunmap(hv_vp_assist_page[cpu]);
+			hv_vp_assist_page[cpu] = NULL;
+			msr.as_uint64 = hv_get_msr(HV_MSR_VP_ASSIST_PAGE);
+			msr.enable = 0;
+		}
+		hv_set_msr(HV_MSR_VP_ASSIST_PAGE, msr.as_uint64);
+	}
+
 	return 0;
 }
 
diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyperv.h
index d37b68238c97..2810aa05dc73 100644
--- a/include/asm-generic/mshyperv.h
+++ b/include/asm-generic/mshyperv.h
@@ -25,6 +25,7 @@
 #include <linux/nmi.h>
 #include <asm/ptrace.h>
 #include <hyperv/hvhdk.h>
+#include <hyperv/hvgdk.h>
 
 #define VTPM_BASE_ADDRESS 0xfed40000
 
@@ -299,6 +300,16 @@ do { \
 #define hv_status_debug(status, fmt, ...) \
 	hv_status_printk(debug, status, fmt, ##__VA_ARGS__)
 
+extern struct hv_vp_assist_page **hv_vp_assist_page;
+
+static inline struct hv_vp_assist_page *hv_get_vp_assist_page(unsigned int cpu)
+{
+	if (!hv_vp_assist_page)
+		return NULL;
+
+	return hv_vp_assist_page[cpu];
+}
+
 const char *hv_result_to_string(u64 hv_status);
 int hv_result_to_errno(u64 status);
 void hyperv_report_panic(struct pt_regs *regs, long err, bool in_die);
@@ -327,6 +338,11 @@ static inline enum hv_isolation_type hv_get_isolation_type(void)
 {
 	return HV_ISOLATION_TYPE_NONE;
 }
+
+static inline struct hv_vp_assist_page *hv_get_vp_assist_page(unsigned int cpu)
+{
+	return NULL;
+}
 #endif /* CONFIG_HYPERV */
 
 #if IS_ENABLED(CONFIG_MSHV_ROOT)
diff --git a/include/hyperv/hvgdk_mini.h b/include/hyperv/hvgdk_mini.h
index 056ef7b6b360..c72d04cd5ae4 100644
--- a/include/hyperv/hvgdk_mini.h
+++ b/include/hyperv/hvgdk_mini.h
@@ -149,6 +149,7 @@ struct hv_u128 {
 #define HV_X64_MSR_VP_ASSIST_PAGE_ADDRESS_SHIFT	12
 #define HV_X64_MSR_VP_ASSIST_PAGE_ADDRESS_MASK	\
 		(~((1ull << HV_X64_MSR_VP_ASSIST_PAGE_ADDRESS_SHIFT) - 1))
+#define HV_MSR_VP_ASSIST_PAGE              (HV_X64_MSR_VP_ASSIST_PAGE)
 
 /* Hyper-V Enlightened VMCS version mask in nested features CPUID */
 #define HV_X64_ENLIGHTENED_VMCS_VERSION		0xff
@@ -410,6 +411,7 @@ union hv_x64_msr_hypercall_contents {
 #if defined(CONFIG_ARM64)
 #define HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE	BIT(8)
 #define HV_STIMER_DIRECT_MODE_AVAILABLE		BIT(13)
+#define HV_VP_ASSIST_PAGE_ADDRESS_SHIFT 12
 #endif /* CONFIG_ARM64 */
 
 #if defined(CONFIG_X86)
@@ -1163,6 +1165,8 @@ enum hv_register_name {
 #define HV_MSR_STIMER0_CONFIG	(HV_X64_MSR_STIMER0_CONFIG)
 #define HV_MSR_STIMER0_COUNT	(HV_X64_MSR_STIMER0_COUNT)
 
+#define HV_VP_ASSIST_PAGE_ADDRESS_SHIFT HV_X64_MSR_VP_ASSIST_PAGE_ADDRESS_SHIFT
+
 #elif defined(CONFIG_ARM64) /* CONFIG_X86 */
 
 #define HV_MSR_CRASH_P0		(HV_REGISTER_GUEST_CRASH_P0)
@@ -1185,7 +1189,7 @@ enum hv_register_name {
 
 #define HV_MSR_STIMER0_CONFIG	(HV_REGISTER_STIMER0_CONFIG)
 #define HV_MSR_STIMER0_COUNT	(HV_REGISTER_STIMER0_COUNT)
-
+#define HV_MSR_VP_ASSIST_PAGE    (HV_REGISTER_VP_ASSIST_PAGE)
 #endif /* CONFIG_ARM64 */
 
 union hv_explicit_suspend_register {
-- 
2.43.0


From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 76BE13EDAD3;
	Thu, 23 Apr 2026 12:42:46 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=13.77.154.182
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1776948167; cv=none; b=HM9lCX/l407oehMWQ751gmvlyVR1OpJUqpLSKTa4TMu/5RogzaSQoEH8y1nJTCy5a++Adb+HSM6bD9d2mKnngcmxypNGJC28jjnXMGN4upcb8A+8GE6OaqrJ3sr03A5dFfDDyJtYIv+utr96lyMKyXT3OvD+tmzv627vxLGGUI0=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1776948167; c=relaxed/simple;
	bh=O/KxpLA9As2ClJGwVyI5h46bbQ5m3KVt+eTtzgD7ddI=;
	h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
	 MIME-Version; b=XvH9O+cFvjeJC6BHebye7qP0F4MpLbpFJNmOnxXlPwI3QD5TIll6KR6ysKpDvlbOJQOh3U3l70aYrwX5Qpk+2VCcYBSA2b2C2Os1HgJf3lpks1h72fdOYb15wxtDVOFaAZCMyQqpf8F877OAFW0QR1Fep7+qf4IVZXf4XJrNl0M=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com; spf=pass smtp.mailfrom=linux.microsoft.com; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b=XxtnKmAZ; arc=none smtp.client-ip=13.77.154.182
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="XxtnKmAZ"
Received: from CPC-namja-026ON.redmond.corp.microsoft.com (unknown [4.213.232.18])
	by linux.microsoft.com (Postfix) with ESMTPSA id 6A37520B716E;
	Thu, 23 Apr 2026 05:42:38 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 6A37520B716E
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1776948165;
	bh=RgOk9CuNiMb2ueZsexw1395h43OXuM/ZLDHAurB/vUw=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=XxtnKmAZkBsl1fo5vHmG1yFvwFiMsZTf0tpny7IxDVM9D9co5+6lVoSiRvy5ZEWXL
	 m/QTC0zSPOY++7G88l5sW5gq6ud3jQim6h/EFnC2Hp3qNkNFTjTwp2dqZtRDLlCAfk
	 FJuSJjmd4QdYK/ZdtpBJGsvpEESRR2oihG4xQh/I=
From: Naman Jain <namjain@linux.microsoft.com>
To: "K . Y . Srinivasan" <kys@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	Wei Liu <wei.liu@kernel.org>,
	Dexuan Cui <decui@microsoft.com>,
	Long Li <longli@microsoft.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Thomas Gleixner <tglx@kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org,
	"H . Peter Anvin" <hpa@zytor.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Paul Walmsley <pjw@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Alexandre Ghiti <alex@ghiti.fr>,
	Michael Kelley <mhklinux@outlook.com>
Cc: Marc Zyngier <maz@kernel.org>,
	Timothy Hayes <timothy.hayes@arm.com>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Sascha Bischoff <sascha.bischoff@arm.com>,
	mrigendrachaubey <mrigendra.chaubey@gmail.com>,
	Naman Jain <namjain@linux.microsoft.com>,
	linux-hyperv@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	linux-arch@vger.kernel.org,
	linux-riscv@lists.infradead.org,
	vdso@mailbox.org,
	ssengar@linux.microsoft.com
Subject: [PATCH v2 03/15] Drivers: hv: Move vmbus_handler to common code
Date: Thu, 23 Apr 2026 12:41:53 +0000
Message-ID: <20260423124206.2410879-4-namjain@linux.microsoft.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260423124206.2410879-1-namjain@linux.microsoft.com>
References: <20260423124206.2410879-1-namjain@linux.microsoft.com>
Precedence: bulk
X-Mailing-List: linux-arch@vger.kernel.org
List-Id: <linux-arch.vger.kernel.org>
List-Subscribe: <mailto:linux-arch+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-arch+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Move the vmbus_handler global variable and hv_setup_vmbus_handler()/
hv_remove_vmbus_handler() from arch/x86 to drivers/hv/hv_common.c.

hv_setup_vmbus_handler() is called unconditionally in vmbus_bus_init()
and works for both x86 (sysvec handler) and arm64 (vmbus_percpu_isr).

This eliminates the need for separate percpu vmbus handler setup
functions and __weak stubs, that are needed for adding ARM64 support
in MSHV_VTL driver where we need to set a custom per-cpu vmbus handler.

Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
---
 arch/x86/kernel/cpu/mshyperv.c | 12 ------------
 drivers/hv/hv_common.c         |  9 +++++++--
 drivers/hv/vmbus_drv.c         | 17 +++++++++--------
 include/asm-generic/mshyperv.h |  1 +
 4 files changed, 17 insertions(+), 22 deletions(-)

diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 89a2eb8a0722..68706ff5880e 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -145,7 +145,6 @@ void hv_set_msr(unsigned int reg, u64 value)
 EXPORT_SYMBOL_GPL(hv_set_msr);
 
 static void (*mshv_handler)(void);
-static void (*vmbus_handler)(void);
 static void (*hv_stimer0_handler)(void);
 static void (*hv_kexec_handler)(void);
 static void (*hv_crash_handler)(struct pt_regs *regs);
@@ -172,17 +171,6 @@ void hv_setup_mshv_handler(void (*handler)(void))
 	mshv_handler = handler;
 }
 
-void hv_setup_vmbus_handler(void (*handler)(void))
-{
-	vmbus_handler = handler;
-}
-
-void hv_remove_vmbus_handler(void)
-{
-	/* We have no way to deallocate the interrupt gate */
-	vmbus_handler = NULL;
-}
-
 /*
  * Routines to do per-architecture handling of stimer0
  * interrupts when in Direct Mode
diff --git a/drivers/hv/hv_common.c b/drivers/hv/hv_common.c
index e8633bc51d56..eb7b0028b45d 100644
--- a/drivers/hv/hv_common.c
+++ b/drivers/hv/hv_common.c
@@ -758,13 +758,18 @@ bool __weak hv_isolation_type_tdx(void)
 }
 EXPORT_SYMBOL_GPL(hv_isolation_type_tdx);
 
-void __weak hv_setup_vmbus_handler(void (*handler)(void))
+void (*vmbus_handler)(void);
+EXPORT_SYMBOL_GPL(vmbus_handler);
+
+void hv_setup_vmbus_handler(void (*handler)(void))
 {
+	vmbus_handler = handler;
 }
 EXPORT_SYMBOL_GPL(hv_setup_vmbus_handler);
 
-void __weak hv_remove_vmbus_handler(void)
+void hv_remove_vmbus_handler(void)
 {
+	vmbus_handler = NULL;
 }
 EXPORT_SYMBOL_GPL(hv_remove_vmbus_handler);
 
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index bc4fc1951ae1..052ca8b11cee 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -1415,7 +1415,8 @@ EXPORT_SYMBOL_FOR_MODULES(vmbus_isr, "mshv_vtl");
 
 static irqreturn_t vmbus_percpu_isr(int irq, void *dev_id)
 {
-	vmbus_isr();
+	if (vmbus_handler)
+		vmbus_handler();
 	return IRQ_HANDLED;
 }
 
@@ -1517,8 +1518,10 @@ static int vmbus_bus_init(void)
 		vmbus_irq_initialized = true;
 	}
 
+	hv_setup_vmbus_handler(vmbus_isr);
+
 	if (vmbus_irq == -1) {
-		hv_setup_vmbus_handler(vmbus_isr);
+		/* x86: sysvec handler uses vmbus_handler directly */
 	} else {
 		ret = request_percpu_irq(vmbus_irq, vmbus_percpu_isr,
 				"Hyper-V VMbus", &vmbus_evt);
@@ -1553,9 +1556,8 @@ static int vmbus_bus_init(void)
 	return 0;
 
 err_connect:
-	if (vmbus_irq == -1)
-		hv_remove_vmbus_handler();
-	else
+	hv_remove_vmbus_handler();
+	if (vmbus_irq != -1)
 		free_percpu_irq(vmbus_irq, &vmbus_evt);
 err_setup:
 	if (IS_ENABLED(CONFIG_PREEMPT_RT) && vmbus_irq_initialized) {
@@ -3026,9 +3028,8 @@ static void __exit vmbus_exit(void)
 	vmbus_connection.conn_state = DISCONNECTED;
 	hv_stimer_global_cleanup();
 	vmbus_disconnect();
-	if (vmbus_irq == -1)
-		hv_remove_vmbus_handler();
-	else
+	hv_remove_vmbus_handler();
+	if (vmbus_irq != -1)
 		free_percpu_irq(vmbus_irq, &vmbus_evt);
 	if (IS_ENABLED(CONFIG_PREEMPT_RT) && vmbus_irq_initialized) {
 		smpboot_unregister_percpu_thread(&vmbus_irq_threads);
diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyperv.h
index 2810aa05dc73..db183c8cfb95 100644
--- a/include/asm-generic/mshyperv.h
+++ b/include/asm-generic/mshyperv.h
@@ -179,6 +179,7 @@ static inline u64 hv_generate_guest_id(u64 kernel_version)
 
 int hv_get_hypervisor_version(union hv_hypervisor_version_info *info);
 
+extern void (*vmbus_handler)(void);
 void hv_setup_vmbus_handler(void (*handler)(void));
 void hv_remove_vmbus_handler(void);
 void hv_setup_stimer0_handler(void (*handler)(void));
-- 
2.43.0


From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id A3B7E1D6DB5;
	Thu, 23 Apr 2026 12:42:54 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=13.77.154.182
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1776948176; cv=none; b=XF5exliQl+JqGHol4VTiYU7Gw2mHf2cIhX83S9wU0n9d2DaSmVfPQ54AgaqsDglJj48+R2nTp/S4sCB2XbGntpvrcky8tp3EqMDS2n8Ns9fbNPDMyFKI6QF2/t7idxqqrYWzl87P9OBpeQadT0Ao6QGZj+Klq+g+wfT09PefpD8=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1776948176; c=relaxed/simple;
	bh=lRYGL8+M5E0O+MiNmFHULhnPKzeLquiWbMmrAztQqLE=;
	h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
	 MIME-Version; b=aVb6jhH46H4apTbaIiFBHKMsjrf8SBy/XQnyzDmtQZg6hKD1G7vzKRqla7E32Yg4pqOwnRynAVfOEJzshvgtbiDQKanmTzlOb0MdCkyLC4nqH6JoFnwMksSdQtJenLYrZueb9K5OWZ5h3Jm0WymqAmBksa6OIe91jVLtu9n9Rlo=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com; spf=pass smtp.mailfrom=linux.microsoft.com; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b=n2e5wkn5; arc=none smtp.client-ip=13.77.154.182
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="n2e5wkn5"
Received: from CPC-namja-026ON.redmond.corp.microsoft.com (unknown [4.213.232.18])
	by linux.microsoft.com (Postfix) with ESMTPSA id 39EBD20B7168;
	Thu, 23 Apr 2026 05:42:47 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 39EBD20B7168
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1776948174;
	bh=eNolo9wcc/fCgDUj7KA5ML74AnpbIf9VjPZXjw3boPg=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=n2e5wkn5BvqRZ8mdLLsZQSI8g8S42lIFbSAihELRZ+HRaNQfthfVpZ5hrgsdVS6q9
	 KVc3GVsEIYc0vhw7usGqUKjhA8dtShi6Rzt6nuf6E8nR/xHQVQkYUZwM3RjCuEgges
	 1JjNR8+ZmpbWrz9eTFbdbhvqwODXrxL6viSw8ipc=
From: Naman Jain <namjain@linux.microsoft.com>
To: "K . Y . Srinivasan" <kys@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	Wei Liu <wei.liu@kernel.org>,
	Dexuan Cui <decui@microsoft.com>,
	Long Li <longli@microsoft.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Thomas Gleixner <tglx@kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org,
	"H . Peter Anvin" <hpa@zytor.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Paul Walmsley <pjw@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Alexandre Ghiti <alex@ghiti.fr>,
	Michael Kelley <mhklinux@outlook.com>
Cc: Marc Zyngier <maz@kernel.org>,
	Timothy Hayes <timothy.hayes@arm.com>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Sascha Bischoff <sascha.bischoff@arm.com>,
	mrigendrachaubey <mrigendra.chaubey@gmail.com>,
	Naman Jain <namjain@linux.microsoft.com>,
	linux-hyperv@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	linux-arch@vger.kernel.org,
	linux-riscv@lists.infradead.org,
	vdso@mailbox.org,
	ssengar@linux.microsoft.com
Subject: [PATCH v2 04/15] mshv_vtl: Refactor the driver for ARM64 support to be added
Date: Thu, 23 Apr 2026 12:41:54 +0000
Message-ID: <20260423124206.2410879-5-namjain@linux.microsoft.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260423124206.2410879-1-namjain@linux.microsoft.com>
References: <20260423124206.2410879-1-namjain@linux.microsoft.com>
Precedence: bulk
X-Mailing-List: linux-arch@vger.kernel.org
List-Id: <linux-arch.vger.kernel.org>
List-Subscribe: <mailto:linux-arch+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-arch+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Refactor MSHV_VTL driver to move some of the x86 specific code to arch
specific files, and add corresponding functions for arm64.

Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
Reviewed-by: Roman Kisel <vdso@mailbox.org>
Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
---
 arch/arm64/include/asm/mshyperv.h |  10 +++
 arch/x86/hyperv/hv_vtl.c          |  98 ++++++++++++++++++++++++++++
 arch/x86/include/asm/mshyperv.h   |   1 +
 drivers/hv/mshv_vtl_main.c        | 102 +-----------------------------
 4 files changed, 111 insertions(+), 100 deletions(-)

diff --git a/arch/arm64/include/asm/mshyperv.h b/arch/arm64/include/asm/mshyperv.h
index b721d3134ab6..585b23a26f1b 100644
--- a/arch/arm64/include/asm/mshyperv.h
+++ b/arch/arm64/include/asm/mshyperv.h
@@ -60,6 +60,16 @@ static inline u64 hv_get_non_nested_msr(unsigned int reg)
 				ARM_SMCCC_SMC_64,		\
 				ARM_SMCCC_OWNER_VENDOR_HYP,	\
 				HV_SMCCC_FUNC_NUMBER)
+#ifdef CONFIG_HYPERV_VTL_MODE
+/*
+ * Get/Set the register. If the function returns `1`, that must be done via
+ * a hypercall. Returning `0` means success.
+ */
+static inline int hv_vtl_get_set_reg(struct hv_register_assoc *regs, bool set, bool shared)
+{
+	return 1;
+}
+#endif
 
 #include <asm-generic/mshyperv.h>
 
diff --git a/arch/x86/hyperv/hv_vtl.c b/arch/x86/hyperv/hv_vtl.c
index 9b6a9bc4ab76..09d81f9b853c 100644
--- a/arch/x86/hyperv/hv_vtl.c
+++ b/arch/x86/hyperv/hv_vtl.c
@@ -17,6 +17,8 @@
 #include <asm/realmode.h>
 #include <asm/reboot.h>
 #include <asm/smap.h>
+#include <uapi/asm/mtrr.h>
+#include <asm/debugreg.h>
 #include <linux/export.h>
 #include <../kernel/smpboot.h>
 #include "../../kernel/fpu/legacy.h"
@@ -281,3 +283,99 @@ void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0)
 	kernel_fpu_end();
 }
 EXPORT_SYMBOL(mshv_vtl_return_call);
+
+/* Static table mapping register names to their corresponding actions */
+static const struct {
+	enum hv_register_name reg_name;
+	int debug_reg_num;  /* -1 if not a debug register */
+	u32 msr_addr;       /* 0 if not an MSR */
+} reg_table[] = {
+	/* Debug registers */
+	{HV_X64_REGISTER_DR0, 0, 0},
+	{HV_X64_REGISTER_DR1, 1, 0},
+	{HV_X64_REGISTER_DR2, 2, 0},
+	{HV_X64_REGISTER_DR3, 3, 0},
+	{HV_X64_REGISTER_DR6, 6, 0},
+	/* MTRR MSRs */
+	{HV_X64_REGISTER_MSR_MTRR_CAP, -1, MSR_MTRRcap},
+	{HV_X64_REGISTER_MSR_MTRR_DEF_TYPE, -1, MSR_MTRRdefType},
+	{HV_X64_REGISTER_MSR_MTRR_PHYS_BASE0, -1, MTRRphysBase_MSR(0)},
+	{HV_X64_REGISTER_MSR_MTRR_PHYS_BASE1, -1, MTRRphysBase_MSR(1)},
+	{HV_X64_REGISTER_MSR_MTRR_PHYS_BASE2, -1, MTRRphysBase_MSR(2)},
+	{HV_X64_REGISTER_MSR_MTRR_PHYS_BASE3, -1, MTRRphysBase_MSR(3)},
+	{HV_X64_REGISTER_MSR_MTRR_PHYS_BASE4, -1, MTRRphysBase_MSR(4)},
+	{HV_X64_REGISTER_MSR_MTRR_PHYS_BASE5, -1, MTRRphysBase_MSR(5)},
+	{HV_X64_REGISTER_MSR_MTRR_PHYS_BASE6, -1, MTRRphysBase_MSR(6)},
+	{HV_X64_REGISTER_MSR_MTRR_PHYS_BASE7, -1, MTRRphysBase_MSR(7)},
+	{HV_X64_REGISTER_MSR_MTRR_PHYS_BASE8, -1, MTRRphysBase_MSR(8)},
+	{HV_X64_REGISTER_MSR_MTRR_PHYS_BASE9, -1, MTRRphysBase_MSR(9)},
+	{HV_X64_REGISTER_MSR_MTRR_PHYS_BASEA, -1, MTRRphysBase_MSR(0xa)},
+	{HV_X64_REGISTER_MSR_MTRR_PHYS_BASEB, -1, MTRRphysBase_MSR(0xb)},
+	{HV_X64_REGISTER_MSR_MTRR_PHYS_BASEC, -1, MTRRphysBase_MSR(0xc)},
+	{HV_X64_REGISTER_MSR_MTRR_PHYS_BASED, -1, MTRRphysBase_MSR(0xd)},
+	{HV_X64_REGISTER_MSR_MTRR_PHYS_BASEE, -1, MTRRphysBase_MSR(0xe)},
+	{HV_X64_REGISTER_MSR_MTRR_PHYS_BASEF, -1, MTRRphysBase_MSR(0xf)},
+	{HV_X64_REGISTER_MSR_MTRR_PHYS_MASK0, -1, MTRRphysMask_MSR(0)},
+	{HV_X64_REGISTER_MSR_MTRR_PHYS_MASK1, -1, MTRRphysMask_MSR(1)},
+	{HV_X64_REGISTER_MSR_MTRR_PHYS_MASK2, -1, MTRRphysMask_MSR(2)},
+	{HV_X64_REGISTER_MSR_MTRR_PHYS_MASK3, -1, MTRRphysMask_MSR(3)},
+	{HV_X64_REGISTER_MSR_MTRR_PHYS_MASK4, -1, MTRRphysMask_MSR(4)},
+	{HV_X64_REGISTER_MSR_MTRR_PHYS_MASK5, -1, MTRRphysMask_MSR(5)},
+	{HV_X64_REGISTER_MSR_MTRR_PHYS_MASK6, -1, MTRRphysMask_MSR(6)},
+	{HV_X64_REGISTER_MSR_MTRR_PHYS_MASK7, -1, MTRRphysMask_MSR(7)},
+	{HV_X64_REGISTER_MSR_MTRR_PHYS_MASK8, -1, MTRRphysMask_MSR(8)},
+	{HV_X64_REGISTER_MSR_MTRR_PHYS_MASK9, -1, MTRRphysMask_MSR(9)},
+	{HV_X64_REGISTER_MSR_MTRR_PHYS_MASKA, -1, MTRRphysMask_MSR(0xa)},
+	{HV_X64_REGISTER_MSR_MTRR_PHYS_MASKB, -1, MTRRphysMask_MSR(0xb)},
+	{HV_X64_REGISTER_MSR_MTRR_PHYS_MASKC, -1, MTRRphysMask_MSR(0xc)},
+	{HV_X64_REGISTER_MSR_MTRR_PHYS_MASKD, -1, MTRRphysMask_MSR(0xd)},
+	{HV_X64_REGISTER_MSR_MTRR_PHYS_MASKE, -1, MTRRphysMask_MSR(0xe)},
+	{HV_X64_REGISTER_MSR_MTRR_PHYS_MASKF, -1, MTRRphysMask_MSR(0xf)},
+	{HV_X64_REGISTER_MSR_MTRR_FIX64K00000, -1, MSR_MTRRfix64K_00000},
+	{HV_X64_REGISTER_MSR_MTRR_FIX16K80000, -1, MSR_MTRRfix16K_80000},
+	{HV_X64_REGISTER_MSR_MTRR_FIX16KA0000, -1, MSR_MTRRfix16K_A0000},
+	{HV_X64_REGISTER_MSR_MTRR_FIX4KC0000, -1, MSR_MTRRfix4K_C0000},
+	{HV_X64_REGISTER_MSR_MTRR_FIX4KC8000, -1, MSR_MTRRfix4K_C8000},
+	{HV_X64_REGISTER_MSR_MTRR_FIX4KD0000, -1, MSR_MTRRfix4K_D0000},
+	{HV_X64_REGISTER_MSR_MTRR_FIX4KD8000, -1, MSR_MTRRfix4K_D8000},
+	{HV_X64_REGISTER_MSR_MTRR_FIX4KE0000, -1, MSR_MTRRfix4K_E0000},
+	{HV_X64_REGISTER_MSR_MTRR_FIX4KE8000, -1, MSR_MTRRfix4K_E8000},
+	{HV_X64_REGISTER_MSR_MTRR_FIX4KF0000, -1, MSR_MTRRfix4K_F0000},
+	{HV_X64_REGISTER_MSR_MTRR_FIX4KF8000, -1, MSR_MTRRfix4K_F8000},
+};
+
+int hv_vtl_get_set_reg(struct hv_register_assoc *regs, bool set, bool shared)
+{
+	u64 *reg64;
+	enum hv_register_name gpr_name;
+	int i;
+
+	gpr_name = regs->name;
+	reg64 = &regs->value.reg64;
+
+	/* Search for the register in the table */
+	for (i = 0; i < ARRAY_SIZE(reg_table); i++) {
+		if (reg_table[i].reg_name != gpr_name)
+			continue;
+		if (reg_table[i].debug_reg_num != -1) {
+			/* Handle debug registers */
+			if (gpr_name == HV_X64_REGISTER_DR6 && !shared)
+				goto hypercall;
+			if (set)
+				native_set_debugreg(reg_table[i].debug_reg_num, *reg64);
+			else
+				*reg64 = native_get_debugreg(reg_table[i].debug_reg_num);
+		} else {
+			/* Handle MSRs */
+			if (set)
+				wrmsrl(reg_table[i].msr_addr, *reg64);
+			else
+				rdmsrl(reg_table[i].msr_addr, *reg64);
+		}
+		return 0;
+	}
+
+hypercall:
+	return 1;
+}
+EXPORT_SYMBOL(hv_vtl_get_set_reg);
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index 95b452387969..08278547b84c 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -290,6 +290,7 @@ void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0);
 void mshv_vtl_return_call_init(u64 vtl_return_offset);
 void mshv_vtl_return_hypercall(void);
 void __mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0);
+int hv_vtl_get_set_reg(struct hv_register_assoc *regs, bool set, bool shared);
 #else
 static inline void __init hv_vtl_init_platform(void) {}
 static inline int __init hv_vtl_early_init(void) { return 0; }
diff --git a/drivers/hv/mshv_vtl_main.c b/drivers/hv/mshv_vtl_main.c
index 5856975f32e1..b607b6e7e121 100644
--- a/drivers/hv/mshv_vtl_main.c
+++ b/drivers/hv/mshv_vtl_main.c
@@ -19,10 +19,8 @@
 #include <linux/poll.h>
 #include <linux/file.h>
 #include <linux/vmalloc.h>
-#include <asm/debugreg.h>
 #include <asm/mshyperv.h>
 #include <trace/events/ipi.h>
-#include <uapi/asm/mtrr.h>
 #include <uapi/linux/mshv.h>
 #include <hyperv/hvhdk.h>
 
@@ -505,102 +503,6 @@ static int mshv_vtl_ioctl_set_poll_file(struct mshv_vtl_set_poll_file __user *us
 	return 0;
 }
 
-/* Static table mapping register names to their corresponding actions */
-static const struct {
-	enum hv_register_name reg_name;
-	int debug_reg_num;  /* -1 if not a debug register */
-	u32 msr_addr;       /* 0 if not an MSR */
-} reg_table[] = {
-	/* Debug registers */
-	{HV_X64_REGISTER_DR0, 0, 0},
-	{HV_X64_REGISTER_DR1, 1, 0},
-	{HV_X64_REGISTER_DR2, 2, 0},
-	{HV_X64_REGISTER_DR3, 3, 0},
-	{HV_X64_REGISTER_DR6, 6, 0},
-	/* MTRR MSRs */
-	{HV_X64_REGISTER_MSR_MTRR_CAP, -1, MSR_MTRRcap},
-	{HV_X64_REGISTER_MSR_MTRR_DEF_TYPE, -1, MSR_MTRRdefType},
-	{HV_X64_REGISTER_MSR_MTRR_PHYS_BASE0, -1, MTRRphysBase_MSR(0)},
-	{HV_X64_REGISTER_MSR_MTRR_PHYS_BASE1, -1, MTRRphysBase_MSR(1)},
-	{HV_X64_REGISTER_MSR_MTRR_PHYS_BASE2, -1, MTRRphysBase_MSR(2)},
-	{HV_X64_REGISTER_MSR_MTRR_PHYS_BASE3, -1, MTRRphysBase_MSR(3)},
-	{HV_X64_REGISTER_MSR_MTRR_PHYS_BASE4, -1, MTRRphysBase_MSR(4)},
-	{HV_X64_REGISTER_MSR_MTRR_PHYS_BASE5, -1, MTRRphysBase_MSR(5)},
-	{HV_X64_REGISTER_MSR_MTRR_PHYS_BASE6, -1, MTRRphysBase_MSR(6)},
-	{HV_X64_REGISTER_MSR_MTRR_PHYS_BASE7, -1, MTRRphysBase_MSR(7)},
-	{HV_X64_REGISTER_MSR_MTRR_PHYS_BASE8, -1, MTRRphysBase_MSR(8)},
-	{HV_X64_REGISTER_MSR_MTRR_PHYS_BASE9, -1, MTRRphysBase_MSR(9)},
-	{HV_X64_REGISTER_MSR_MTRR_PHYS_BASEA, -1, MTRRphysBase_MSR(0xa)},
-	{HV_X64_REGISTER_MSR_MTRR_PHYS_BASEB, -1, MTRRphysBase_MSR(0xb)},
-	{HV_X64_REGISTER_MSR_MTRR_PHYS_BASEC, -1, MTRRphysBase_MSR(0xc)},
-	{HV_X64_REGISTER_MSR_MTRR_PHYS_BASED, -1, MTRRphysBase_MSR(0xd)},
-	{HV_X64_REGISTER_MSR_MTRR_PHYS_BASEE, -1, MTRRphysBase_MSR(0xe)},
-	{HV_X64_REGISTER_MSR_MTRR_PHYS_BASEF, -1, MTRRphysBase_MSR(0xf)},
-	{HV_X64_REGISTER_MSR_MTRR_PHYS_MASK0, -1, MTRRphysMask_MSR(0)},
-	{HV_X64_REGISTER_MSR_MTRR_PHYS_MASK1, -1, MTRRphysMask_MSR(1)},
-	{HV_X64_REGISTER_MSR_MTRR_PHYS_MASK2, -1, MTRRphysMask_MSR(2)},
-	{HV_X64_REGISTER_MSR_MTRR_PHYS_MASK3, -1, MTRRphysMask_MSR(3)},
-	{HV_X64_REGISTER_MSR_MTRR_PHYS_MASK4, -1, MTRRphysMask_MSR(4)},
-	{HV_X64_REGISTER_MSR_MTRR_PHYS_MASK5, -1, MTRRphysMask_MSR(5)},
-	{HV_X64_REGISTER_MSR_MTRR_PHYS_MASK6, -1, MTRRphysMask_MSR(6)},
-	{HV_X64_REGISTER_MSR_MTRR_PHYS_MASK7, -1, MTRRphysMask_MSR(7)},
-	{HV_X64_REGISTER_MSR_MTRR_PHYS_MASK8, -1, MTRRphysMask_MSR(8)},
-	{HV_X64_REGISTER_MSR_MTRR_PHYS_MASK9, -1, MTRRphysMask_MSR(9)},
-	{HV_X64_REGISTER_MSR_MTRR_PHYS_MASKA, -1, MTRRphysMask_MSR(0xa)},
-	{HV_X64_REGISTER_MSR_MTRR_PHYS_MASKB, -1, MTRRphysMask_MSR(0xb)},
-	{HV_X64_REGISTER_MSR_MTRR_PHYS_MASKC, -1, MTRRphysMask_MSR(0xc)},
-	{HV_X64_REGISTER_MSR_MTRR_PHYS_MASKD, -1, MTRRphysMask_MSR(0xd)},
-	{HV_X64_REGISTER_MSR_MTRR_PHYS_MASKE, -1, MTRRphysMask_MSR(0xe)},
-	{HV_X64_REGISTER_MSR_MTRR_PHYS_MASKF, -1, MTRRphysMask_MSR(0xf)},
-	{HV_X64_REGISTER_MSR_MTRR_FIX64K00000, -1, MSR_MTRRfix64K_00000},
-	{HV_X64_REGISTER_MSR_MTRR_FIX16K80000, -1, MSR_MTRRfix16K_80000},
-	{HV_X64_REGISTER_MSR_MTRR_FIX16KA0000, -1, MSR_MTRRfix16K_A0000},
-	{HV_X64_REGISTER_MSR_MTRR_FIX4KC0000, -1, MSR_MTRRfix4K_C0000},
-	{HV_X64_REGISTER_MSR_MTRR_FIX4KC8000, -1, MSR_MTRRfix4K_C8000},
-	{HV_X64_REGISTER_MSR_MTRR_FIX4KD0000, -1, MSR_MTRRfix4K_D0000},
-	{HV_X64_REGISTER_MSR_MTRR_FIX4KD8000, -1, MSR_MTRRfix4K_D8000},
-	{HV_X64_REGISTER_MSR_MTRR_FIX4KE0000, -1, MSR_MTRRfix4K_E0000},
-	{HV_X64_REGISTER_MSR_MTRR_FIX4KE8000, -1, MSR_MTRRfix4K_E8000},
-	{HV_X64_REGISTER_MSR_MTRR_FIX4KF0000, -1, MSR_MTRRfix4K_F0000},
-	{HV_X64_REGISTER_MSR_MTRR_FIX4KF8000, -1, MSR_MTRRfix4K_F8000},
-};
-
-static int mshv_vtl_get_set_reg(struct hv_register_assoc *regs, bool set)
-{
-	u64 *reg64;
-	enum hv_register_name gpr_name;
-	int i;
-
-	gpr_name = regs->name;
-	reg64 = &regs->value.reg64;
-
-	/* Search for the register in the table */
-	for (i = 0; i < ARRAY_SIZE(reg_table); i++) {
-		if (reg_table[i].reg_name != gpr_name)
-			continue;
-		if (reg_table[i].debug_reg_num != -1) {
-			/* Handle debug registers */
-			if (gpr_name == HV_X64_REGISTER_DR6 &&
-			    !mshv_vsm_capabilities.dr6_shared)
-				goto hypercall;
-			if (set)
-				native_set_debugreg(reg_table[i].debug_reg_num, *reg64);
-			else
-				*reg64 = native_get_debugreg(reg_table[i].debug_reg_num);
-		} else {
-			/* Handle MSRs */
-			if (set)
-				wrmsrl(reg_table[i].msr_addr, *reg64);
-			else
-				rdmsrl(reg_table[i].msr_addr, *reg64);
-		}
-		return 0;
-	}
-
-hypercall:
-	return 1;
-}
-
 static void mshv_vtl_return(struct mshv_vtl_cpu_context *vtl0)
 {
 	struct hv_vp_assist_page *hvp;
@@ -720,7 +622,7 @@ mshv_vtl_ioctl_get_regs(void __user *user_args)
 			   sizeof(reg)))
 		return -EFAULT;
 
-	ret = mshv_vtl_get_set_reg(&reg, false);
+	ret = hv_vtl_get_set_reg(&reg, false, mshv_vsm_capabilities.dr6_shared);
 	if (!ret)
 		goto copy_args; /* No need of hypercall */
 	ret = vtl_get_vp_register(&reg);
@@ -751,7 +653,7 @@ mshv_vtl_ioctl_set_regs(void __user *user_args)
 	if (copy_from_user(&reg, (void __user *)args.regs_ptr, sizeof(reg)))
 		return -EFAULT;
 
-	ret = mshv_vtl_get_set_reg(&reg, true);
+	ret = hv_vtl_get_set_reg(&reg, true, mshv_vsm_capabilities.dr6_shared);
 	if (!ret)
 		return ret; /* No need of hypercall */
 	ret = vtl_set_vp_register(&reg);
-- 
2.43.0


From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 6E42B3EE1D1;
	Thu, 23 Apr 2026 12:43:02 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=13.77.154.182
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1776948183; cv=none; b=jv6PhpB3MJzF4UTzeSu55W71JSFrf0Kt6TPLpYxu/5rGFNKl6l2MPKWKidmrQFG9WGW6nWOeh4aaTnuEOd0vwEhH+iq81+OE4uRLcXb8xrR0Frp8DG2mGOsG1l6beYvTRR5no2XuMABgDByhG+QLiFcyOmZ5AKRjeuKoFLSVuN0=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1776948183; c=relaxed/simple;
	bh=+l8Kq2o53RDg3DGJBvOnLAcSd/SPa7vsSu5k0MKfoRY=;
	h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
	 MIME-Version; b=QzEdensCq1PM/YXn81HtQ6N2QsRnrOZu84r2SV8qXWtmAYFgMWWn91R7RNrHjbr9+wUmE+cAItKCyqxkO1tQA81+wGTIQ1aSkTavhd4YZH2ovgkJZaQ59mMkeNqzMPWm+n8uZdA0wJltA1fnr1j0e/ew53k4j63cmg4U4oHpk8A=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com; spf=pass smtp.mailfrom=linux.microsoft.com; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b=kdfK+cNK; arc=none smtp.client-ip=13.77.154.182
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="kdfK+cNK"
Received: from CPC-namja-026ON.redmond.corp.microsoft.com (unknown [4.213.232.18])
	by linux.microsoft.com (Postfix) with ESMTPSA id 527D720B7167;
	Thu, 23 Apr 2026 05:42:55 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 527D720B7167
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1776948182;
	bh=Q76kHi3aTcSg7O4rk2jstLQj95vNaQvrKNEZQjnBiXc=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=kdfK+cNKF7P5mLQrePhjWhMrUP6eSRlh5W0NUH46xhS7kvsAEkw46O2Mmpt2oiuMV
	 n1LTlHyLATBHcLD8VCm0Uj+Zz7RtO6UoWzJE2KKhGGK9Glv8QnC79mPIAFsRfq+uui
	 9Myf/BY8wGV9TnMow/+qSmn15wPrRIPwpGhE10oA=
From: Naman Jain <namjain@linux.microsoft.com>
To: "K . Y . Srinivasan" <kys@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	Wei Liu <wei.liu@kernel.org>,
	Dexuan Cui <decui@microsoft.com>,
	Long Li <longli@microsoft.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Thomas Gleixner <tglx@kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org,
	"H . Peter Anvin" <hpa@zytor.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Paul Walmsley <pjw@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Alexandre Ghiti <alex@ghiti.fr>,
	Michael Kelley <mhklinux@outlook.com>
Cc: Marc Zyngier <maz@kernel.org>,
	Timothy Hayes <timothy.hayes@arm.com>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Sascha Bischoff <sascha.bischoff@arm.com>,
	mrigendrachaubey <mrigendra.chaubey@gmail.com>,
	Naman Jain <namjain@linux.microsoft.com>,
	linux-hyperv@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	linux-arch@vger.kernel.org,
	linux-riscv@lists.infradead.org,
	vdso@mailbox.org,
	ssengar@linux.microsoft.com
Subject: [PATCH v2 05/15] Drivers: hv: Export vmbus_interrupt for mshv_vtl module
Date: Thu, 23 Apr 2026 12:41:55 +0000
Message-ID: <20260423124206.2410879-6-namjain@linux.microsoft.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260423124206.2410879-1-namjain@linux.microsoft.com>
References: <20260423124206.2410879-1-namjain@linux.microsoft.com>
Precedence: bulk
X-Mailing-List: linux-arch@vger.kernel.org
List-Id: <linux-arch.vger.kernel.org>
List-Subscribe: <mailto:linux-arch+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-arch+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

vmbus_interrupt is used in mshv_vtl_main.c to set the SINT vector.
When CONFIG_MSHV_VTL=m and CONFIG_HYPERV_VMBUS=y (built-in), the module
cannot access vmbus_interrupt at load time since it is not exported.

Export it using EXPORT_SYMBOL_FOR_MODULES consistent with the existing
pattern used for vmbus_isr.

Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Reviewed-by: Roman Kisel <vdso@mailbox.org>
Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
---
 drivers/hv/vmbus_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 052ca8b11cee..047ad2848782 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -57,6 +57,7 @@ static DEFINE_PER_CPU(long, vmbus_evt);
 /* Values parsed from ACPI DSDT */
 int vmbus_irq;
 int vmbus_interrupt;
+EXPORT_SYMBOL_FOR_MODULES(vmbus_interrupt, "mshv_vtl");
 
 /*
  * If the Confidential VMBus is used, the data on the "wire" is not
-- 
2.43.0


From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 265E53537D0;
	Thu, 23 Apr 2026 12:43:12 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=13.77.154.182
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1776948193; cv=none; b=aOg/PjqwoEMYv7Zl21NHOZTyhk8vAFdQcBIpx4iCk7etr+yJ6WVh6H5uf4e8jAIySInEqnBWD5Vfte4dIlKI6eKMV0RaPrgRxTVJx0tGz/FQAvNU8vExH+4zSwwyFqZPH69ujJk8+Nv9JpHwJEFNEImrsctYbQ+uz7Ffd++7+sA=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1776948193; c=relaxed/simple;
	bh=vPUV+9IKyChIXzMqTscljhgydmQTFZc3z74+Dvtr0hw=;
	h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
	 MIME-Version; b=bUxMSJgh/FZvDa4ake8wG43Gpd9Iyi1ciNYinLKEfNKMRzvHRXJ8WZJOI2EqLTPyytZ2/+jcwg0DJmSuMXAZs0XM5ir3Qa/5Rpyib8HZ/oSdvbISHzRmgwbd1yl1yQSwTK8tgER6iskRAmOLNLhHp2EU1BhOfEjM+Pb/SDlEfzA=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com; spf=pass smtp.mailfrom=linux.microsoft.com; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b=Q+rLxbyv; arc=none smtp.client-ip=13.77.154.182
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="Q+rLxbyv"
Received: from CPC-namja-026ON.redmond.corp.microsoft.com (unknown [4.213.232.18])
	by linux.microsoft.com (Postfix) with ESMTPSA id 4315E20B716A;
	Thu, 23 Apr 2026 05:43:03 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 4315E20B716A
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1776948190;
	bh=xYrsyIoC51W4Qe8bosyyU9xMtVV38HlYUTBKJNuSgig=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=Q+rLxbyvnffxyuNo7mQNSV1jDnHtH+MsGn2tqlrxeqczaIVyO9o9XxHTxfZYPivTj
	 IlWMlNYJBS65wirhfC6MYZYo470rxfD5FcIRjgLk/a3YENQESPYAlJHYYI/zpIJ0qL
	 YIZqDaeCfud83sBftDNVa/ckgxRBUqNnkc8Qs3/U=
From: Naman Jain <namjain@linux.microsoft.com>
To: "K . Y . Srinivasan" <kys@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	Wei Liu <wei.liu@kernel.org>,
	Dexuan Cui <decui@microsoft.com>,
	Long Li <longli@microsoft.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Thomas Gleixner <tglx@kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org,
	"H . Peter Anvin" <hpa@zytor.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Paul Walmsley <pjw@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Alexandre Ghiti <alex@ghiti.fr>,
	Michael Kelley <mhklinux@outlook.com>
Cc: Marc Zyngier <maz@kernel.org>,
	Timothy Hayes <timothy.hayes@arm.com>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Sascha Bischoff <sascha.bischoff@arm.com>,
	mrigendrachaubey <mrigendra.chaubey@gmail.com>,
	Naman Jain <namjain@linux.microsoft.com>,
	linux-hyperv@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	linux-arch@vger.kernel.org,
	linux-riscv@lists.infradead.org,
	vdso@mailbox.org,
	ssengar@linux.microsoft.com
Subject: [PATCH v2 06/15] mshv_vtl: Make sint vector architecture neutral
Date: Thu, 23 Apr 2026 12:41:56 +0000
Message-ID: <20260423124206.2410879-7-namjain@linux.microsoft.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260423124206.2410879-1-namjain@linux.microsoft.com>
References: <20260423124206.2410879-1-namjain@linux.microsoft.com>
Precedence: bulk
X-Mailing-List: linux-arch@vger.kernel.org
List-Id: <linux-arch.vger.kernel.org>
List-Subscribe: <mailto:linux-arch+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-arch+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Generalize Synthetic interrupt source vector (sint) to use
vmbus_interrupt variable instead, which automatically takes care of
architectures where HYPERVISOR_CALLBACK_VECTOR is not present (arm64).

Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Reviewed-by: Roman Kisel <vdso@mailbox.org>
Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
---
 drivers/hv/mshv_vtl_main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/hv/mshv_vtl_main.c b/drivers/hv/mshv_vtl_main.c
index b607b6e7e121..91517b45d526 100644
--- a/drivers/hv/mshv_vtl_main.c
+++ b/drivers/hv/mshv_vtl_main.c
@@ -234,7 +234,7 @@ static void mshv_vtl_synic_enable_regs(unsigned int cpu)
 	union hv_synic_sint sint;
 
 	sint.as_uint64 = 0;
-	sint.vector = HYPERVISOR_CALLBACK_VECTOR;
+	sint.vector = vmbus_interrupt;
 	sint.masked = false;
 	sint.auto_eoi = hv_recommend_using_aeoi();
 
@@ -753,7 +753,7 @@ static void mshv_vtl_synic_mask_vmbus_sint(void *info)
 	const u8 *mask = info;
 
 	sint.as_uint64 = 0;
-	sint.vector = HYPERVISOR_CALLBACK_VECTOR;
+	sint.vector = vmbus_interrupt;
 	sint.masked = (*mask != 0);
 	sint.auto_eoi = hv_recommend_using_aeoi();
 
-- 
2.43.0


From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 939B21D6DB5;
	Thu, 23 Apr 2026 12:43:20 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=13.77.154.182
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1776948202; cv=none; b=VTHTth1G5Vl1xZUJGlqTF+Vyh1LuVs8biUOwWcnpBZfo9UmKI/Vb9COUIazINiBcG+blDxzq1tW6ApsLH3jaun5B0z4WdjpnsenBrqmtxtr3gnXkH6vd0ZBoOlT5s1sG7MtxsIM5tMZN/96bTJMTeBqnrx/9KXqJEn22IWbidas=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1776948202; c=relaxed/simple;
	bh=eAdPjGUyJz01icU8R0rlCiMxidI+ThwnPQ3HGdEb5xA=;
	h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
	 MIME-Version; b=gQgzP723zxoHe5ogBSafpUMlejzZwqaIiMdCWDoWRNo5Ab7lEStHOxs6uQo6LE1BSeOMtCU4wWN8gGOf0OdxNZNghLIhXUTpBeWqVELrJpuSynjwF95klGIRVj+FJ7W1CdDs4VPJA8+gXoytQs3nKV1eIrXqA4pvL8VFJ/pfsR4=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com; spf=pass smtp.mailfrom=linux.microsoft.com; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b=f47tU/Hz; arc=none smtp.client-ip=13.77.154.182
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="f47tU/Hz"
Received: from CPC-namja-026ON.redmond.corp.microsoft.com (unknown [4.213.232.18])
	by linux.microsoft.com (Postfix) with ESMTPSA id D497220B7168;
	Thu, 23 Apr 2026 05:43:12 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com D497220B7168
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1776948200;
	bh=aVyNCeXYZ0oAOSkaW+ZPREQaMs9A0VJFYF7viH8T5Q0=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=f47tU/Hz8pUgeCWHR4nk3hAOYdY/CrdV6Wxs13qz7+o6zxJeVLErfv+FKEjgxS16J
	 7DaIBAtMEJ8BnFAzdnI/eEGQ9EFe1MRZxVxWyzN6cVW47hJjMKBgbS7SRviMNvKNnD
	 ZTMw3hZZRAFeSuwFnSEbvdvjcAdvmR69NYxEltQg=
From: Naman Jain <namjain@linux.microsoft.com>
To: "K . Y . Srinivasan" <kys@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	Wei Liu <wei.liu@kernel.org>,
	Dexuan Cui <decui@microsoft.com>,
	Long Li <longli@microsoft.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Thomas Gleixner <tglx@kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org,
	"H . Peter Anvin" <hpa@zytor.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Paul Walmsley <pjw@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Alexandre Ghiti <alex@ghiti.fr>,
	Michael Kelley <mhklinux@outlook.com>
Cc: Marc Zyngier <maz@kernel.org>,
	Timothy Hayes <timothy.hayes@arm.com>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Sascha Bischoff <sascha.bischoff@arm.com>,
	mrigendrachaubey <mrigendra.chaubey@gmail.com>,
	Naman Jain <namjain@linux.microsoft.com>,
	linux-hyperv@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	linux-arch@vger.kernel.org,
	linux-riscv@lists.infradead.org,
	vdso@mailbox.org,
	ssengar@linux.microsoft.com
Subject: [PATCH v2 07/15] arm64: hyperv: Add support for mshv_vtl_return_call
Date: Thu, 23 Apr 2026 12:41:57 +0000
Message-ID: <20260423124206.2410879-8-namjain@linux.microsoft.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260423124206.2410879-1-namjain@linux.microsoft.com>
References: <20260423124206.2410879-1-namjain@linux.microsoft.com>
Precedence: bulk
X-Mailing-List: linux-arch@vger.kernel.org
List-Id: <linux-arch.vger.kernel.org>
List-Subscribe: <mailto:linux-arch+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-arch+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Add the arm64 variant of mshv_vtl_return_call() to support the MSHV_VTL
driver on arm64. This function enables the transition between Virtual
Trust Levels (VTLs) in MSHV_VTL when the kernel acts as a paravisor.

Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
Reviewed-by: Roman Kisel <vdso@mailbox.org>
Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
---
 arch/arm64/hyperv/Makefile        |   1 +
 arch/arm64/hyperv/hv_vtl.c        | 158 ++++++++++++++++++++++++++++++
 arch/arm64/include/asm/mshyperv.h |  13 +++
 arch/x86/include/asm/mshyperv.h   |   2 -
 drivers/hv/mshv_vtl.h             |   3 +
 include/asm-generic/mshyperv.h    |   2 +
 6 files changed, 177 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm64/hyperv/hv_vtl.c

diff --git a/arch/arm64/hyperv/Makefile b/arch/arm64/hyperv/Makefile
index 87c31c001da9..9701a837a6e1 100644
--- a/arch/arm64/hyperv/Makefile
+++ b/arch/arm64/hyperv/Makefile
@@ -1,2 +1,3 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-y		:= hv_core.o mshyperv.o
+obj-$(CONFIG_HYPERV_VTL_MODE)	+= hv_vtl.o
diff --git a/arch/arm64/hyperv/hv_vtl.c b/arch/arm64/hyperv/hv_vtl.c
new file mode 100644
index 000000000000..59cbeb74e7b9
--- /dev/null
+++ b/arch/arm64/hyperv/hv_vtl.c
@@ -0,0 +1,158 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2026, Microsoft, Inc.
+ *
+ * Authors:
+ *     Roman Kisel <romank@linux.microsoft.com>
+ *     Naman Jain <namjain@linux.microsoft.com>
+ */
+
+#include <asm/mshyperv.h>
+#include <asm/neon.h>
+#include <linux/export.h>
+
+void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0)
+{
+	struct user_fpsimd_state fpsimd_state;
+	u64 base_ptr = (u64)vtl0->x;
+
+	/*
+	 * Obtain the CPU FPSIMD registers for VTL context switch.
+	 * This saves the current task's FP/NEON state and allows us to
+	 * safely load VTL0's FP/NEON context for the hypercall.
+	 */
+	kernel_neon_begin(&fpsimd_state);
+
+	/*
+	 * VTL switch for ARM64 platform - managing VTL0's CPU context.
+	 * We explicitly use the stack to save the base pointer, and use x16
+	 * as our working register for accessing the context structure.
+	 *
+	 * Register Handling:
+	 * - X0-X17: Saved/restored (general-purpose, shared for VTL communication)
+	 * - X18: NOT touched - hypervisor-managed per-VTL (platform register)
+	 * - X19-X30: Saved/restored (part of VTL0's execution context)
+	 * - Q0-Q31: Saved/restored (128-bit NEON/floating-point registers, shared)
+	 * - SP: Not in structure, hypervisor-managed per-VTL
+	 *
+	 * X29 (FP) and X30 (LR) are in the structure and must be saved/restored
+	 * as part of VTL0's complete execution state.
+	 */
+	asm __volatile__ (
+		/* Save base pointer to stack explicitly, then load into x16 */
+		"str %0, [sp, #-16]!\n\t"     /* Push base pointer onto stack */
+		"mov x16, %0\n\t"             /* Load base pointer into x16 */
+		/* Volatile registers (Windows ARM64 ABI: x0-x17) */
+		"ldp x0, x1, [x16]\n\t"
+		"ldp x2, x3, [x16, #(2*8)]\n\t"
+		"ldp x4, x5, [x16, #(4*8)]\n\t"
+		"ldp x6, x7, [x16, #(6*8)]\n\t"
+		"ldp x8, x9, [x16, #(8*8)]\n\t"
+		"ldp x10, x11, [x16, #(10*8)]\n\t"
+		"ldp x12, x13, [x16, #(12*8)]\n\t"
+		"ldp x14, x15, [x16, #(14*8)]\n\t"
+		/* x16 will be loaded last, after saving base pointer */
+		"ldr x17, [x16, #(17*8)]\n\t"
+		/* x18 is hypervisor-managed per-VTL - DO NOT LOAD */
+
+		/* General-purpose registers: x19-x30 */
+		"ldp x19, x20, [x16, #(19*8)]\n\t"
+		"ldp x21, x22, [x16, #(21*8)]\n\t"
+		"ldp x23, x24, [x16, #(23*8)]\n\t"
+		"ldp x25, x26, [x16, #(25*8)]\n\t"
+		"ldp x27, x28, [x16, #(27*8)]\n\t"
+
+		/* Frame pointer and link register */
+		"ldp x29, x30, [x16, #(29*8)]\n\t"
+
+		/* Shared NEON/FP registers: Q0-Q31 (128-bit) */
+		"ldp q0, q1, [x16, #(32*8)]\n\t"
+		"ldp q2, q3, [x16, #(32*8 + 2*16)]\n\t"
+		"ldp q4, q5, [x16, #(32*8 + 4*16)]\n\t"
+		"ldp q6, q7, [x16, #(32*8 + 6*16)]\n\t"
+		"ldp q8, q9, [x16, #(32*8 + 8*16)]\n\t"
+		"ldp q10, q11, [x16, #(32*8 + 10*16)]\n\t"
+		"ldp q12, q13, [x16, #(32*8 + 12*16)]\n\t"
+		"ldp q14, q15, [x16, #(32*8 + 14*16)]\n\t"
+		"ldp q16, q17, [x16, #(32*8 + 16*16)]\n\t"
+		"ldp q18, q19, [x16, #(32*8 + 18*16)]\n\t"
+		"ldp q20, q21, [x16, #(32*8 + 20*16)]\n\t"
+		"ldp q22, q23, [x16, #(32*8 + 22*16)]\n\t"
+		"ldp q24, q25, [x16, #(32*8 + 24*16)]\n\t"
+		"ldp q26, q27, [x16, #(32*8 + 26*16)]\n\t"
+		"ldp q28, q29, [x16, #(32*8 + 28*16)]\n\t"
+		"ldp q30, q31, [x16, #(32*8 + 30*16)]\n\t"
+
+		/* Now load x16 itself */
+		"ldr x16, [x16, #(16*8)]\n\t"
+
+		/* Return to the lower VTL */
+		"hvc #3\n\t"
+
+		/* Save context after return - reload base pointer from stack */
+		"stp x16, x17, [sp, #-16]!\n\t" /* Save x16, x17 temporarily */
+		"ldr x16, [sp, #16]\n\t"        /* Reload base pointer (skip saved x16,x17) */
+
+		/* Volatile registers */
+		"stp x0, x1, [x16]\n\t"
+		"stp x2, x3, [x16, #(2*8)]\n\t"
+		"stp x4, x5, [x16, #(4*8)]\n\t"
+		"stp x6, x7, [x16, #(6*8)]\n\t"
+		"stp x8, x9, [x16, #(8*8)]\n\t"
+		"stp x10, x11, [x16, #(10*8)]\n\t"
+		"stp x12, x13, [x16, #(12*8)]\n\t"
+		"stp x14, x15, [x16, #(14*8)]\n\t"
+		"ldp x0, x1, [sp], #16\n\t"      /* Recover saved x16, x17 */
+		"stp x0, x1, [x16, #(16*8)]\n\t"
+		/* x18 is hypervisor-managed - DO NOT SAVE */
+
+		/* General-purpose registers: x19-x30 */
+		"stp x19, x20, [x16, #(19*8)]\n\t"
+		"stp x21, x22, [x16, #(21*8)]\n\t"
+		"stp x23, x24, [x16, #(23*8)]\n\t"
+		"stp x25, x26, [x16, #(25*8)]\n\t"
+		"stp x27, x28, [x16, #(27*8)]\n\t"
+		"stp x29, x30, [x16, #(29*8)]\n\t"  /* Frame pointer and link register */
+
+		/* Shared NEON/FP registers: Q0-Q31 (128-bit) */
+		"stp q0, q1, [x16, #(32*8)]\n\t"
+		"stp q2, q3, [x16, #(32*8 + 2*16)]\n\t"
+		"stp q4, q5, [x16, #(32*8 + 4*16)]\n\t"
+		"stp q6, q7, [x16, #(32*8 + 6*16)]\n\t"
+		"stp q8, q9, [x16, #(32*8 + 8*16)]\n\t"
+		"stp q10, q11, [x16, #(32*8 + 10*16)]\n\t"
+		"stp q12, q13, [x16, #(32*8 + 12*16)]\n\t"
+		"stp q14, q15, [x16, #(32*8 + 14*16)]\n\t"
+		"stp q16, q17, [x16, #(32*8 + 16*16)]\n\t"
+		"stp q18, q19, [x16, #(32*8 + 18*16)]\n\t"
+		"stp q20, q21, [x16, #(32*8 + 20*16)]\n\t"
+		"stp q22, q23, [x16, #(32*8 + 22*16)]\n\t"
+		"stp q24, q25, [x16, #(32*8 + 24*16)]\n\t"
+		"stp q26, q27, [x16, #(32*8 + 26*16)]\n\t"
+		"stp q28, q29, [x16, #(32*8 + 28*16)]\n\t"
+		"stp q30, q31, [x16, #(32*8 + 30*16)]\n\t"
+
+		/* Clean up stack - pop base pointer */
+		"add sp, sp, #16\n\t"
+
+		: /* No outputs */
+		: /* Input */ "r"(base_ptr)
+		: /* Clobber list - x16 used as base, x18 is hypervisor-managed (not touched) */
+		"memory", "cc",
+		"x0", "x1", "x2", "x3", "x4", "x5",
+		"x6", "x7", "x8", "x9", "x10", "x11", "x12", "x13",
+		"x14", "x15", "x16", "x17", "x19", "x20", "x21",
+		"x22", "x23", "x24", "x25", "x26", "x27", "x28",
+		"x29", "x30",
+		"v0", "v1", "v2", "v3", "v4", "v5", "v6", "v7",
+		"v8", "v9", "v10", "v11", "v12", "v13", "v14", "v15",
+		"v16", "v17", "v18", "v19", "v20", "v21", "v22", "v23",
+		"v24", "v25", "v26", "v27", "v28", "v29", "v30", "v31");
+
+	/*
+	 * Restore the task's FP/SIMD state and return CPU FPSIMD registers
+	 * back to normal kernel use.
+	 */
+	kernel_neon_end(&fpsimd_state);
+}
+EXPORT_SYMBOL(mshv_vtl_return_call);
diff --git a/arch/arm64/include/asm/mshyperv.h b/arch/arm64/include/asm/mshyperv.h
index 585b23a26f1b..9eb0e5999f29 100644
--- a/arch/arm64/include/asm/mshyperv.h
+++ b/arch/arm64/include/asm/mshyperv.h
@@ -60,6 +60,18 @@ static inline u64 hv_get_non_nested_msr(unsigned int reg)
 				ARM_SMCCC_SMC_64,		\
 				ARM_SMCCC_OWNER_VENDOR_HYP,	\
 				HV_SMCCC_FUNC_NUMBER)
+
+struct mshv_vtl_cpu_context {
+/*
+ * x18 is managed by the hypervisor. It won't be reloaded from this array.
+ * It is included here for convenience in array indexing.
+ * 'rsvd' field serves as alignment padding so q[] starts at offset 32*8=256.
+ */
+	__u64 x[31];
+	__u64 rsvd;
+	__uint128_t q[32];
+};
+
 #ifdef CONFIG_HYPERV_VTL_MODE
 /*
  * Get/Set the register. If the function returns `1`, that must be done via
@@ -69,6 +81,7 @@ static inline int hv_vtl_get_set_reg(struct hv_register_assoc *regs, bool set, b
 {
 	return 1;
 }
+
 #endif
 
 #include <asm-generic/mshyperv.h>
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index 08278547b84c..b4d80c9a673a 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -286,7 +286,6 @@ struct mshv_vtl_cpu_context {
 #ifdef CONFIG_HYPERV_VTL_MODE
 void __init hv_vtl_init_platform(void);
 int __init hv_vtl_early_init(void);
-void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0);
 void mshv_vtl_return_call_init(u64 vtl_return_offset);
 void mshv_vtl_return_hypercall(void);
 void __mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0);
@@ -294,7 +293,6 @@ int hv_vtl_get_set_reg(struct hv_register_assoc *regs, bool set, bool shared);
 #else
 static inline void __init hv_vtl_init_platform(void) {}
 static inline int __init hv_vtl_early_init(void) { return 0; }
-static inline void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0) {}
 static inline void mshv_vtl_return_call_init(u64 vtl_return_offset) {}
 static inline void mshv_vtl_return_hypercall(void) {}
 static inline void __mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0) {}
diff --git a/drivers/hv/mshv_vtl.h b/drivers/hv/mshv_vtl.h
index a6eea52f7aa2..103f07371f3f 100644
--- a/drivers/hv/mshv_vtl.h
+++ b/drivers/hv/mshv_vtl.h
@@ -22,4 +22,7 @@ struct mshv_vtl_run {
 	char vtl_ret_actions[MSHV_MAX_RUN_MSG_SIZE];
 };
 
+static_assert(sizeof(struct mshv_vtl_cpu_context) <= 1024,
+	      "struct mshv_vtl_cpu_context exceeds reserved space in struct mshv_vtl_run");
+
 #endif /* _MSHV_VTL_H */
diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyperv.h
index db183c8cfb95..8cdf2a9fbdfb 100644
--- a/include/asm-generic/mshyperv.h
+++ b/include/asm-generic/mshyperv.h
@@ -396,8 +396,10 @@ static inline int hv_deposit_memory(u64 partition_id, u64 status)
 
 #if IS_ENABLED(CONFIG_HYPERV_VTL_MODE)
 u8 __init get_vtl(void);
+void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0);
 #else
 static inline u8 get_vtl(void) { return 0; }
+static inline void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0) {}
 #endif
 
 #endif
-- 
2.43.0


From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 868DF1D6DB5;
	Thu, 23 Apr 2026 12:43:28 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=13.77.154.182
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1776948209; cv=none; b=McYmUPrkQ3Gzd/C0d1IwaEfitu/wwUgH+PKY/bQQwagC8/DGfH8BdmSI54ktfIfcI+tJaeVoRPNj2jDUvuAO6jihVBSeTR/RB13TMMq7JZlDGmbezJDeSe5AVNqsMOSec+GhG0Io74g3FBNulILygMTLXizdgrOpsBgPBiXZ50Y=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1776948209; c=relaxed/simple;
	bh=7jDf0qndz1oyEM0pImsr9dMT+4Hp4mYhkZE6kVNozDM=;
	h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
	 MIME-Version; b=jpv3VhvOkmwCYIJYjC2HnHjB1TMCLENoca++73PoibRXIurHryq6h5ng8cAcKYNvXujyHwaa3+vMYYEnvSyZ3nwmAP+JLTPZAxAa7Fp6Bqp69lanXPiSrhhFQU8o7+9yUzWYZMnuPGRxVOD0JSwH7XRoJ3oqoEvEeBARSxV2b+A=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com; spf=pass smtp.mailfrom=linux.microsoft.com; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b=NNQ3LTd5; arc=none smtp.client-ip=13.77.154.182
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="NNQ3LTd5"
Received: from CPC-namja-026ON.redmond.corp.microsoft.com (unknown [4.213.232.18])
	by linux.microsoft.com (Postfix) with ESMTPSA id 686C520B716D;
	Thu, 23 Apr 2026 05:43:21 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 686C520B716D
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1776948208;
	bh=AQZdLQ59S/MbqpK3C/yK6xjmEtEnqnrMolLC2gULXrU=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=NNQ3LTd5fOkxRO6d4h4FSo33AZnCbrUVpoKOERGdAyh4vOHjNxvzi28PEzhOcKJkB
	 2fn9REvjhoIut5m1/YH3p9loue9OP9qe3rH2HLhD1EJ4KFE5DrFf8h29+/qGAVusXd
	 5I9eo8NBr3Gk3/YNpx4NRc8RbqzDk+Jar1LOWwM4=
From: Naman Jain <namjain@linux.microsoft.com>
To: "K . Y . Srinivasan" <kys@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	Wei Liu <wei.liu@kernel.org>,
	Dexuan Cui <decui@microsoft.com>,
	Long Li <longli@microsoft.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Thomas Gleixner <tglx@kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org,
	"H . Peter Anvin" <hpa@zytor.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Paul Walmsley <pjw@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Alexandre Ghiti <alex@ghiti.fr>,
	Michael Kelley <mhklinux@outlook.com>
Cc: Marc Zyngier <maz@kernel.org>,
	Timothy Hayes <timothy.hayes@arm.com>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Sascha Bischoff <sascha.bischoff@arm.com>,
	mrigendrachaubey <mrigendra.chaubey@gmail.com>,
	Naman Jain <namjain@linux.microsoft.com>,
	linux-hyperv@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	linux-arch@vger.kernel.org,
	linux-riscv@lists.infradead.org,
	vdso@mailbox.org,
	ssengar@linux.microsoft.com
Subject: [PATCH v2 08/15] Drivers: hv: Move hv_call_(get|set)_vp_registers() declarations
Date: Thu, 23 Apr 2026 12:41:58 +0000
Message-ID: <20260423124206.2410879-9-namjain@linux.microsoft.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260423124206.2410879-1-namjain@linux.microsoft.com>
References: <20260423124206.2410879-1-namjain@linux.microsoft.com>
Precedence: bulk
X-Mailing-List: linux-arch@vger.kernel.org
List-Id: <linux-arch.vger.kernel.org>
List-Subscribe: <mailto:linux-arch+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-arch+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Move hv_call_get_vp_registers() and hv_call_set_vp_registers()
declarations from drivers/hv/mshv.h to include/asm-generic/mshyperv.h.

These functions are defined in mshv_common.c and are going to be called
from both drivers/hv/ and arch/x86/hyperv/hv_vtl.c. The latter never
included mshv.h, relying on implicit declaration visibility. Moving the
declarations to the arch-generic Hyper-V header makes them properly
visible to all architecture-specific callers.

Provide static inline stubs returning -EOPNOTSUPP when neither
CONFIG_MSHV_ROOT nor CONFIG_MSHV_VTL is enabled.

Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
---
 drivers/hv/mshv.h              |  8 --------
 include/asm-generic/mshyperv.h | 26 ++++++++++++++++++++++++++
 2 files changed, 26 insertions(+), 8 deletions(-)

diff --git a/drivers/hv/mshv.h b/drivers/hv/mshv.h
index d4813df92b9c..0fcb7f9ba6a9 100644
--- a/drivers/hv/mshv.h
+++ b/drivers/hv/mshv.h
@@ -14,14 +14,6 @@
 	memchr_inv(&((STRUCT).MEMBER), \
 		   0, sizeof_field(typeof(STRUCT), MEMBER))
 
-int hv_call_get_vp_registers(u32 vp_index, u64 partition_id, u16 count,
-			     union hv_input_vtl input_vtl,
-			     struct hv_register_assoc *registers);
-
-int hv_call_set_vp_registers(u32 vp_index, u64 partition_id, u16 count,
-			     union hv_input_vtl input_vtl,
-			     struct hv_register_assoc *registers);
-
 int hv_call_get_partition_property(u64 partition_id, u64 property_code,
 				   u64 *property_value);
 
diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyperv.h
index 8cdf2a9fbdfb..ef0b9466808c 100644
--- a/include/asm-generic/mshyperv.h
+++ b/include/asm-generic/mshyperv.h
@@ -394,6 +394,32 @@ static inline int hv_deposit_memory(u64 partition_id, u64 status)
 	return hv_deposit_memory_node(NUMA_NO_NODE, partition_id, status);
 }
 
+#if IS_ENABLED(CONFIG_MSHV_ROOT) || IS_ENABLED(CONFIG_MSHV_VTL)
+int hv_call_get_vp_registers(u32 vp_index, u64 partition_id, u16 count,
+			     union hv_input_vtl input_vtl,
+			     struct hv_register_assoc *registers);
+
+int hv_call_set_vp_registers(u32 vp_index, u64 partition_id, u16 count,
+			     union hv_input_vtl input_vtl,
+			     struct hv_register_assoc *registers);
+#else
+static inline int hv_call_get_vp_registers(u32 vp_index, u64 partition_id,
+					   u16 count,
+					   union hv_input_vtl input_vtl,
+					   struct hv_register_assoc *registers)
+{
+	return -EOPNOTSUPP;
+}
+
+static inline int hv_call_set_vp_registers(u32 vp_index, u64 partition_id,
+					   u16 count,
+					   union hv_input_vtl input_vtl,
+					   struct hv_register_assoc *registers)
+{
+	return -EOPNOTSUPP;
+}
+#endif /* CONFIG_MSHV_ROOT || CONFIG_MSHV_VTL */
+
 #if IS_ENABLED(CONFIG_HYPERV_VTL_MODE)
 u8 __init get_vtl(void);
 void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0);
-- 
2.43.0


From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 624561D6DB5;
	Thu, 23 Apr 2026 12:43:36 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=13.77.154.182
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1776948217; cv=none; b=BYp4ABpRZ7P5ZyFEpiR2zD1p4G07vzLo5ddK1MNKYW+qY2DwTyhdl5pqLLuam2AnR2jz2i+Riiw82EB8HZRm+4wxNL5za+PUCEaxsAwMHHZzP80n4oqW6sj0SO1rDwFQGW5qcCGJXBTjhh4CMDryf6jHuOq6b5bEprrcCoMvs6I=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1776948217; c=relaxed/simple;
	bh=YOK/a+e/PtY6w+pqw8Ybhle3cg9YiSM6I03HdX42Bn8=;
	h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
	 MIME-Version; b=XY47PbL1R8b1ZEuAXBz1Ll4fqTTlnPsdAZiBV+q7k79+unDOUHXSImG6ExudALoVQkyob2AEw78y8Vkz2NmbhIQpirwGDvW6XZ9uWKS3ff+9u9HRl71YBew0mMBPJ5dWyvEChGlAuLk0u+HJCasUhoe7YEbTV+Bb7lgnRfyl6QE=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com; spf=pass smtp.mailfrom=linux.microsoft.com; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b=JmSCk4Ym; arc=none smtp.client-ip=13.77.154.182
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="JmSCk4Ym"
Received: from CPC-namja-026ON.redmond.corp.microsoft.com (unknown [4.213.232.18])
	by linux.microsoft.com (Postfix) with ESMTPSA id 45C5820B7169;
	Thu, 23 Apr 2026 05:43:29 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 45C5820B7169
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1776948216;
	bh=uQw1PT6DTk9aMq/uyQg5ZP88ycqsrhH6HFR6Qo8Qtvo=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=JmSCk4YmnmzDUTARRleR7GDQGFC3wWT780ANEY8sBDC6VoRAKc1F1Pu5BC9WoCnMg
	 r/u12AZ5+4NrhrxhIlwandv1AmysWhK0cKlFyYYnR9i1JF53ayB68lBxA7/apqCUIj
	 lAWWPdgMd6mxfsTq7rhiVIrk3AHCq5ZseKLZPkJE=
From: Naman Jain <namjain@linux.microsoft.com>
To: "K . Y . Srinivasan" <kys@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	Wei Liu <wei.liu@kernel.org>,
	Dexuan Cui <decui@microsoft.com>,
	Long Li <longli@microsoft.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Thomas Gleixner <tglx@kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org,
	"H . Peter Anvin" <hpa@zytor.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Paul Walmsley <pjw@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Alexandre Ghiti <alex@ghiti.fr>,
	Michael Kelley <mhklinux@outlook.com>
Cc: Marc Zyngier <maz@kernel.org>,
	Timothy Hayes <timothy.hayes@arm.com>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Sascha Bischoff <sascha.bischoff@arm.com>,
	mrigendrachaubey <mrigendra.chaubey@gmail.com>,
	Naman Jain <namjain@linux.microsoft.com>,
	linux-hyperv@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	linux-arch@vger.kernel.org,
	linux-riscv@lists.infradead.org,
	vdso@mailbox.org,
	ssengar@linux.microsoft.com
Subject: [PATCH v2 09/15] Drivers: hv: mshv_vtl: Move hv_vtl_configure_reg_page() to x86
Date: Thu, 23 Apr 2026 12:41:59 +0000
Message-ID: <20260423124206.2410879-10-namjain@linux.microsoft.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260423124206.2410879-1-namjain@linux.microsoft.com>
References: <20260423124206.2410879-1-namjain@linux.microsoft.com>
Precedence: bulk
X-Mailing-List: linux-arch@vger.kernel.org
List-Id: <linux-arch.vger.kernel.org>
List-Subscribe: <mailto:linux-arch+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-arch+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Move hv_vtl_configure_reg_page() from drivers/hv/mshv_vtl_main.c to
arch/x86/hyperv/hv_vtl.c. The register page overlay is an x86-specific
feature that uses HV_X64_REGISTER_REG_PAGE, so its configuration belongs
in architecture-specific code.

Move struct mshv_vtl_per_cpu and union hv_synic_overlay_page_msr to
include/asm-generic/mshyperv.h so they are visible to both arch and
driver code.

Change the return type from void to bool so the caller can determine
whether the register page was successfully configured and set
mshv_has_reg_page accordingly.

Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
---
 arch/x86/hyperv/hv_vtl.c       | 32 ++++++++++++++++++++++
 drivers/hv/mshv_vtl_main.c     | 49 +++-------------------------------
 include/asm-generic/mshyperv.h | 17 ++++++++++++
 3 files changed, 53 insertions(+), 45 deletions(-)

diff --git a/arch/x86/hyperv/hv_vtl.c b/arch/x86/hyperv/hv_vtl.c
index 09d81f9b853c..f3ffb6a7cb2d 100644
--- a/arch/x86/hyperv/hv_vtl.c
+++ b/arch/x86/hyperv/hv_vtl.c
@@ -20,6 +20,7 @@
 #include <uapi/asm/mtrr.h>
 #include <asm/debugreg.h>
 #include <linux/export.h>
+#include <linux/hyperv.h>
 #include <../kernel/smpboot.h>
 #include "../../kernel/fpu/legacy.h"
 
@@ -259,6 +260,37 @@ int __init hv_vtl_early_init(void)
 	return 0;
 }
 
+static const union hv_input_vtl input_vtl_zero;
+
+bool hv_vtl_configure_reg_page(struct mshv_vtl_per_cpu *per_cpu)
+{
+	struct hv_register_assoc reg_assoc = {};
+	union hv_synic_overlay_page_msr overlay = {};
+	struct page *reg_page;
+
+	reg_page = alloc_page(GFP_KERNEL | __GFP_ZERO | __GFP_RETRY_MAYFAIL);
+	if (!reg_page) {
+		WARN(1, "failed to allocate register page\n");
+		return false;
+	}
+
+	overlay.enabled = 1;
+	overlay.pfn = page_to_hvpfn(reg_page);
+	reg_assoc.name = HV_X64_REGISTER_REG_PAGE;
+	reg_assoc.value.reg64 = overlay.as_uint64;
+
+	if (hv_call_set_vp_registers(HV_VP_INDEX_SELF, HV_PARTITION_ID_SELF,
+				     1, input_vtl_zero, &reg_assoc)) {
+		WARN(1, "failed to setup register page\n");
+		__free_page(reg_page);
+		return false;
+	}
+
+	per_cpu->reg_page = reg_page;
+	return true;
+}
+EXPORT_SYMBOL_GPL(hv_vtl_configure_reg_page);
+
 DEFINE_STATIC_CALL_NULL(__mshv_vtl_return_hypercall, void (*)(void));
 
 void mshv_vtl_return_call_init(u64 vtl_return_offset)
diff --git a/drivers/hv/mshv_vtl_main.c b/drivers/hv/mshv_vtl_main.c
index 91517b45d526..c79d24317b8e 100644
--- a/drivers/hv/mshv_vtl_main.c
+++ b/drivers/hv/mshv_vtl_main.c
@@ -78,21 +78,6 @@ struct mshv_vtl {
 	u64 id;
 };
 
-struct mshv_vtl_per_cpu {
-	struct mshv_vtl_run *run;
-	struct page *reg_page;
-};
-
-/* SYNIC_OVERLAY_PAGE_MSR - internal, identical to hv_synic_simp */
-union hv_synic_overlay_page_msr {
-	u64 as_uint64;
-	struct {
-		u64 enabled: 1;
-		u64 reserved: 11;
-		u64 pfn: 52;
-	} __packed;
-};
-
 static struct mutex mshv_vtl_poll_file_lock;
 static union hv_register_vsm_page_offsets mshv_vsm_page_offsets;
 static union hv_register_vsm_capabilities mshv_vsm_capabilities;
@@ -201,34 +186,6 @@ static struct page *mshv_vtl_cpu_reg_page(int cpu)
 	return *per_cpu_ptr(&mshv_vtl_per_cpu.reg_page, cpu);
 }
 
-static void mshv_vtl_configure_reg_page(struct mshv_vtl_per_cpu *per_cpu)
-{
-	struct hv_register_assoc reg_assoc = {};
-	union hv_synic_overlay_page_msr overlay = {};
-	struct page *reg_page;
-
-	reg_page = alloc_page(GFP_KERNEL | __GFP_ZERO | __GFP_RETRY_MAYFAIL);
-	if (!reg_page) {
-		WARN(1, "failed to allocate register page\n");
-		return;
-	}
-
-	overlay.enabled = 1;
-	overlay.pfn = page_to_hvpfn(reg_page);
-	reg_assoc.name = HV_X64_REGISTER_REG_PAGE;
-	reg_assoc.value.reg64 = overlay.as_uint64;
-
-	if (hv_call_set_vp_registers(HV_VP_INDEX_SELF, HV_PARTITION_ID_SELF,
-				     1, input_vtl_zero, &reg_assoc)) {
-		WARN(1, "failed to setup register page\n");
-		__free_page(reg_page);
-		return;
-	}
-
-	per_cpu->reg_page = reg_page;
-	mshv_has_reg_page = true;
-}
-
 static void mshv_vtl_synic_enable_regs(unsigned int cpu)
 {
 	union hv_synic_sint sint;
@@ -329,8 +286,10 @@ static int mshv_vtl_alloc_context(unsigned int cpu)
 	if (!per_cpu->run)
 		return -ENOMEM;
 
-	if (mshv_vsm_capabilities.intercept_page_available)
-		mshv_vtl_configure_reg_page(per_cpu);
+	if (mshv_vsm_capabilities.intercept_page_available) {
+		if (hv_vtl_configure_reg_page(per_cpu))
+			mshv_has_reg_page = true;
+	}
 
 	mshv_vtl_synic_enable_regs(cpu);
 
diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyperv.h
index ef0b9466808c..9e86178c182e 100644
--- a/include/asm-generic/mshyperv.h
+++ b/include/asm-generic/mshyperv.h
@@ -420,12 +420,29 @@ static inline int hv_call_set_vp_registers(u32 vp_index, u64 partition_id,
 }
 #endif /* CONFIG_MSHV_ROOT || CONFIG_MSHV_VTL */
 
+struct mshv_vtl_per_cpu {
+	struct mshv_vtl_run *run;
+	struct page *reg_page;
+};
+
 #if IS_ENABLED(CONFIG_HYPERV_VTL_MODE)
+/* SYNIC_OVERLAY_PAGE_MSR - internal, identical to hv_synic_simp */
+union hv_synic_overlay_page_msr {
+	u64 as_uint64;
+	struct {
+		u64 enabled: 1;
+		u64 reserved: 11;
+		u64 pfn: 52;
+	} __packed;
+};
+
 u8 __init get_vtl(void);
 void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0);
+bool hv_vtl_configure_reg_page(struct mshv_vtl_per_cpu *per_cpu);
 #else
 static inline u8 get_vtl(void) { return 0; }
 static inline void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0) {}
+static inline bool hv_vtl_configure_reg_page(struct mshv_vtl_per_cpu *per_cpu) { return false; }
 #endif
 
 #endif
-- 
2.43.0


From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 36DB73EDAA6;
	Thu, 23 Apr 2026 12:43:44 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=13.77.154.182
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1776948225; cv=none; b=hSYc5rcubyOcWI0PUmDTeU0O50mSbfa3hEBDpJqCrcNYKyi64mROdlh+3CnphJkfpgVMyO23JGxAHkG/icxgV36OG7qTmP2LvshLfOUJwYGgVmUTlhf1B/aiEuOAtlm5/i6wulpVioxpE39gTi/jJbmalxRVyYG2o8072M56vk8=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1776948225; c=relaxed/simple;
	bh=xTtc9TutELlyQEkkRXCdnqpf1ZRzLYGo6NHAK52BlN4=;
	h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
	 MIME-Version; b=W6klJioMewCazYvck6BYxq6ptxJI7JMzgB+llmD0d0ZHR2iubSYpvKHLTWZ9AM568tZbtuMiiTkY/w/H4JridVvKDitOzMxUQZvTyMYAjni9jRGvOoeijqieItC2r3+UYDgRSa5A/8Vbu60p9QFCmXZHdOipAJIkwh/H85RbIEQ=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com; spf=pass smtp.mailfrom=linux.microsoft.com; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b=jnDmNSc0; arc=none smtp.client-ip=13.77.154.182
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="jnDmNSc0"
Received: from CPC-namja-026ON.redmond.corp.microsoft.com (unknown [4.213.232.18])
	by linux.microsoft.com (Postfix) with ESMTPSA id 37DC520B7167;
	Thu, 23 Apr 2026 05:43:37 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 37DC520B7167
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1776948224;
	bh=HSbbqWv3vuhtoGamHoPNheyejHz2e9u0oDYSbNnHoaw=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=jnDmNSc0a/QiF41tnxPVpEemp0ovscQVoHm7CEknskN0kFoNazOQmBlBxrsnROhBF
	 HheeJD79c5Vtd0Nsn/hk4DaJ85YaULJVPW12qOrDSXkk2T4+rkdp4TmKCHfJ7PXX7H
	 s4ZTD4CYNMR+wg+YC3mqrxLdgn9/4lpM4PspwDDo=
From: Naman Jain <namjain@linux.microsoft.com>
To: "K . Y . Srinivasan" <kys@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	Wei Liu <wei.liu@kernel.org>,
	Dexuan Cui <decui@microsoft.com>,
	Long Li <longli@microsoft.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Thomas Gleixner <tglx@kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org,
	"H . Peter Anvin" <hpa@zytor.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Paul Walmsley <pjw@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Alexandre Ghiti <alex@ghiti.fr>,
	Michael Kelley <mhklinux@outlook.com>
Cc: Marc Zyngier <maz@kernel.org>,
	Timothy Hayes <timothy.hayes@arm.com>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Sascha Bischoff <sascha.bischoff@arm.com>,
	mrigendrachaubey <mrigendra.chaubey@gmail.com>,
	Naman Jain <namjain@linux.microsoft.com>,
	linux-hyperv@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	linux-arch@vger.kernel.org,
	linux-riscv@lists.infradead.org,
	vdso@mailbox.org,
	ssengar@linux.microsoft.com
Subject: [PATCH v2 10/15] arm64: hyperv: Add hv_vtl_configure_reg_page() stub
Date: Thu, 23 Apr 2026 12:42:00 +0000
Message-ID: <20260423124206.2410879-11-namjain@linux.microsoft.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260423124206.2410879-1-namjain@linux.microsoft.com>
References: <20260423124206.2410879-1-namjain@linux.microsoft.com>
Precedence: bulk
X-Mailing-List: linux-arch@vger.kernel.org
List-Id: <linux-arch.vger.kernel.org>
List-Subscribe: <mailto:linux-arch+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-arch+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

ARM64 does not support the register page overlay, so provide a stub
that returns false. This pairs with the preceding commit that moved
hv_vtl_configure_reg_page() out of common code into architecture-
specific files.

Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
---
 arch/arm64/hyperv/hv_vtl.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/hyperv/hv_vtl.c b/arch/arm64/hyperv/hv_vtl.c
index 59cbeb74e7b9..e07f6a865350 100644
--- a/arch/arm64/hyperv/hv_vtl.c
+++ b/arch/arm64/hyperv/hv_vtl.c
@@ -156,3 +156,10 @@ void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0)
 	kernel_neon_end(&fpsimd_state);
 }
 EXPORT_SYMBOL(mshv_vtl_return_call);
+
+bool hv_vtl_configure_reg_page(struct mshv_vtl_per_cpu *per_cpu)
+{
+	pr_debug("Register page not supported on ARM64\n");
+	return false;
+}
+EXPORT_SYMBOL_GPL(hv_vtl_configure_reg_page);
-- 
2.43.0


From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 3E7B63EDAA5;
	Thu, 23 Apr 2026 12:43:52 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=13.77.154.182
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1776948233; cv=none; b=kyDfttBG5vMRAxTUIDGtCP7luZqR3pqrU18iRcY4c99jA7LGIrkRn5VC+PY5f24KmF9sJD3P528n88EWkgS1LTITT+B1dn6k0zzRXkGlBpdf+1aHi+tmWvB7JqcxnRWzXroTgTDDlmARrgPae1CZJ3TjNlIuHmyU+McllzcWQX0=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1776948233; c=relaxed/simple;
	bh=G6rRZTfAM29k5zPVR/ARwkGaN/9gK2H/QSOjtVbIZj0=;
	h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
	 MIME-Version; b=r0vUGpxHtluSuhe7tHjdxsE+qunJeiL+xtms2b9a4dhj4JZwfng9QJ0PvSdCpaJddQgzwGZ8szc4axkJD0MBwU4pZgITBAe9kjRzPDZB2llQerVHFQB3v2PYAF5gVdGQ4K/Mz7abd3esZFWe1DRDiHGbewsQtIdE9O2W8Qc07xQ=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com; spf=pass smtp.mailfrom=linux.microsoft.com; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b=YxO7hPzN; arc=none smtp.client-ip=13.77.154.182
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="YxO7hPzN"
Received: from CPC-namja-026ON.redmond.corp.microsoft.com (unknown [4.213.232.18])
	by linux.microsoft.com (Postfix) with ESMTPSA id EF51020B716B;
	Thu, 23 Apr 2026 05:43:44 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com EF51020B716B
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1776948232;
	bh=KqEEuEXQvpD/kvIiGjagKYi0LOOzLGoRJMfm2FtbD3c=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=YxO7hPzNELzGH9P0Z2ujovLhGRHcJDfzVksL8WlejF6Q0UKhR2rFbwJGoIu8dXiV2
	 MYu+15iX7h+FJfSOE3IiGnlOzUBYnjy3nkG/aE/HMExXqJdFMKYcIjIOfsVZ9M6lw2
	 YyVElBj/tFqH5GtAW4RPqFMZ6+qEIS6LP4RrqOH4=
From: Naman Jain <namjain@linux.microsoft.com>
To: "K . Y . Srinivasan" <kys@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	Wei Liu <wei.liu@kernel.org>,
	Dexuan Cui <decui@microsoft.com>,
	Long Li <longli@microsoft.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Thomas Gleixner <tglx@kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org,
	"H . Peter Anvin" <hpa@zytor.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Paul Walmsley <pjw@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Alexandre Ghiti <alex@ghiti.fr>,
	Michael Kelley <mhklinux@outlook.com>
Cc: Marc Zyngier <maz@kernel.org>,
	Timothy Hayes <timothy.hayes@arm.com>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Sascha Bischoff <sascha.bischoff@arm.com>,
	mrigendrachaubey <mrigendra.chaubey@gmail.com>,
	Naman Jain <namjain@linux.microsoft.com>,
	linux-hyperv@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	linux-arch@vger.kernel.org,
	linux-riscv@lists.infradead.org,
	vdso@mailbox.org,
	ssengar@linux.microsoft.com
Subject: [PATCH v2 11/15] mshv_vtl: Let userspace do VSM configuration
Date: Thu, 23 Apr 2026 12:42:01 +0000
Message-ID: <20260423124206.2410879-12-namjain@linux.microsoft.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260423124206.2410879-1-namjain@linux.microsoft.com>
References: <20260423124206.2410879-1-namjain@linux.microsoft.com>
Precedence: bulk
X-Mailing-List: linux-arch@vger.kernel.org
List-Id: <linux-arch.vger.kernel.org>
List-Subscribe: <mailto:linux-arch+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-arch+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The kernel currently sets the VSM configuration register, thereby
imposing certain VSM configuration on the userspace (OpenVMM).

The userspace (OpenVMM) has the capability to configure this register,
and it is already doing it using the generic hypercall interface.
The configuration can vary based on the use case or architectures, so
let userspace take care of configuring it and remove this logic in the
kernel driver.

Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Reviewed-by: Roman Kisel <vdso@mailbox.org>
Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
---
 drivers/hv/mshv_vtl_main.c | 29 -----------------------------
 1 file changed, 29 deletions(-)

diff --git a/drivers/hv/mshv_vtl_main.c b/drivers/hv/mshv_vtl_main.c
index c79d24317b8e..4c9ae65ad3e8 100644
--- a/drivers/hv/mshv_vtl_main.c
+++ b/drivers/hv/mshv_vtl_main.c
@@ -222,30 +222,6 @@ static int mshv_vtl_get_vsm_regs(void)
 	return ret;
 }
 
-static int mshv_vtl_configure_vsm_partition(struct device *dev)
-{
-	union hv_register_vsm_partition_config config;
-	struct hv_register_assoc reg_assoc;
-
-	config.as_uint64 = 0;
-	config.default_vtl_protection_mask = HV_MAP_GPA_PERMISSIONS_MASK;
-	config.enable_vtl_protection = 1;
-	config.zero_memory_on_reset = 1;
-	config.intercept_vp_startup = 1;
-	config.intercept_cpuid_unimplemented = 1;
-
-	if (mshv_vsm_capabilities.intercept_page_available) {
-		dev_dbg(dev, "using intercept page\n");
-		config.intercept_page = 1;
-	}
-
-	reg_assoc.name = HV_REGISTER_VSM_PARTITION_CONFIG;
-	reg_assoc.value.reg64 = config.as_uint64;
-
-	return hv_call_set_vp_registers(HV_VP_INDEX_SELF, HV_PARTITION_ID_SELF,
-				       1, input_vtl_zero, &reg_assoc);
-}
-
 static void mshv_vtl_vmbus_isr(void)
 {
 	struct hv_per_cpu_context *per_cpu;
@@ -1168,11 +1144,6 @@ static int __init mshv_vtl_init(void)
 		ret = -ENODEV;
 		goto free_dev;
 	}
-	if (mshv_vtl_configure_vsm_partition(dev)) {
-		dev_emerg(dev, "VSM configuration failed !!\n");
-		ret = -ENODEV;
-		goto free_dev;
-	}
 
 	mshv_vtl_return_call_init(mshv_vsm_page_offsets.vtl_return_offset);
 	ret = hv_vtl_setup_synic();
-- 
2.43.0


From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 0F120382281;
	Thu, 23 Apr 2026 12:43:59 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=13.77.154.182
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1776948241; cv=none; b=Lqhxli35e3ohL53iuLJZMTjaz6KJNF4/J37+PUDEwYVU8F86rTTH2fCWemz5IpSbiXK5XAy7+ZbMSreS9ng1leFOOHaA7FflnpgDX2plLhKOGzn8CrzoFCadsXNy8K9nChh+0uu5vE7vEmgA17Ipllmj6eb7dhDrHI1rRbtDBt0=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1776948241; c=relaxed/simple;
	bh=Yl2tqtoe6+sXbirM1ZqrVjc/Ixhrns5ByeitkyVRDm8=;
	h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
	 MIME-Version; b=MzeHfcN3SJEg6H5EYhKxZtZT6L62a+SiTxP/n0Jg18X5sOcApcWclxJeReCv+nhEjmMIgFj9S0acrZev6TelLMpW+pPz1/UTxYQyWB/FAcIpA4xP7mQVgVpCRYZEC1AeFFUN/s+eLn4lkpEDIEJlYFPXSQvcEh6pl1CNX6IhyzE=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com; spf=pass smtp.mailfrom=linux.microsoft.com; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b=oIKRO7GJ; arc=none smtp.client-ip=13.77.154.182
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="oIKRO7GJ"
Received: from CPC-namja-026ON.redmond.corp.microsoft.com (unknown [4.213.232.18])
	by linux.microsoft.com (Postfix) with ESMTPSA id D685E20B7172;
	Thu, 23 Apr 2026 05:43:52 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com D685E20B7172
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1776948240;
	bh=wwtrSevDXsiP4ai9nAki7ynEwNWhGDuPbqk73+Idwtg=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=oIKRO7GJl2Gm7dcJrQHwiTxm2axwxWGppTMKxuLoDn+EPRMGbsJTNvawOzU+7GVf6
	 vGvJcp2InOpXQHjLPEyByEnJuHw/OzOgIomchpySoIozcjj1QsjJdx4US2BOrqF9fz
	 6IASXptBiFTXx75DHr9XFAiKATMW22wSzKTDOqmE=
From: Naman Jain <namjain@linux.microsoft.com>
To: "K . Y . Srinivasan" <kys@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	Wei Liu <wei.liu@kernel.org>,
	Dexuan Cui <decui@microsoft.com>,
	Long Li <longli@microsoft.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Thomas Gleixner <tglx@kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org,
	"H . Peter Anvin" <hpa@zytor.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Paul Walmsley <pjw@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Alexandre Ghiti <alex@ghiti.fr>,
	Michael Kelley <mhklinux@outlook.com>
Cc: Marc Zyngier <maz@kernel.org>,
	Timothy Hayes <timothy.hayes@arm.com>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Sascha Bischoff <sascha.bischoff@arm.com>,
	mrigendrachaubey <mrigendra.chaubey@gmail.com>,
	Naman Jain <namjain@linux.microsoft.com>,
	linux-hyperv@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	linux-arch@vger.kernel.org,
	linux-riscv@lists.infradead.org,
	vdso@mailbox.org,
	ssengar@linux.microsoft.com
Subject: [PATCH v2 12/15] mshv_vtl: Move VSM code page offset logic to x86 files
Date: Thu, 23 Apr 2026 12:42:02 +0000
Message-ID: <20260423124206.2410879-13-namjain@linux.microsoft.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260423124206.2410879-1-namjain@linux.microsoft.com>
References: <20260423124206.2410879-1-namjain@linux.microsoft.com>
Precedence: bulk
X-Mailing-List: linux-arch@vger.kernel.org
List-Id: <linux-arch.vger.kernel.org>
List-Subscribe: <mailto:linux-arch+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-arch+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The VSM code page offset register (HV_REGISTER_VSM_CODE_PAGE_OFFSETS)
is x86 specific, its value configures the static call used to return
to VTL0 via the hypercall page. Move the register read from the common
mshv_vtl_get_vsm_regs() into the x86 mshv_vtl_return_call_init(),
which is the sole consumer of the offset.

Change mshv_vtl_return_call_init() from taking a u64 parameter
to taking no arguments, and rename mshv_vtl_get_vsm_regs() to
mshv_vtl_get_vsm_cap_reg() since it now only fetches
HV_REGISTER_VSM_CAPABILITIES.

No functional change on x86. This prepares the common driver code for
ARM64 where VSM code page offsets do not apply.

Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
---
 arch/x86/hyperv/hv_vtl.c        | 19 +++++++++++++++++--
 arch/x86/include/asm/mshyperv.h |  4 ++--
 drivers/hv/mshv_vtl_main.c      | 24 +++++++++++++-----------
 3 files changed, 32 insertions(+), 15 deletions(-)

diff --git a/arch/x86/hyperv/hv_vtl.c b/arch/x86/hyperv/hv_vtl.c
index f3ffb6a7cb2d..7c10b34cf8a4 100644
--- a/arch/x86/hyperv/hv_vtl.c
+++ b/arch/x86/hyperv/hv_vtl.c
@@ -293,10 +293,25 @@ EXPORT_SYMBOL_GPL(hv_vtl_configure_reg_page);
 
 DEFINE_STATIC_CALL_NULL(__mshv_vtl_return_hypercall, void (*)(void));
 
-void mshv_vtl_return_call_init(u64 vtl_return_offset)
+int mshv_vtl_return_call_init(void)
 {
+	struct hv_register_assoc vsm_pg_offset_reg;
+	union hv_register_vsm_page_offsets offsets;
+	int ret;
+
+	vsm_pg_offset_reg.name = HV_REGISTER_VSM_CODE_PAGE_OFFSETS;
+
+	ret = hv_call_get_vp_registers(HV_VP_INDEX_SELF, HV_PARTITION_ID_SELF,
+				       1, input_vtl_zero, &vsm_pg_offset_reg);
+	if (ret)
+		return ret;
+
+	offsets.as_uint64 = vsm_pg_offset_reg.value.reg64;
+
 	static_call_update(__mshv_vtl_return_hypercall,
-			   (void *)((u8 *)hv_hypercall_pg + vtl_return_offset));
+			   (void *)((u8 *)hv_hypercall_pg + offsets.vtl_return_offset));
+
+	return 0;
 }
 EXPORT_SYMBOL(mshv_vtl_return_call_init);
 
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index b4d80c9a673a..b48f115c1292 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -286,14 +286,14 @@ struct mshv_vtl_cpu_context {
 #ifdef CONFIG_HYPERV_VTL_MODE
 void __init hv_vtl_init_platform(void);
 int __init hv_vtl_early_init(void);
-void mshv_vtl_return_call_init(u64 vtl_return_offset);
+int mshv_vtl_return_call_init(void);
 void mshv_vtl_return_hypercall(void);
 void __mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0);
 int hv_vtl_get_set_reg(struct hv_register_assoc *regs, bool set, bool shared);
 #else
 static inline void __init hv_vtl_init_platform(void) {}
 static inline int __init hv_vtl_early_init(void) { return 0; }
-static inline void mshv_vtl_return_call_init(u64 vtl_return_offset) {}
+static inline int mshv_vtl_return_call_init(void) { return 0; }
 static inline void mshv_vtl_return_hypercall(void) {}
 static inline void __mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0) {}
 #endif
diff --git a/drivers/hv/mshv_vtl_main.c b/drivers/hv/mshv_vtl_main.c
index 4c9ae65ad3e8..be498c9234fd 100644
--- a/drivers/hv/mshv_vtl_main.c
+++ b/drivers/hv/mshv_vtl_main.c
@@ -79,7 +79,6 @@ struct mshv_vtl {
 };
 
 static struct mutex mshv_vtl_poll_file_lock;
-static union hv_register_vsm_page_offsets mshv_vsm_page_offsets;
 static union hv_register_vsm_capabilities mshv_vsm_capabilities;
 
 static DEFINE_PER_CPU(struct mshv_vtl_poll_file, mshv_vtl_poll_file);
@@ -203,21 +202,19 @@ static void mshv_vtl_synic_enable_regs(unsigned int cpu)
 	/* VTL2 Host VSP SINT is (un)masked when the user mode requests that */
 }
 
-static int mshv_vtl_get_vsm_regs(void)
+static int mshv_vtl_get_vsm_cap_reg(void)
 {
-	struct hv_register_assoc registers[2];
-	int ret, count = 2;
+	struct hv_register_assoc vsm_capability_reg;
+	int ret;
 
-	registers[0].name = HV_REGISTER_VSM_CODE_PAGE_OFFSETS;
-	registers[1].name = HV_REGISTER_VSM_CAPABILITIES;
+	vsm_capability_reg.name = HV_REGISTER_VSM_CAPABILITIES;
 
 	ret = hv_call_get_vp_registers(HV_VP_INDEX_SELF, HV_PARTITION_ID_SELF,
-				       count, input_vtl_zero, registers);
+				       1, input_vtl_zero, &vsm_capability_reg);
 	if (ret)
 		return ret;
 
-	mshv_vsm_page_offsets.as_uint64 = registers[0].value.reg64;
-	mshv_vsm_capabilities.as_uint64 = registers[1].value.reg64;
+	mshv_vsm_capabilities.as_uint64 = vsm_capability_reg.value.reg64;
 
 	return ret;
 }
@@ -1139,13 +1136,18 @@ static int __init mshv_vtl_init(void)
 	tasklet_init(&msg_dpc, mshv_vtl_sint_on_msg_dpc, 0);
 	init_waitqueue_head(&fd_wait_queue);
 
-	if (mshv_vtl_get_vsm_regs()) {
+	if (mshv_vtl_get_vsm_cap_reg()) {
 		dev_emerg(dev, "Unable to get VSM capabilities !!\n");
 		ret = -ENODEV;
 		goto free_dev;
 	}
 
-	mshv_vtl_return_call_init(mshv_vsm_page_offsets.vtl_return_offset);
+	ret = mshv_vtl_return_call_init();
+	if (ret) {
+		dev_err(dev, "mshv_vtl_return_call_init failed: %d\n", ret);
+		goto free_dev;
+	}
+
 	ret = hv_vtl_setup_synic();
 	if (ret)
 		goto free_dev;
-- 
2.43.0


From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id BFDBF3ED5DB;
	Thu, 23 Apr 2026 12:44:07 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=13.77.154.182
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1776948248; cv=none; b=OXueiSZ35kihaQVSaRbF5u6IaDnxvo3EnY/75FwUBHmBC7q+2az+TIkZWpqWbrWenuHs+A/zyvIR1Sbnjpt+a9E8716zb3P3RRts1XdUEZ3ozFqtsWVh4WBZPK9FBuqdGx3TtiRnO9JY3V5Z2VKaUsngF0ThY+no/zI3PeuKFZQ=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1776948248; c=relaxed/simple;
	bh=QhwlyZLVHh3iKGvYP2jk7wpTpp9V2bihpmbro8Kp1gU=;
	h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
	 MIME-Version; b=bElM705n4zEYJ3+WD3fVhMqa1qrEqEHHuMPLrGswUrflHxu8MZWLPC3I4WJMYLLvzL0DFI4JrtiQraqgYQEp2VxFLIbWRZ6IWYBE5Uf/lkASCe7l3ARsXYZZoP1pc20HwEpn51rR3mVTNlgPkZPDaCgsjLTszGBdY7MAQK9Osxk=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com; spf=pass smtp.mailfrom=linux.microsoft.com; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b=Ex1bUyOf; arc=none smtp.client-ip=13.77.154.182
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="Ex1bUyOf"
Received: from CPC-namja-026ON.redmond.corp.microsoft.com (unknown [4.213.232.18])
	by linux.microsoft.com (Postfix) with ESMTPSA id BDFEE20B716F;
	Thu, 23 Apr 2026 05:44:00 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com BDFEE20B716F
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1776948247;
	bh=1Si2vLE+zPB6prbMPE/cdtc4huvV7tWVF4D7BT4Ap7I=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=Ex1bUyOfRJKCP+0lBVsUziVPVd+0d51ReTPSRmFbuc28vd3Nz4ptTcg4+AVNnYZM9
	 RSunynWJvpI5uw7AKMyeGLw50tlZ95+Tlt6dvDrxSPQem9Esju+nJmcsQ/kGebKLqi
	 HUTyiX+QXMF7vONKiTPx6RrGdBNVwqf9es11vYGs=
From: Naman Jain <namjain@linux.microsoft.com>
To: "K . Y . Srinivasan" <kys@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	Wei Liu <wei.liu@kernel.org>,
	Dexuan Cui <decui@microsoft.com>,
	Long Li <longli@microsoft.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Thomas Gleixner <tglx@kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org,
	"H . Peter Anvin" <hpa@zytor.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Paul Walmsley <pjw@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Alexandre Ghiti <alex@ghiti.fr>,
	Michael Kelley <mhklinux@outlook.com>
Cc: Marc Zyngier <maz@kernel.org>,
	Timothy Hayes <timothy.hayes@arm.com>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Sascha Bischoff <sascha.bischoff@arm.com>,
	mrigendrachaubey <mrigendra.chaubey@gmail.com>,
	Naman Jain <namjain@linux.microsoft.com>,
	linux-hyperv@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	linux-arch@vger.kernel.org,
	linux-riscv@lists.infradead.org,
	vdso@mailbox.org,
	ssengar@linux.microsoft.com
Subject: [PATCH v2 13/15] mshv_vtl: Add remaining support for arm64
Date: Thu, 23 Apr 2026 12:42:03 +0000
Message-ID: <20260423124206.2410879-14-namjain@linux.microsoft.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260423124206.2410879-1-namjain@linux.microsoft.com>
References: <20260423124206.2410879-1-namjain@linux.microsoft.com>
Precedence: bulk
X-Mailing-List: linux-arch@vger.kernel.org
List-Id: <linux-arch.vger.kernel.org>
List-Subscribe: <mailto:linux-arch+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-arch+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Add necessary support to make MSHV_VTL work for arm64 architecture.
* Add stub implementation for mshv_vtl_return_call_init() as it's not
  required for arm64
* Handle hugepage functions by config checks, as it's x86 specific
* fpu/legacy.h header inclusion was required when x86 assembly code
  was present here, it got left when the code was moved to arch files.
  Remove it now (unrelated to arm64)

Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
---
 arch/arm64/include/asm/mshyperv.h | 2 ++
 drivers/hv/mshv_vtl_main.c        | 4 ++--
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/include/asm/mshyperv.h b/arch/arm64/include/asm/mshyperv.h
index 9eb0e5999f29..6f668ec68b2f 100644
--- a/arch/arm64/include/asm/mshyperv.h
+++ b/arch/arm64/include/asm/mshyperv.h
@@ -82,6 +82,8 @@ static inline int hv_vtl_get_set_reg(struct hv_register_assoc *regs, bool set, b
 	return 1;
 }
 
+/* Stubbed for arm64 */
+static inline int mshv_vtl_return_call_init(void) { return 0; }
 #endif
 
 #include <asm-generic/mshyperv.h>
diff --git a/drivers/hv/mshv_vtl_main.c b/drivers/hv/mshv_vtl_main.c
index be498c9234fd..d5308956dfb6 100644
--- a/drivers/hv/mshv_vtl_main.c
+++ b/drivers/hv/mshv_vtl_main.c
@@ -23,8 +23,6 @@
 #include <trace/events/ipi.h>
 #include <uapi/linux/mshv.h>
 #include <hyperv/hvhdk.h>
-
-#include "../../kernel/fpu/legacy.h"
 #include "mshv.h"
 #include "mshv_vtl.h"
 #include "hyperv_vmbus.h"
@@ -1077,10 +1075,12 @@ static vm_fault_t mshv_vtl_low_huge_fault(struct vm_fault *vmf, unsigned int ord
 			ret = vmf_insert_pfn_pmd(vmf, pfn, vmf->flags & FAULT_FLAG_WRITE);
 		return ret;
 
+#if defined(CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD)
 	case PUD_ORDER:
 		if (can_fault(vmf, PUD_SIZE, &pfn))
 			ret = vmf_insert_pfn_pud(vmf, pfn, vmf->flags & FAULT_FLAG_WRITE);
 		return ret;
+#endif
 
 	default:
 		return VM_FAULT_SIGBUS;
-- 
2.43.0


From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 32C4B1D6DB5;
	Thu, 23 Apr 2026 12:44:29 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=13.77.154.182
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1776948270; cv=none; b=JP6i1sNU6f1aPTriVjk8ECTntxTjSDwexGjR5CpzmlpKhzyt/rbSlmJWcLQeTPE7QB7wtw6xDz0l6PFFjyAxO+vMzOxWuC4AE3J0Vor7qQz9Zy+83HD6J1R4W2QFwa1ZlheSM7OOlO5HDkPtBfT0DUu/hs7G8IV1TXuENFneegc=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1776948270; c=relaxed/simple;
	bh=CoDvSCNn4jGrMUulDHPvfhhkBsriG7oP3HcJNSqjRng=;
	h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
	 MIME-Version; b=uSfG1UDbI2BJvP4C4M2JKLjEAQnqgXiqH7xf5DfsTOIGTJwgbJU3HIffakGkHtkDVyLykkopwoAmERkVoGm2KgTRecENMM8QP8zAjlcLSe8tx0+KfHSVxhDMR9B6O5BmNnB7jeuVXBYmHRRaA4bLkWu0bsOTHUUDyQbmFn0VMEU=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com; spf=pass smtp.mailfrom=linux.microsoft.com; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b=o9WkEKDY; arc=none smtp.client-ip=13.77.154.182
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="o9WkEKDY"
Received: from CPC-namja-026ON.redmond.corp.microsoft.com (unknown [4.213.232.18])
	by linux.microsoft.com (Postfix) with ESMTPSA id 8D79720B716E;
	Thu, 23 Apr 2026 05:44:08 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 8D79720B716E
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1776948255;
	bh=WCqVD6YRGkVlS61nC58ZQHPJoEDu23OMTFcYIc3KK7w=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=o9WkEKDY1+IjGA7KFzub4vgAD8r4TOVboRhyxRljZfT4Cn2GsJoqg7WNN9vIhuVXt
	 H2Yf3Nkj2Wsq271fqrX1wrAYYyvoFn2o8S7p9TnmsSNSUq3XOrQ1dDRVtCcJFMQy3B
	 QohTj61p/B/cM3PvJR+/k9oHkGlU7NBEhQoZ8ymM=
From: Naman Jain <namjain@linux.microsoft.com>
To: "K . Y . Srinivasan" <kys@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	Wei Liu <wei.liu@kernel.org>,
	Dexuan Cui <decui@microsoft.com>,
	Long Li <longli@microsoft.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Thomas Gleixner <tglx@kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org,
	"H . Peter Anvin" <hpa@zytor.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Paul Walmsley <pjw@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Alexandre Ghiti <alex@ghiti.fr>,
	Michael Kelley <mhklinux@outlook.com>
Cc: Marc Zyngier <maz@kernel.org>,
	Timothy Hayes <timothy.hayes@arm.com>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Sascha Bischoff <sascha.bischoff@arm.com>,
	mrigendrachaubey <mrigendra.chaubey@gmail.com>,
	Naman Jain <namjain@linux.microsoft.com>,
	linux-hyperv@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	linux-arch@vger.kernel.org,
	linux-riscv@lists.infradead.org,
	vdso@mailbox.org,
	ssengar@linux.microsoft.com
Subject: [PATCH v2 14/15] Drivers: hv: Add 4K page dependency in MSHV_VTL
Date: Thu, 23 Apr 2026 12:42:04 +0000
Message-ID: <20260423124206.2410879-15-namjain@linux.microsoft.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260423124206.2410879-1-namjain@linux.microsoft.com>
References: <20260423124206.2410879-1-namjain@linux.microsoft.com>
Precedence: bulk
X-Mailing-List: linux-arch@vger.kernel.org
List-Id: <linux-arch.vger.kernel.org>
List-Subscribe: <mailto:linux-arch+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-arch+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Add a dependency on 4K page size in Kconfig of MSHV_VTL
to support any assumptions that may be present in the code.
x86 anyways supports 4K page size only, and for arm64, higher
page size support is not validated. Remove this dependency as
and when this feature is supported.

Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
---
 drivers/hv/Kconfig | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
index 7937ac0cbd0f..115821cc535c 100644
--- a/drivers/hv/Kconfig
+++ b/drivers/hv/Kconfig
@@ -96,6 +96,11 @@ config MSHV_VTL
 	# MTRRs are controlled by VTL0, and are not specific to individual VTLs.
 	# Therefore, do not attempt to access or modify MTRRs here.
 	depends on !MTRR
+	# The hypervisor interface operates on 4k pages. Enforcing it here
+	# simplifies many assumptions in the mshv_vtl code.
+	# VTL0 VMs can still support higher page size in ARM64 and is not limited
+	# by this setting.
+	depends on PAGE_SIZE_4KB
 	select CPUMASK_OFFSTACK
 	select VIRT_XFER_TO_GUEST_WORK
 	default n
-- 
2.43.0


From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 624EE1D6DB5;
	Thu, 23 Apr 2026 12:44:47 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=13.77.154.182
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1776948288; cv=none; b=SgWkhGTs4tZsAbcVc5Me3K9wKZS4bUaPA6U+BNc1hmcI5+ieBs9nDSYNDZJE0GFgZPDv9r9mJ0mkeZ3kRJLGCAxHpy0gbcnEPZlB0SlN9MNx/h55kF7SgCy+4VLTtzzJ5xStvHO9oFfrqvgoSa/6oz8DFPvKJsBk7nddgwuPLg0=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1776948288; c=relaxed/simple;
	bh=UJFdtsv+xUTxCdD902MCvqyrQbINo6D6Gc7EY3d+HRk=;
	h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
	 MIME-Version; b=Joa8IXeLKJ9I9aR+8LmKzOE3ZhLOp9DkOcPp+TEEOAPyD7nUO68QQQkSmId7BfCbsaMz/jOYoloZA7qjgwb3lL3YTGzF43BqvJnezxF40NOcvKzdroQ2SySmJp4alc2VPuFHQdOezrLQnKYwTGwqkdW62VMyrA0oSzc+Ub16K6Q=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com; spf=pass smtp.mailfrom=linux.microsoft.com; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b=TZwi8EF3; arc=none smtp.client-ip=13.77.154.182
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="TZwi8EF3"
Received: from CPC-namja-026ON.redmond.corp.microsoft.com (unknown [4.213.232.18])
	by linux.microsoft.com (Postfix) with ESMTPSA id 070C020B7185;
	Thu, 23 Apr 2026 05:44:29 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 070C020B7185
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1776948277;
	bh=R8uasiKJJqB0UypVXrQ/4MfR+9wKG2jPGAjkmO/egns=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=TZwi8EF3KFtKojnKql1YiP0AxnEytUmxPRo3tGXKd7KO+PMWGFiqKd6B2H0MhaQYM
	 YGXvBpEzByzP3E7BIOFqlkvqdMymumuRVtYgejafE2X8vrjrWmk57c9IhZ4qd5vNc+
	 GpA+cyWtUSQ/hPB3EXOg0C2B5OBUflbRhUenyRL4=
From: Naman Jain <namjain@linux.microsoft.com>
To: "K . Y . Srinivasan" <kys@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	Wei Liu <wei.liu@kernel.org>,
	Dexuan Cui <decui@microsoft.com>,
	Long Li <longli@microsoft.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Thomas Gleixner <tglx@kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org,
	"H . Peter Anvin" <hpa@zytor.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Paul Walmsley <pjw@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Alexandre Ghiti <alex@ghiti.fr>,
	Michael Kelley <mhklinux@outlook.com>
Cc: Marc Zyngier <maz@kernel.org>,
	Timothy Hayes <timothy.hayes@arm.com>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Sascha Bischoff <sascha.bischoff@arm.com>,
	mrigendrachaubey <mrigendra.chaubey@gmail.com>,
	Naman Jain <namjain@linux.microsoft.com>,
	linux-hyperv@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	linux-arch@vger.kernel.org,
	linux-riscv@lists.infradead.org,
	vdso@mailbox.org,
	ssengar@linux.microsoft.com
Subject: [PATCH v2 15/15] Drivers: hv: Add ARM64 support for MSHV_VTL in Kconfig
Date: Thu, 23 Apr 2026 12:42:05 +0000
Message-ID: <20260423124206.2410879-16-namjain@linux.microsoft.com>
X-Mailer: git-send-email 2.43.0
In-Reply-To: <20260423124206.2410879-1-namjain@linux.microsoft.com>
References: <20260423124206.2410879-1-namjain@linux.microsoft.com>
Precedence: bulk
X-Mailing-List: linux-arch@vger.kernel.org
List-Id: <linux-arch.vger.kernel.org>
List-Subscribe: <mailto:linux-arch+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-arch+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Enable ARM64 support in MSHV_VTL Kconfig now that all the necessary
support is present.

Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Reviewed-by: Roman Kisel <vdso@mailbox.org>
Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
---
 drivers/hv/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
index 115821cc535c..0bec3bc81a1a 100644
--- a/drivers/hv/Kconfig
+++ b/drivers/hv/Kconfig
@@ -87,7 +87,7 @@ config MSHV_ROOT
 
 config MSHV_VTL
 	tristate "Microsoft Hyper-V VTL driver"
-	depends on X86_64 && HYPERV_VTL_MODE
+	depends on (X86_64 || ARM64) && HYPERV_VTL_MODE
 	depends on HYPERV_VMBUS
 	# Mapping VTL0 memory to a userspace process in VTL2 is supported in OpenHCL.
 	# VTL2 for OpenHCL makes use of Huge Pages to improve performance on VMs,
-- 
2.43.0


From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id E40DD126C03;
	Thu, 23 Apr 2026 13:56:56 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1776952618; cv=none; b=g2RwOgQHWmUquVH4j9UlCtsPEdlSRYnd8nvLlDJt10LWoF9pGQmEAkinIjj/aAeC8a/hHBPI3llgQDkUTPWMlIm5OJzRdA4W36EaCC95uadh8bCr7w1e4cTEBrvPl0xZFXxfUByFjrZaJ3KzrQyWOAIvPhOz4Y8WitH3nfCe4j4=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1776952618; c=relaxed/simple;
	bh=6LfUy7I1VMNamQxWSciFQf6jdTAWYyv2Ia/cLP4B6X4=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=Rrvd/ZsZ4Im2AvCquMJA5CyBhywuLZ5I12b7DbJxVKKYvg4SJ4GOtYIEFyxJsxZ9bJnPCNlVSwJKKx5YeqMofcqMLQetEdf8JE7oFu8JlZHzVOtsGbu06edTeoCxBWwCZyv3Iv2KTDvGF8i/M310WR7bJ4SnjMbHh8Jo5uA0XAs=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=rBflTTAD; arc=none smtp.client-ip=217.140.110.172
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="rBflTTAD"
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
	by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 74CAB1BF7;
	Thu, 23 Apr 2026 06:56:50 -0700 (PDT)
Received: from J2N7QTR9R3.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14])
	by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id EAD5A3F641;
	Thu, 23 Apr 2026 06:56:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss;
	t=1776952615; bh=6LfUy7I1VMNamQxWSciFQf6jdTAWYyv2Ia/cLP4B6X4=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=rBflTTAD1Nx18ZIKce0DB9rGA61RgIzbWsTnQaMaNQevsXWb4YJJhzTVK+mi1B9WL
	 d2rQAEWHeYRvbN0Ht4CDh4jY2GpWlPqjntX33LzvDdGBDahRo8Y4EieF31A8JyVGut
	 4w7a0aEAoP5zijGVD9Bbjnm6gchimq3SzV4phl5Q=
Date: Thu, 23 Apr 2026 14:56:47 +0100
From: Mark Rutland <mark.rutland@arm.com>
To: Naman Jain <namjain@linux.microsoft.com>
Cc: "K . Y . Srinivasan" <kys@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	Wei Liu <wei.liu@kernel.org>, Dexuan Cui <decui@microsoft.com>,
	Long Li <longli@microsoft.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Thomas Gleixner <tglx@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org,
	"H . Peter Anvin" <hpa@zytor.com>, Arnd Bergmann <arnd@arndb.de>,
	Paul Walmsley <pjw@kernel.org>, Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>, Alexandre Ghiti <alex@ghiti.fr>,
	Michael Kelley <mhklinux@outlook.com>,
	Marc Zyngier <maz@kernel.org>,
	Timothy Hayes <timothy.hayes@arm.com>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Sascha Bischoff <sascha.bischoff@arm.com>,
	mrigendrachaubey <mrigendra.chaubey@gmail.com>,
	linux-hyperv@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
	linux-riscv@lists.infradead.org, vdso@mailbox.org,
	ssengar@linux.microsoft.com
Subject: Re: [PATCH v2 07/15] arm64: hyperv: Add support for
 mshv_vtl_return_call
Message-ID: <aeolHwXHFH4AnX_n@J2N7QTR9R3.cambridge.arm.com>
References: <20260423124206.2410879-1-namjain@linux.microsoft.com>
 <20260423124206.2410879-8-namjain@linux.microsoft.com>
Precedence: bulk
X-Mailing-List: linux-arch@vger.kernel.org
List-Id: <linux-arch.vger.kernel.org>
List-Subscribe: <mailto:linux-arch+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-arch+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20260423124206.2410879-8-namjain@linux.microsoft.com>

On Thu, Apr 23, 2026 at 12:41:57PM +0000, Naman Jain wrote:
> Add the arm64 variant of mshv_vtl_return_call() to support the MSHV_VTL
> driver on arm64. This function enables the transition between Virtual
> Trust Levels (VTLs) in MSHV_VTL when the kernel acts as a paravisor.
> 
> Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
> Reviewed-by: Roman Kisel <vdso@mailbox.org>
> Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
> ---
>  arch/arm64/hyperv/Makefile        |   1 +
>  arch/arm64/hyperv/hv_vtl.c        | 158 ++++++++++++++++++++++++++++++
>  arch/arm64/include/asm/mshyperv.h |  13 +++
>  arch/x86/include/asm/mshyperv.h   |   2 -
>  drivers/hv/mshv_vtl.h             |   3 +
>  include/asm-generic/mshyperv.h    |   2 +
>  6 files changed, 177 insertions(+), 2 deletions(-)
>  create mode 100644 arch/arm64/hyperv/hv_vtl.c
> 
> diff --git a/arch/arm64/hyperv/Makefile b/arch/arm64/hyperv/Makefile
> index 87c31c001da9..9701a837a6e1 100644
> --- a/arch/arm64/hyperv/Makefile
> +++ b/arch/arm64/hyperv/Makefile
> @@ -1,2 +1,3 @@
>  # SPDX-License-Identifier: GPL-2.0
>  obj-y		:= hv_core.o mshyperv.o
> +obj-$(CONFIG_HYPERV_VTL_MODE)	+= hv_vtl.o
> diff --git a/arch/arm64/hyperv/hv_vtl.c b/arch/arm64/hyperv/hv_vtl.c
> new file mode 100644
> index 000000000000..59cbeb74e7b9
> --- /dev/null
> +++ b/arch/arm64/hyperv/hv_vtl.c
> @@ -0,0 +1,158 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2026, Microsoft, Inc.
> + *
> + * Authors:
> + *     Roman Kisel <romank@linux.microsoft.com>
> + *     Naman Jain <namjain@linux.microsoft.com>
> + */
> +
> +#include <asm/mshyperv.h>
> +#include <asm/neon.h>
> +#include <linux/export.h>
> +
> +void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0)
> +{
> +	struct user_fpsimd_state fpsimd_state;
> +	u64 base_ptr = (u64)vtl0->x;
> +
> +	/*
> +	 * Obtain the CPU FPSIMD registers for VTL context switch.
> +	 * This saves the current task's FP/NEON state and allows us to
> +	 * safely load VTL0's FP/NEON context for the hypercall.
> +	 */
> +	kernel_neon_begin(&fpsimd_state);
> +
> +	/*
> +	 * VTL switch for ARM64 platform - managing VTL0's CPU context.
> +	 * We explicitly use the stack to save the base pointer, and use x16
> +	 * as our working register for accessing the context structure.
> +	 *
> +	 * Register Handling:
> +	 * - X0-X17: Saved/restored (general-purpose, shared for VTL communication)
> +	 * - X18: NOT touched - hypervisor-managed per-VTL (platform register)
> +	 * - X19-X30: Saved/restored (part of VTL0's execution context)
> +	 * - Q0-Q31: Saved/restored (128-bit NEON/floating-point registers, shared)
> +	 * - SP: Not in structure, hypervisor-managed per-VTL
> +	 *
> +	 * X29 (FP) and X30 (LR) are in the structure and must be saved/restored
> +	 * as part of VTL0's complete execution state.
> +	 */
> +	asm __volatile__ (
> +		/* Save base pointer to stack explicitly, then load into x16 */
> +		"str %0, [sp, #-16]!\n\t"     /* Push base pointer onto stack */
> +		"mov x16, %0\n\t"             /* Load base pointer into x16 */
> +		/* Volatile registers (Windows ARM64 ABI: x0-x17) */
> +		"ldp x0, x1, [x16]\n\t"
> +		"ldp x2, x3, [x16, #(2*8)]\n\t"
> +		"ldp x4, x5, [x16, #(4*8)]\n\t"
> +		"ldp x6, x7, [x16, #(6*8)]\n\t"
> +		"ldp x8, x9, [x16, #(8*8)]\n\t"
> +		"ldp x10, x11, [x16, #(10*8)]\n\t"
> +		"ldp x12, x13, [x16, #(12*8)]\n\t"
> +		"ldp x14, x15, [x16, #(14*8)]\n\t"
> +		/* x16 will be loaded last, after saving base pointer */
> +		"ldr x17, [x16, #(17*8)]\n\t"
> +		/* x18 is hypervisor-managed per-VTL - DO NOT LOAD */
> +
> +		/* General-purpose registers: x19-x30 */
> +		"ldp x19, x20, [x16, #(19*8)]\n\t"
> +		"ldp x21, x22, [x16, #(21*8)]\n\t"
> +		"ldp x23, x24, [x16, #(23*8)]\n\t"
> +		"ldp x25, x26, [x16, #(25*8)]\n\t"
> +		"ldp x27, x28, [x16, #(27*8)]\n\t"
> +
> +		/* Frame pointer and link register */
> +		"ldp x29, x30, [x16, #(29*8)]\n\t"
> +
> +		/* Shared NEON/FP registers: Q0-Q31 (128-bit) */
> +		"ldp q0, q1, [x16, #(32*8)]\n\t"
> +		"ldp q2, q3, [x16, #(32*8 + 2*16)]\n\t"
> +		"ldp q4, q5, [x16, #(32*8 + 4*16)]\n\t"
> +		"ldp q6, q7, [x16, #(32*8 + 6*16)]\n\t"
> +		"ldp q8, q9, [x16, #(32*8 + 8*16)]\n\t"
> +		"ldp q10, q11, [x16, #(32*8 + 10*16)]\n\t"
> +		"ldp q12, q13, [x16, #(32*8 + 12*16)]\n\t"
> +		"ldp q14, q15, [x16, #(32*8 + 14*16)]\n\t"
> +		"ldp q16, q17, [x16, #(32*8 + 16*16)]\n\t"
> +		"ldp q18, q19, [x16, #(32*8 + 18*16)]\n\t"
> +		"ldp q20, q21, [x16, #(32*8 + 20*16)]\n\t"
> +		"ldp q22, q23, [x16, #(32*8 + 22*16)]\n\t"
> +		"ldp q24, q25, [x16, #(32*8 + 24*16)]\n\t"
> +		"ldp q26, q27, [x16, #(32*8 + 26*16)]\n\t"
> +		"ldp q28, q29, [x16, #(32*8 + 28*16)]\n\t"
> +		"ldp q30, q31, [x16, #(32*8 + 30*16)]\n\t"
> +
> +		/* Now load x16 itself */
> +		"ldr x16, [x16, #(16*8)]\n\t"
> +
> +		/* Return to the lower VTL */
> +		"hvc #3\n\t"

NAK to this.

* This is a non-SMCCC hypercall, which we have NAK'd in general in the
  past for various reasons that I am not going to rehash here.

* It's not clear how this is going to be extended with necessary
  architecture state in future (e.g. SVE, SME). This is not
  future-proof, and I don't believe this is maintainable.

* This breaks general requirements for reliable stacktracing by
  clobbering state (e.g. x29) that we depend upon being valid AT ALL
  TIMES outside of entry code.

* IMO, if this needs to be saved/restored, that should happen in
  whatever you are calling.

Mark.

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 12F5F275AFB;
	Thu, 23 Apr 2026 14:00:37 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1776952838; cv=none; b=B/bFiHklRIlY7s6+hNaB3uOjO382qvZJ5A170VhekDZcIcqHNLTMxY0Cgi2HQzOJAnfyKdnh2x1B9GjD4Ci+QD0zmL1rEYbR5RrivX8Z5bAUda/LA+bnir5YHyU0mKLVk6TSz5aItJv4VpjKN0WOOzm+8Cj0b31cDz46r6rVkUc=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1776952838; c=relaxed/simple;
	bh=mVrK0zXCEdJ6a40kh14ulfHCdH3uQpXGB2DGyceVQ9M=;
	h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References:
	 MIME-Version:Content-Type; b=qXSrJRhf/9aKl3v2Oh+9s5Y+7m44dk/3Vt+hZmJ3TNudbJ0dFa+0kKJnlNIeJ0xwIuRkNKr1Kw6TRe7SQ4AvGDvhSl7hhqENNlY4mZwnHmBPT8IB2RddyMZGR/exAFiNiTETouyAaZWNIrRm8RiP0tUD7bQTYCd06VlzPeSUL8I=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Na8CI7bw; arc=none smtp.client-ip=10.30.226.201
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Na8CI7bw"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7C102C2BCB3;
	Thu, 23 Apr 2026 14:00:37 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1776952837;
	bh=mVrK0zXCEdJ6a40kh14ulfHCdH3uQpXGB2DGyceVQ9M=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=Na8CI7bwOFFciWF152SK6VpvgW/0uJ9C/ab85EokcYjuHus/X7p5kdg3sgcvfaoT8
	 qHtp6cimBCaiagvbYXjw2BModFBlKGaR7PB9ARWc01gap3WEdVSBIm+os8k2xnkOPu
	 xlBzNX8FRqwIEDKREsGsUViWZfjeYfjGIMrkbuvIEutscXEFDBVc4YlhdVFs9SfT8B
	 WrL3lV26hSmkoRSlYMtK1MQpod6CFooqGC4+WUs8b+cH8X9CS2SdUqsOGlbKAd/AAs
	 SM789kC1D0hTDtVBhRTd6CAMJHrAPGcFthq786V4/J2nP4PQLEQE+epCfoxx3mKPcr
	 Vco1wbe+h2pvQ==
Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org)
	by disco-boy.misterjones.org with esmtpsa  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.98.2)
	(envelope-from <maz@kernel.org>)
	id 1wFuba-0000000E4rW-3VD2;
	Thu, 23 Apr 2026 14:00:34 +0000
Date: Thu, 23 Apr 2026 15:00:34 +0100
Message-ID: <864il122v1.wl-maz@kernel.org>
From: Marc Zyngier <maz@kernel.org>
To: Naman Jain <namjain@linux.microsoft.com>
Cc: "K . Y . Srinivasan" <kys@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	Wei Liu <wei.liu@kernel.org>,
	Dexuan Cui <decui@microsoft.com>,
	Long Li <longli@microsoft.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Thomas Gleixner <tglx@kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org,
	"H . Peter Anvin" <hpa@zytor.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Paul Walmsley <pjw@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Alexandre Ghiti <alex@ghiti.fr>,
	Michael Kelley <mhklinux@outlook.com>,
	Timothy Hayes <timothy.hayes@arm.com>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Sascha Bischoff <sascha.bischoff@arm.com>,
	mrigendrachaubey <mrigendra.chaubey@gmail.com>,
	linux-hyperv@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	linux-arch@vger.kernel.org,
	linux-riscv@lists.infradead.org,
	vdso@mailbox.org,
	ssengar@linux.microsoft.com
Subject: Re: [PATCH v2 07/15] arm64: hyperv: Add support for mshv_vtl_return_call
In-Reply-To: <20260423124206.2410879-8-namjain@linux.microsoft.com>
References: <20260423124206.2410879-1-namjain@linux.microsoft.com>
	<20260423124206.2410879-8-namjain@linux.microsoft.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue)
 FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1
 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO)
Precedence: bulk
X-Mailing-List: linux-arch@vger.kernel.org
List-Id: <linux-arch.vger.kernel.org>
List-Subscribe: <mailto:linux-arch+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-arch+unsubscribe@vger.kernel.org>
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
X-SA-Exim-Connect-IP: 185.219.108.64
X-SA-Exim-Rcpt-To: namjain@linux.microsoft.com, kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com, longli@microsoft.com, catalin.marinas@arm.com, will@kernel.org, tglx@kernel.org, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, arnd@arndb.de, pjw@kernel.org, palmer@dabbelt.com, aou@eecs.berkeley.edu, alex@ghiti.fr, mhklinux@outlook.com, timothy.hayes@arm.com, lpieralisi@kernel.org, sascha.bischoff@arm.com, mrigendra.chaubey@gmail.com, linux-hyperv@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-riscv@lists.infradead.org, vdso@mailbox.org, ssengar@linux.microsoft.com
X-SA-Exim-Mail-From: maz@kernel.org
X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false

On Thu, 23 Apr 2026 13:41:57 +0100,
Naman Jain <namjain@linux.microsoft.com> wrote:
> 
> Add the arm64 variant of mshv_vtl_return_call() to support the MSHV_VTL
> driver on arm64. This function enables the transition between Virtual
> Trust Levels (VTLs) in MSHV_VTL when the kernel acts as a paravisor.
> 
> Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
> Reviewed-by: Roman Kisel <vdso@mailbox.org>
> Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
> ---
>  arch/arm64/hyperv/Makefile        |   1 +
>  arch/arm64/hyperv/hv_vtl.c        | 158 ++++++++++++++++++++++++++++++
>  arch/arm64/include/asm/mshyperv.h |  13 +++
>  arch/x86/include/asm/mshyperv.h   |   2 -
>  drivers/hv/mshv_vtl.h             |   3 +
>  include/asm-generic/mshyperv.h    |   2 +
>  6 files changed, 177 insertions(+), 2 deletions(-)
>  create mode 100644 arch/arm64/hyperv/hv_vtl.c
> 
> diff --git a/arch/arm64/hyperv/Makefile b/arch/arm64/hyperv/Makefile
> index 87c31c001da9..9701a837a6e1 100644
> --- a/arch/arm64/hyperv/Makefile
> +++ b/arch/arm64/hyperv/Makefile
> @@ -1,2 +1,3 @@
>  # SPDX-License-Identifier: GPL-2.0
>  obj-y		:= hv_core.o mshyperv.o
> +obj-$(CONFIG_HYPERV_VTL_MODE)	+= hv_vtl.o
> diff --git a/arch/arm64/hyperv/hv_vtl.c b/arch/arm64/hyperv/hv_vtl.c
> new file mode 100644
> index 000000000000..59cbeb74e7b9
> --- /dev/null
> +++ b/arch/arm64/hyperv/hv_vtl.c
> @@ -0,0 +1,158 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2026, Microsoft, Inc.
> + *
> + * Authors:
> + *     Roman Kisel <romank@linux.microsoft.com>
> + *     Naman Jain <namjain@linux.microsoft.com>
> + */
> +
> +#include <asm/mshyperv.h>
> +#include <asm/neon.h>
> +#include <linux/export.h>
> +
> +void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0)
> +{
> +	struct user_fpsimd_state fpsimd_state;
> +	u64 base_ptr = (u64)vtl0->x;
> +
> +	/*
> +	 * Obtain the CPU FPSIMD registers for VTL context switch.
> +	 * This saves the current task's FP/NEON state and allows us to
> +	 * safely load VTL0's FP/NEON context for the hypercall.
> +	 */
> +	kernel_neon_begin(&fpsimd_state);
> +
> +	/*
> +	 * VTL switch for ARM64 platform - managing VTL0's CPU context.
> +	 * We explicitly use the stack to save the base pointer, and use x16
> +	 * as our working register for accessing the context structure.
> +	 *
> +	 * Register Handling:
> +	 * - X0-X17: Saved/restored (general-purpose, shared for VTL communication)
> +	 * - X18: NOT touched - hypervisor-managed per-VTL (platform register)
> +	 * - X19-X30: Saved/restored (part of VTL0's execution context)
> +	 * - Q0-Q31: Saved/restored (128-bit NEON/floating-point registers, shared)
> +	 * - SP: Not in structure, hypervisor-managed per-VTL
> +	 *
> +	 * X29 (FP) and X30 (LR) are in the structure and must be saved/restored
> +	 * as part of VTL0's complete execution state.
> +	 */
> +	asm __volatile__ (
> +		/* Save base pointer to stack explicitly, then load into x16 */
> +		"str %0, [sp, #-16]!\n\t"     /* Push base pointer onto stack */
> +		"mov x16, %0\n\t"             /* Load base pointer into x16 */
> +		/* Volatile registers (Windows ARM64 ABI: x0-x17) */
> +		"ldp x0, x1, [x16]\n\t"
> +		"ldp x2, x3, [x16, #(2*8)]\n\t"
> +		"ldp x4, x5, [x16, #(4*8)]\n\t"
> +		"ldp x6, x7, [x16, #(6*8)]\n\t"
> +		"ldp x8, x9, [x16, #(8*8)]\n\t"
> +		"ldp x10, x11, [x16, #(10*8)]\n\t"
> +		"ldp x12, x13, [x16, #(12*8)]\n\t"
> +		"ldp x14, x15, [x16, #(14*8)]\n\t"
> +		/* x16 will be loaded last, after saving base pointer */
> +		"ldr x17, [x16, #(17*8)]\n\t"
> +		/* x18 is hypervisor-managed per-VTL - DO NOT LOAD */

Wut? Does it mean the kernel is not free to use x18?

> +		/* General-purpose registers: x19-x30 */
> +		"ldp x19, x20, [x16, #(19*8)]\n\t"
> +		"ldp x21, x22, [x16, #(21*8)]\n\t"
> +		"ldp x23, x24, [x16, #(23*8)]\n\t"
> +		"ldp x25, x26, [x16, #(25*8)]\n\t"
> +		"ldp x27, x28, [x16, #(27*8)]\n\t"
> +
> +		/* Frame pointer and link register */
> +		"ldp x29, x30, [x16, #(29*8)]\n\t"
> +
> +		/* Shared NEON/FP registers: Q0-Q31 (128-bit) */
> +		"ldp q0, q1, [x16, #(32*8)]\n\t"
> +		"ldp q2, q3, [x16, #(32*8 + 2*16)]\n\t"
> +		"ldp q4, q5, [x16, #(32*8 + 4*16)]\n\t"
> +		"ldp q6, q7, [x16, #(32*8 + 6*16)]\n\t"
> +		"ldp q8, q9, [x16, #(32*8 + 8*16)]\n\t"
> +		"ldp q10, q11, [x16, #(32*8 + 10*16)]\n\t"
> +		"ldp q12, q13, [x16, #(32*8 + 12*16)]\n\t"
> +		"ldp q14, q15, [x16, #(32*8 + 14*16)]\n\t"
> +		"ldp q16, q17, [x16, #(32*8 + 16*16)]\n\t"
> +		"ldp q18, q19, [x16, #(32*8 + 18*16)]\n\t"
> +		"ldp q20, q21, [x16, #(32*8 + 20*16)]\n\t"
> +		"ldp q22, q23, [x16, #(32*8 + 22*16)]\n\t"
> +		"ldp q24, q25, [x16, #(32*8 + 24*16)]\n\t"
> +		"ldp q26, q27, [x16, #(32*8 + 26*16)]\n\t"
> +		"ldp q28, q29, [x16, #(32*8 + 28*16)]\n\t"
> +		"ldp q30, q31, [x16, #(32*8 + 30*16)]\n\t"
> +
> +		/* Now load x16 itself */
> +		"ldr x16, [x16, #(16*8)]\n\t"
> +
> +		/* Return to the lower VTL */
> +		"hvc #3\n\t"

No. Absolutely not. If you need to do context switching, do it in the
hypervisor. Entirely in the hypervisor. You don't even handle SVE, let
alone SME. How is that going to work?

And please use the SMCCC. Only that. Which mandates that the HVC
immediate is 0, 0 or zero.

	M.

-- 
Without deviation from the norm, progress is not possible.

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from PH8PR06CU001.outbound.protection.outlook.com (mail-westus3azolkn19012038.outbound.protection.outlook.com [52.103.23.38])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9C8BF40DFA5;
	Mon, 27 Apr 2026 05:37:33 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.103.23.38
ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1777268255; cv=fail; b=I7DLflqferPXwVMtkZBHhP8NBGJl5F5gPgYU87DP8jtWOCYBPWgs29HVHMfr9H7LCAceHA/qd13Iy4EC7H9VhckG9eaHAfraxb96la7KAEIxHtXLmAjWkVKrSSho9jVB65RY2g58YEY0lzlyghn3tkIaP/m1KGXEpxLgWbYgda8=
ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1777268255; c=relaxed/simple;
	bh=AIWfjjrebcjYxz8V1L4xyEn4t6nRk6Bb+dkkroUXxVU=;
	h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:
	 Content-Type:MIME-Version; b=BwjgW+o5QeLo0fbW+UFp+eVz5UFxFPu+Wkr2WjRgNhsG9WLV+edG9kkFIxulMdiavswsKTVHMGPMUE9uf/UM2Prn6mt7hsD85i3wE7FeCx8h3coWKWtYlH3aDnKPLCX/XiDij8oSKII/FZb9hyz2E4Rwbas55tx9rH8tDpkQKKY=
ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=outlook.com; spf=pass smtp.mailfrom=outlook.com; dkim=pass (2048-bit key) header.d=outlook.com header.i=@outlook.com header.b=knJ1HSW8; arc=fail smtp.client-ip=52.103.23.38
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=outlook.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=outlook.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=outlook.com header.i=@outlook.com header.b="knJ1HSW8"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=u4+cAUuRnqVLXpZWS6koVmua4G09WXiQkdq5FKTRb8DrFwdEiZSffWINbZHE+buBGZFRtb9x8pIdaof3eKKQ4ncS9IpcJANkon0csmcj7udx1guCqqumel1Yc5Q8O/U5hobNwOMCPIUKrQNMyzipNHshIsZLqw1IxuDBqfMMSpa5InJtijNEgoil1hinaBuw5vPByNt5GiuH2nVqjZtW1UqLOrxuXw5RRsbRpVFl/Li/OLCkcvTwVfM/52J6Syb/3hBykD/P3Kr/4CZr+8ch8TbrwVPD0CIOB5vUhL/CynhCFxL4kjqCOFN9UOPfgmDs5YmTnWYbnnhvzG3JWMxo8g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=tdEyUmHqpcPNEEz4G6lRZEBsdfRU7rwhcOk1yMh9qnU=;
 b=gtjwSdQVlZaB2LXdjXS/Znk/ccastvAP3TccPNXRAfM7nXVpLMl9kc9D1YVGLXvzRFQqWeSfUfnvLRPLZq92d5mbHooJIvQ+5HhFwK7ywaFWOnc3ff2nicrxU6toRCibjKptfcTEeU1pLjzfI8gx4bNXDK4XxkiglBuSAZD8sA+SDMJL+fA23e1/8qlxDl6gjxJCA2zf127nWr0k2G+jbMJlOezg4WiKKaAahwQ696R6EbWKPZE6zsvPZv6RQ9Svt0VrmXG3Nd71eDv751V78xM3Xy2b9hzR1BpSRHbwIE24x5heBYFqGr/YXfdcolz9wpTg4k+N4465KGl/vgKo7g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=tdEyUmHqpcPNEEz4G6lRZEBsdfRU7rwhcOk1yMh9qnU=;
 b=knJ1HSW8mjik6xucWxKpikH/qkCVGS883EdUt+sAQzoVAqFxInGiF2g+iPyMbN9Klw1iwIDWBuE502aFxkBM96JJWHAQwwATUR69YgMiFUyy0U6sbXc/mJYAeMQMYVaC6kBl6Pjhmjw+0CS7Uq0yQ3fmrhVnnMDkLkX+QU8FqUjb/ahrHf7hx0NYfvKrEhIBb/CbA72bRogkLOz3ta2H/BOoPWOtRuEvx9QYpKtHWCNNQYd9VIOfsxlM0MugNj7IjpHp0yDvfBTKGDmBWGsLAnyWCt8CWjM7ysh4zZfeUOdsr0e5FU9ENv96JnYrijZ6jamiH45cJLcEbNaZdkLc/g==
Received: from SN6PR02MB4157.namprd02.prod.outlook.com (2603:10b6:805:33::23)
 by CO6PR02MB7809.namprd02.prod.outlook.com (2603:10b6:303:a2::22) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9846.26; Mon, 27 Apr
 2026 05:37:29 +0000
Received: from SN6PR02MB4157.namprd02.prod.outlook.com
 ([fe80::900:1ccf:2b1e:52b6]) by SN6PR02MB4157.namprd02.prod.outlook.com
 ([fe80::900:1ccf:2b1e:52b6%6]) with mapi id 15.20.9846.025; Mon, 27 Apr 2026
 05:37:29 +0000
From: Michael Kelley <mhklinux@outlook.com>
To: Naman Jain <namjain@linux.microsoft.com>, "K . Y . Srinivasan"
	<kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu
	<wei.liu@kernel.org>, Dexuan Cui <decui@microsoft.com>, Long Li
	<longli@microsoft.com>, Catalin Marinas <catalin.marinas@arm.com>, Will
 Deacon <will@kernel.org>, Thomas Gleixner <tglx@kernel.org>, Ingo Molnar
	<mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, Dave Hansen
	<dave.hansen@linux.intel.com>, "x86@kernel.org" <x86@kernel.org>, "H . Peter
 Anvin" <hpa@zytor.com>, Arnd Bergmann <arnd@arndb.de>, Paul Walmsley
	<pjw@kernel.org>, Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou
	<aou@eecs.berkeley.edu>, Alexandre Ghiti <alex@ghiti.fr>, Michael Kelley
	<mhklinux@outlook.com>
CC: Marc Zyngier <maz@kernel.org>, Timothy Hayes <timothy.hayes@arm.com>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>, Sascha Bischoff
	<sascha.bischoff@arm.com>, mrigendrachaubey <mrigendra.chaubey@gmail.com>,
	"linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>, "linux-kernel@vger.kernel.org"
	<linux-kernel@vger.kernel.org>, "linux-arch@vger.kernel.org"
	<linux-arch@vger.kernel.org>, "linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>, "vdso@mailbox.org" <vdso@mailbox.org>,
	"ssengar@linux.microsoft.com" <ssengar@linux.microsoft.com>
Subject: RE: [PATCH v2 02/15] Drivers: hv: Move hv_vp_assist_page to common
 files
Thread-Topic: [PATCH v2 02/15] Drivers: hv: Move hv_vp_assist_page to common
 files
Thread-Index: AQHc0x6sH7YGHCQdqUepmn1fh9hlT7XyaZnA
Date: Mon, 27 Apr 2026 05:37:28 +0000
Message-ID:
 <SN6PR02MB4157BEAF5480D931C3756B7DD4362@SN6PR02MB4157.namprd02.prod.outlook.com>
References: <20260423124206.2410879-1-namjain@linux.microsoft.com>
 <20260423124206.2410879-3-namjain@linux.microsoft.com>
In-Reply-To: <20260423124206.2410879-3-namjain@linux.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: SN6PR02MB4157:EE_|CO6PR02MB7809:EE_
x-ms-office365-filtering-correlation-id: f9428a7f-2245-44f4-eac2-08dea41f122a
x-microsoft-antispam:
 BCL:0;ARA:14566002|51005399006|55001999006|37011999003|13091999003|19101099003|461199028|41001999006|31061999003|19110799012|15080799012|8062599012|8060799015|19061999003|40105399003|440099028|3412199025|102099032|12091999003|1710799026;
x-microsoft-antispam-message-info:
 =?us-ascii?Q?WBAgu0oJL9dUswrLeppJfhN3Gg9PLbTPuIc6UtVM/SMqTngUWtcVwo1WcbDO?=
 =?us-ascii?Q?WxsuLIfTjDk+ToWfxgghxComzGtnUWKxDA8IeuYvoYOMYcgNpCBfCPfAfAwL?=
 =?us-ascii?Q?cp5VD8NAVDolFYeIoLh9WOSkB37tSo0VMNsWcewvdNSjHMCXtmFQq8oPFGqp?=
 =?us-ascii?Q?66PjG0WS8zaaRiTuvRWl9rbQkO4ZwfBlKEWlHBjfJxTwM3/Wtv6AlV656TIw?=
 =?us-ascii?Q?BMpU6DmMen/LnONocI84DkdB9wyz3IW15PXrtrmxZtJFsUyZL8PMOaUUCZkd?=
 =?us-ascii?Q?x1auOkIer2d7Gy4eblfH9dsVX2HWOpX4B4wc17PKXLwk3bwiDT+nEkDk+Vfq?=
 =?us-ascii?Q?180cBpHFhyl1vW1Zv69FyfNNWRQxXcDjW3iqFCypDljzPM4ELarAmxkAxHPC?=
 =?us-ascii?Q?KM2RaxgacsoyroV9WgrrYv3vAdSMaiNPOy8nsSDKQBGJa6MVJ8eGTwoisoVO?=
 =?us-ascii?Q?HhsXRfLNGwd6dwTnNvbadj77p25HAWuGg5IV/CWkIm80dcW85c15oFpX5dTH?=
 =?us-ascii?Q?ErskhzrhKy9OgGxnRPMUYMcSBJuQ5qVXUkrpsHabeMHJePLD0AEAccYZp6Zi?=
 =?us-ascii?Q?NQG8UaCAJxNMkqNhUhWHB0gRgZ3PiPHd3duoZlXWRgX8zFfkEMzj/D2C6wsX?=
 =?us-ascii?Q?SH0RovmL1y1m2C9ta5LTl4uP63AczKB4Y2diR7zNABljgE7yhZlQajppIp/9?=
 =?us-ascii?Q?x6QQIoP+chZf0qNsjgYG63vl+wrXExpcsKKSYGHmH5VzDMLO5WANrJbZVMXS?=
 =?us-ascii?Q?fmkfbfTzi9LWFiqyJaoTJCbFqnrGi6DimqJGH9JZumwiLtYss98yj3axJ8au?=
 =?us-ascii?Q?34fx+HGeZ9F8G7h1TXkQy4CXehxR5fvXdjeV/1NU3kcIofnCikTFFhoA4ixS?=
 =?us-ascii?Q?IVAOiRibLW7R/884yv/gb8YMgYazCD2NeABSriXXBGig6AiUo5LbVR+qOo/6?=
 =?us-ascii?Q?NqqLasmlg2zkKhnUp+O7Gixi0toa8yVTMpc1MIiljxsXTaXET/ScKgcy4X+f?=
 =?us-ascii?Q?M4D4E2psg/0JlaSaVJckrLaXxJxmQc2e1Ayn7JC/vItWDEACaYQ2IEExvZ5s?=
 =?us-ascii?Q?2MR56y31SceRgcuj8SS2XqH2Cl+rVDGWyW3xwQbxcQQCnNmO4K3LfqaVXLFH?=
 =?us-ascii?Q?mKvMLzqZBO1QCA/nsYe8pP3NjPkZHa7boA=3D=3D?=
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?5Y4VJTtFNuVYygEs6OQI+oPJ9t0D9J/dLaLvdFeHGV1aKbzM2kYOJzFpGlEy?=
 =?us-ascii?Q?tIyOE690pvRXot+z7rwgE95ZCo7jWKHNYAVZ0NSUikybl4+eE4U3+5+ZllKa?=
 =?us-ascii?Q?OjN+6HRGIm1y/wTLEesG4lyyN+KeZeddBrNhS0WkBlyJZQmFmiztaf3Xb5kM?=
 =?us-ascii?Q?bca0zT+/ma2+LrDdWDVLwxJ6OWyVSHiDg2sqeqaqKuH2SnSLLvGhHd8peLnC?=
 =?us-ascii?Q?m6P6ogbfuCmk8tYle1JKP1dmtAiPTSQ9971k4efIuH41wgN0mVGhmw0YCckk?=
 =?us-ascii?Q?I2c/0deZoCGrFB596oSVzb+qZSvvEw+528VHignWDF3/FVIt4eCJZ8v+EoWE?=
 =?us-ascii?Q?4cIHRxH8PnQwHh4yeIYSweoGP9AKSDXzeGjaFZEACgM928Hw4z3iahNXfeQt?=
 =?us-ascii?Q?3NdumDbUqxY4CCEFXdV42WUfFQhZ2Hf8W4PKE4DR+ud6LGhp0HQGwYo9quqd?=
 =?us-ascii?Q?gMSWEK5BLfo+Y2UGZ6iLbPfLXllggH32bpDstm21IOPYRn+EobRsjgTutFnE?=
 =?us-ascii?Q?zBDx7GKWoMlEGQP6PHVc8IJGIOBX6MqMcH0hgqhq5BNF4NuulVJActcFxCrJ?=
 =?us-ascii?Q?4SWExEws7QLZLWrLwiihULXoBE6Pn7+CzW3PjmyS2IrCJ4/LSXNPluW1Ycz9?=
 =?us-ascii?Q?VXEfWT6t41KzIGIyj0MLpPVvKaprD9kMxRzs6hOTMvG/+wrL/7vkWzNwS6dh?=
 =?us-ascii?Q?oI46WwsJ1kERGa5FcXENV0IJnAte2jdba6EQnjUad2ZKkzJmepMrzAEjpHwD?=
 =?us-ascii?Q?NqCcEC2Hx3Nz39KLVOQoJJda//BfXZI0aTE3wEVjFgqlJEFA51mu+CbEiCV3?=
 =?us-ascii?Q?OrTzeTgid2sXfq+CZ0MNQArwQrAfvgZu1naXAH/R7ZmobCXqhbV1IuybLdhV?=
 =?us-ascii?Q?VGob//2nSmXvuDATcq+SWiTlM1wHhUX7PKysFXXjUdUUYUTigZfOtkfmUbkI?=
 =?us-ascii?Q?3bqYgAcqQ4z7L0J0fzMh9BLAf4HdD8Or1Pucvek6KRkvTP7yikTKT7pWKLdb?=
 =?us-ascii?Q?SOA1VvCZgoof7ZxV++lSvBeWGkvCrRs2w2U6N2uyU/YcsnI/gqeWvUmFsoze?=
 =?us-ascii?Q?SzjNfhn8eogYAWc0e1tKbeL2K9golSQLRtAKZh+zQCrRqkHYCpcSgU4RKmcK?=
 =?us-ascii?Q?pmDh0HjuaweMhI+o3D70aoxUGolk1oTTTBRyXV0Xkbx3EbpIntRko7Wza9p7?=
 =?us-ascii?Q?Fx2kQvEfJvuB3Z8dIFXH1l45UQ/aCHORVpJGfimBo5XknRdKJq6dmTvxZhEc?=
 =?us-ascii?Q?wlUhOC6e1Ribs+tAw1Svs0ePo3pfxR6j+su2QzlsNh9T9P666lOWNtNHkEUh?=
 =?us-ascii?Q?vWRMYUPICFtUQ/pAJ/3p+3uYBnAOs3TBfm8eG2JZ0l04m0i5kHEXjZqFlajT?=
 =?us-ascii?Q?aoHPei4=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
X-Mailing-List: linux-arch@vger.kernel.org
List-Id: <linux-arch.vger.kernel.org>
List-Subscribe: <mailto:linux-arch+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-arch+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SN6PR02MB4157.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: f9428a7f-2245-44f4-eac2-08dea41f122a
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2026 05:37:28.8796
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO6PR02MB7809

From: Naman Jain <namjain@linux.microsoft.com> Sent: Thursday, April 23, 20=
26 5:42 AM
>=20
> Move the logic to initialize and export hv_vp_assist_page from x86
> architecture code to Hyper-V common code to allow it to be used for
> upcoming arm64 support in MSHV_VTL driver.
> Note: This change also improves error handling - if VP assist page
> allocation fails, hyperv_init() now returns early instead of
> continuing with partial initialization.
>=20
> Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
> Reviewed-by: Roman Kisel <vdso@mailbox.org>
> Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
> ---
>  arch/x86/hyperv/hv_init.c       | 88 +-----------------------------
>  arch/x86/include/asm/mshyperv.h | 14 -----
>  drivers/hv/hv_common.c          | 94 ++++++++++++++++++++++++++++++++-
>  include/asm-generic/mshyperv.h  | 16 ++++++
>  include/hyperv/hvgdk_mini.h     |  6 ++-
>  5 files changed, 115 insertions(+), 103 deletions(-)
>=20
> diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
> index 323adc93f2dc..75a98b5e451b 100644
> --- a/arch/x86/hyperv/hv_init.c
> +++ b/arch/x86/hyperv/hv_init.c
> @@ -81,9 +81,6 @@ union hv_ghcb * __percpu *hv_ghcb_pg;
>  /* Storage to save the hypercall page temporarily for hibernation */
>  static void *hv_hypercall_pg_saved;
>=20
> -struct hv_vp_assist_page **hv_vp_assist_page;
> -EXPORT_SYMBOL_GPL(hv_vp_assist_page);
> -
>  static int hyperv_init_ghcb(void)
>  {
>  	u64 ghcb_gpa;
> @@ -117,59 +114,12 @@ static int hyperv_init_ghcb(void)
>=20
>  static int hv_cpu_init(unsigned int cpu)
>  {
> -	union hv_vp_assist_msr_contents msr =3D { 0 };
> -	struct hv_vp_assist_page **hvp;
>  	int ret;
>=20
>  	ret =3D hv_common_cpu_init(cpu);
>  	if (ret)
>  		return ret;
>=20
> -	if (!hv_vp_assist_page)
> -		return 0;
> -
> -	hvp =3D &hv_vp_assist_page[cpu];
> -	if (hv_root_partition()) {
> -		/*
> -		 * For root partition we get the hypervisor provided VP assist
> -		 * page, instead of allocating a new page.
> -		 */
> -		rdmsrq(HV_X64_MSR_VP_ASSIST_PAGE, msr.as_uint64);
> -		*hvp =3D memremap(msr.pfn << HV_X64_MSR_VP_ASSIST_PAGE_ADDRESS_SHIFT,
> -				PAGE_SIZE, MEMREMAP_WB);
> -	} else {
> -		/*
> -		 * The VP assist page is an "overlay" page (see Hyper-V TLFS's
> -		 * Section 5.2.1 "GPA Overlay Pages"). Here it must be zeroed
> -		 * out to make sure we always write the EOI MSR in
> -		 * hv_apic_eoi_write() *after* the EOI optimization is disabled
> -		 * in hv_cpu_die(), otherwise a CPU may not be stopped in the
> -		 * case of CPU offlining and the VM will hang.
> -		 */
> -		if (!*hvp) {
> -			*hvp =3D __vmalloc(PAGE_SIZE, GFP_KERNEL | __GFP_ZERO);
> -
> -			/*
> -			 * Hyper-V should never specify a VM that is a Confidential
> -			 * VM and also running in the root partition. Root partition
> -			 * is blocked to run in Confidential VM. So only decrypt assist
> -			 * page in non-root partition here.
> -			 */
> -			if (*hvp && !ms_hyperv.paravisor_present && hv_isolation_type_snp()) =
{
> -				WARN_ON_ONCE(set_memory_decrypted((unsigned long)(*hvp), 1));
> -				memset(*hvp, 0, PAGE_SIZE);
> -			}
> -		}
> -
> -		if (*hvp)
> -			msr.pfn =3D vmalloc_to_pfn(*hvp);
> -
> -	}
> -	if (!WARN_ON(!(*hvp))) {
> -		msr.enable =3D 1;
> -		wrmsrq(HV_X64_MSR_VP_ASSIST_PAGE, msr.as_uint64);
> -	}
> -
>  	/* Allow Hyper-V stimer vector to be injected from Hypervisor. */
>  	if (ms_hyperv.misc_features & HV_STIMER_DIRECT_MODE_AVAILABLE)
>  		apic_update_vector(cpu, HYPERV_STIMER0_VECTOR, true);
> @@ -286,23 +236,6 @@ static int hv_cpu_die(unsigned int cpu)
>=20
>  	hv_common_cpu_die(cpu);
>=20
> -	if (hv_vp_assist_page && hv_vp_assist_page[cpu]) {
> -		union hv_vp_assist_msr_contents msr =3D { 0 };
> -		if (hv_root_partition()) {
> -			/*
> -			 * For root partition the VP assist page is mapped to
> -			 * hypervisor provided page, and thus we unmap the
> -			 * page here and nullify it, so that in future we have
> -			 * correct page address mapped in hv_cpu_init.
> -			 */
> -			memunmap(hv_vp_assist_page[cpu]);
> -			hv_vp_assist_page[cpu] =3D NULL;
> -			rdmsrq(HV_X64_MSR_VP_ASSIST_PAGE, msr.as_uint64);
> -			msr.enable =3D 0;
> -		}
> -		wrmsrq(HV_X64_MSR_VP_ASSIST_PAGE, msr.as_uint64);
> -	}
> -
>  	if (hv_reenlightenment_cb =3D=3D NULL)
>  		return 0;
>=20
> @@ -460,21 +393,6 @@ void __init hyperv_init(void)
>  	if (hv_common_init())
>  		return;
>=20
> -	/*
> -	 * The VP assist page is useless to a TDX guest: the only use we
> -	 * would have for it is lazy EOI, which can not be used with TDX.
> -	 */
> -	if (hv_isolation_type_tdx())
> -		hv_vp_assist_page =3D NULL;
> -	else
> -		hv_vp_assist_page =3D kzalloc_objs(*hv_vp_assist_page, nr_cpu_ids);
> -	if (!hv_vp_assist_page) {
> -		ms_hyperv.hints &=3D ~HV_X64_ENLIGHTENED_VMCS_RECOMMENDED;
> -
> -		if (!hv_isolation_type_tdx())
> -			goto common_free;
> -	}
> -
>  	if (ms_hyperv.paravisor_present && hv_isolation_type_snp()) {
>  		/* Negotiate GHCB Version. */
>  		if (!hv_ghcb_negotiate_protocol())
> @@ -483,7 +401,7 @@ void __init hyperv_init(void)
>=20
>  		hv_ghcb_pg =3D alloc_percpu(union hv_ghcb *);
>  		if (!hv_ghcb_pg)
> -			goto free_vp_assist_page;
> +			goto free_ghcb_page;

Seems like this should be "goto common_free". The allocation of
hv_ghcb_pg has failed, so going to a label where hv_ghcb_pg is
freed seems redundant. It works since free_percpu() checks for
a NULL argument, but it's a bit unexpected since the common_free
label is already there.

>  	}
>=20
>  	cpuhp =3D cpuhp_setup_state(CPUHP_AP_HYPERV_ONLINE, "x86/hyperv_init:on=
line",
> @@ -613,10 +531,6 @@ void __init hyperv_init(void)
>  	cpuhp_remove_state(CPUHP_AP_HYPERV_ONLINE);
>  free_ghcb_page:
>  	free_percpu(hv_ghcb_pg);
> -free_vp_assist_page:
> -	kfree(hv_vp_assist_page);
> -	hv_vp_assist_page =3D NULL;
> -common_free:
>  	hv_common_free();
>  }
>=20
> diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyp=
erv.h
> index f64393e853ee..95b452387969 100644
> --- a/arch/x86/include/asm/mshyperv.h
> +++ b/arch/x86/include/asm/mshyperv.h
> @@ -155,16 +155,6 @@ static inline u64 hv_do_fast_hypercall16(u16 code, u=
64 input1, u64 input2)
>  	return _hv_do_fast_hypercall16(control, input1, input2);
>  }
>=20
> -extern struct hv_vp_assist_page **hv_vp_assist_page;
> -
> -static inline struct hv_vp_assist_page *hv_get_vp_assist_page(unsigned i=
nt cpu)
> -{
> -	if (!hv_vp_assist_page)
> -		return NULL;
> -
> -	return hv_vp_assist_page[cpu];
> -}
> -
>  void __init hyperv_init(void);
>  void hyperv_setup_mmu_ops(void);
>  void set_hv_tscchange_cb(void (*cb)(void));
> @@ -254,10 +244,6 @@ static inline void hyperv_setup_mmu_ops(void) {}
>  static inline void set_hv_tscchange_cb(void (*cb)(void)) {}
>  static inline void clear_hv_tscchange_cb(void) {}
>  static inline void hyperv_stop_tsc_emulation(void) {};
> -static inline struct hv_vp_assist_page *hv_get_vp_assist_page(unsigned i=
nt cpu)
> -{
> -	return NULL;
> -}
>  static inline int hyperv_flush_guest_mapping(u64 as) { return -1; }
>  static inline int hyperv_flush_guest_mapping_range(u64 as,
>  		hyperv_fill_flush_list_func fill_func, void *data)
> diff --git a/drivers/hv/hv_common.c b/drivers/hv/hv_common.c
> index 6b67ac616789..e8633bc51d56 100644
> --- a/drivers/hv/hv_common.c
> +++ b/drivers/hv/hv_common.c
> @@ -28,7 +28,11 @@
>  #include <linux/slab.h>
>  #include <linux/dma-map-ops.h>
>  #include <linux/set_memory.h>
> +#include <linux/vmalloc.h>
> +#include <linux/io.h>
> +#include <linux/hyperv.h>
>  #include <hyperv/hvhdk.h>
> +#include <hyperv/hvgdk.h>
>  #include <asm/mshyperv.h>
>=20
>  u64 hv_current_partition_id =3D HV_PARTITION_ID_SELF;
> @@ -78,6 +82,8 @@ static struct ctl_table_header *hv_ctl_table_hdr;
>  u8 * __percpu *hv_synic_eventring_tail;
>  EXPORT_SYMBOL_GPL(hv_synic_eventring_tail);
>=20
> +struct hv_vp_assist_page **hv_vp_assist_page;
> +EXPORT_SYMBOL_GPL(hv_vp_assist_page);
>  /*
>   * Hyper-V specific initialization and shutdown code that is
>   * common across all architectures.  Called from architecture
> @@ -92,6 +98,9 @@ void __init hv_common_free(void)
>  	if (ms_hyperv.misc_features & HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE)
>  		hv_kmsg_dump_unregister();
>=20
> +	kfree(hv_vp_assist_page);
> +	hv_vp_assist_page =3D NULL;
> +
>  	kfree(hv_vp_index);
>  	hv_vp_index =3D NULL;
>=20
> @@ -394,6 +403,23 @@ int __init hv_common_init(void)
>  	for (i =3D 0; i < nr_cpu_ids; i++)
>  		hv_vp_index[i] =3D VP_INVAL;
>=20
> +	/*
> +	 * The VP assist page is useless to a TDX guest: the only use we
> +	 * would have for it is lazy EOI, which can not be used with TDX.
> +	 */
> +	if (hv_isolation_type_tdx()) {
> +		hv_vp_assist_page =3D NULL;
> +#ifdef CONFIG_X86_64
> +		ms_hyperv.hints &=3D ~HV_X64_ENLIGHTENED_VMCS_RECOMMENDED;
> +#endif

I realize that this #ifdef went away for the reason I flagged in v1 of
this patch set, but it's back again for a different reason.

Let me suggest another approach. hv_common_init() is called from
both the x86/64 and arm64 hyperv_init() functions. Immediately after
the call to hv_common_init() in the x86/64 hyperv_init(), test
hv_vp_assist_page for NULL and clear
HV_X64_ENLIGHTENED_VMCS_RECOMMENDED if it is. No #ifdef is
needed, and x86/64 specific hackery stays under arch/x86 instead of
being in common code.

> +	} else {
> +		hv_vp_assist_page =3D kzalloc_objs(*hv_vp_assist_page, nr_cpu_ids);
> +		if (!hv_vp_assist_page) {
> +			hv_common_free();
> +			return -ENOMEM;
> +		}
> +	}
> +
>  	return 0;
>  }
>=20
> @@ -471,6 +497,8 @@ void __init ms_hyperv_late_init(void)
>=20
>  int hv_common_cpu_init(unsigned int cpu)
>  {
> +	union hv_vp_assist_msr_contents msr =3D { 0 };
> +	struct hv_vp_assist_page **hvp;
>  	void **inputarg, **outputarg;
>  	u8 **synic_eventring_tail;
>  	u64 msr_vp_index;
> @@ -539,7 +567,53 @@ int hv_common_cpu_init(unsigned int cpu)
>  						sizeof(u8), flags);
>  		/* No need to unwind any of the above on failure here */
>  		if (unlikely(!*synic_eventring_tail))
> -			ret =3D -ENOMEM;
> +			return -ENOMEM;
> +	}
> +
> +	if (!hv_vp_assist_page)
> +		return ret;
> +
> +	hvp =3D &hv_vp_assist_page[cpu];
> +	if (hv_root_partition()) {
> +		/*
> +		 * For root partition we get the hypervisor provided VP assist
> +		 * page, instead of allocating a new page.
> +		 */
> +		msr.as_uint64 =3D hv_get_msr(HV_MSR_VP_ASSIST_PAGE);
> +		*hvp =3D memremap(msr.pfn << HV_VP_ASSIST_PAGE_ADDRESS_SHIFT,
> +				HV_HYP_PAGE_SIZE, MEMREMAP_WB);
> +	} else {
> +		/*
> +		 * The VP assist page is an "overlay" page (see Hyper-V TLFS's
> +		 * Section 5.2.1 "GPA Overlay Pages"). Here it must be zeroed
> +		 * out to make sure that on x86/x64, we always write the EOI MSR in
> +		 * hv_apic_eoi_write() *after* the EOI optimization is disabled
> +		 * in hv_cpu_die(), otherwise a CPU may not be stopped in the
> +		 * case of CPU offlining and the VM will hang.
> +		 */
> +		if (!*hvp) {
> +			*hvp =3D __vmalloc(HV_HYP_PAGE_SIZE, flags | __GFP_ZERO);
> +
> +			/*
> +			 * Hyper-V should never specify a VM that is a Confidential
> +			 * VM and also running in the root partition. Root partition
> +			 * is blocked to run in Confidential VM. So only decrypt assist
> +			 * page in non-root partition here.
> +			 */
> +			if (*hvp &&
> +			    !ms_hyperv.paravisor_present &&
> +			    hv_isolation_type_snp()) {
> +				WARN_ON_ONCE(set_memory_decrypted((unsigned long)(*hvp), 1));
> +				memset(*hvp, 0, HV_HYP_PAGE_SIZE);
> +			}
> +		}
> +
> +		if (*hvp)
> +			msr.pfn =3D page_to_hvpfn(vmalloc_to_page(*hvp));

Your Patch 0 changelog mentions adding a comment about vmalloc_to_pfn(), wh=
ich
I didn't see anywhere. I'm not sure what that comment would say, so maybe i=
t
became unnecessary.

> +	}
> +	if (!WARN_ON(!(*hvp))) {
> +		msr.enable =3D 1;
> +		hv_set_msr(HV_MSR_VP_ASSIST_PAGE, msr.as_uint64);
>  	}
>=20
>  	return ret;
> @@ -566,6 +640,24 @@ int hv_common_cpu_die(unsigned int cpu)
>  		*synic_eventring_tail =3D NULL;
>  	}
>=20
> +	if (hv_vp_assist_page && hv_vp_assist_page[cpu]) {
> +		union hv_vp_assist_msr_contents msr =3D { 0 };
> +
> +		if (hv_root_partition()) {
> +			/*
> +			 * For root partition the VP assist page is mapped to
> +			 * hypervisor provided page, and thus we unmap the
> +			 * page here and nullify it, so that in future we have
> +			 * correct page address mapped in hv_cpu_init.
> +			 */
> +			memunmap(hv_vp_assist_page[cpu]);
> +			hv_vp_assist_page[cpu] =3D NULL;
> +			msr.as_uint64 =3D hv_get_msr(HV_MSR_VP_ASSIST_PAGE);
> +			msr.enable =3D 0;
> +		}
> +		hv_set_msr(HV_MSR_VP_ASSIST_PAGE, msr.as_uint64);
> +	}
> +
>  	return 0;
>  }
>=20
> diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyper=
v.h
> index d37b68238c97..2810aa05dc73 100644
> --- a/include/asm-generic/mshyperv.h
> +++ b/include/asm-generic/mshyperv.h
> @@ -25,6 +25,7 @@
>  #include <linux/nmi.h>
>  #include <asm/ptrace.h>
>  #include <hyperv/hvhdk.h>
> +#include <hyperv/hvgdk.h>
>=20
>  #define VTPM_BASE_ADDRESS 0xfed40000
>=20
> @@ -299,6 +300,16 @@ do { \
>  #define hv_status_debug(status, fmt, ...) \
>  	hv_status_printk(debug, status, fmt, ##__VA_ARGS__)
>=20
> +extern struct hv_vp_assist_page **hv_vp_assist_page;
> +
> +static inline struct hv_vp_assist_page *hv_get_vp_assist_page(unsigned i=
nt cpu)
> +{
> +	if (!hv_vp_assist_page)
> +		return NULL;
> +
> +	return hv_vp_assist_page[cpu];
> +}
> +
>  const char *hv_result_to_string(u64 hv_status);
>  int hv_result_to_errno(u64 status);
>  void hyperv_report_panic(struct pt_regs *regs, long err, bool in_die);
> @@ -327,6 +338,11 @@ static inline enum hv_isolation_type hv_get_isolatio=
n_type(void)
>  {
>  	return HV_ISOLATION_TYPE_NONE;
>  }
> +
> +static inline struct hv_vp_assist_page *hv_get_vp_assist_page(unsigned i=
nt cpu)
> +{
> +	return NULL;
> +}
>  #endif /* CONFIG_HYPERV */
>=20
>  #if IS_ENABLED(CONFIG_MSHV_ROOT)
> diff --git a/include/hyperv/hvgdk_mini.h b/include/hyperv/hvgdk_mini.h
> index 056ef7b6b360..c72d04cd5ae4 100644
> --- a/include/hyperv/hvgdk_mini.h
> +++ b/include/hyperv/hvgdk_mini.h
> @@ -149,6 +149,7 @@ struct hv_u128 {
>  #define HV_X64_MSR_VP_ASSIST_PAGE_ADDRESS_SHIFT	12

Can this X64 specific definition of the shift be eliminated entirely,
and a single common definition for x86/64 and arm64 be used?
As I understand it, the MSR layout is the same on both architectures.
The one gotcha is that kvm_hv_set_msr() would need to be updated.

HV_X64_MSR_VP_ASSIST_PAGE_ADDRESS_MASK defined below isn't
used anywhere, so it could go away too.  (The KVM selftest usage has
its own definition.)

I realize these are changes to a source code file that is derived from
Windows, and I'm not sure of the guidelines for such changes. So maybe
these suggestions have to be ignored ....

>  #define HV_X64_MSR_VP_ASSIST_PAGE_ADDRESS_MASK	\
>  		(~((1ull << HV_X64_MSR_VP_ASSIST_PAGE_ADDRESS_SHIFT) - 1))
> +#define HV_MSR_VP_ASSIST_PAGE              (HV_X64_MSR_VP_ASSIST_PAGE)

This is the correct file for this #define, but it should be placed down aro=
und
line 1148 or so with the other HV_MSR_* definitions in terms of HV_X64_MSR_=
*

>=20
>  /* Hyper-V Enlightened VMCS version mask in nested features CPUID */
>  #define HV_X64_ENLIGHTENED_VMCS_VERSION		0xff
> @@ -410,6 +411,7 @@ union hv_x64_msr_hypercall_contents {
>  #if defined(CONFIG_ARM64)
>  #define HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE	BIT(8)
>  #define HV_STIMER_DIRECT_MODE_AVAILABLE		BIT(13)
> +#define HV_VP_ASSIST_PAGE_ADDRESS_SHIFT 12
>  #endif /* CONFIG_ARM64 */
>=20
>  #if defined(CONFIG_X86)
> @@ -1163,6 +1165,8 @@ enum hv_register_name {
>  #define HV_MSR_STIMER0_CONFIG	(HV_X64_MSR_STIMER0_CONFIG)
>  #define HV_MSR_STIMER0_COUNT	(HV_X64_MSR_STIMER0_COUNT)
>=20
> +#define HV_VP_ASSIST_PAGE_ADDRESS_SHIFT HV_X64_MSR_VP_ASSIST_PAGE_ADDRES=
S_SHIFT
> +
>  #elif defined(CONFIG_ARM64) /* CONFIG_X86 */
>=20
>  #define HV_MSR_CRASH_P0		(HV_REGISTER_GUEST_CRASH_P0)
> @@ -1185,7 +1189,7 @@ enum hv_register_name {
>=20
>  #define HV_MSR_STIMER0_CONFIG	(HV_REGISTER_STIMER0_CONFIG)
>  #define HV_MSR_STIMER0_COUNT	(HV_REGISTER_STIMER0_COUNT)
> -
> +#define HV_MSR_VP_ASSIST_PAGE    (HV_REGISTER_VP_ASSIST_PAGE)

Nit: This definition is slightly mis-aligned. It has spaces where there
should be a tab to match the similar definitions above it.

>  #endif /* CONFIG_ARM64 */
>=20
>  union hv_explicit_suspend_register {
> --
> 2.43.0
>=20


From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from CH4PR04CU002.outbound.protection.outlook.com (mail-northcentralusazolkn19013064.outbound.protection.outlook.com [52.103.20.64])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6531C34E75A;
	Mon, 27 Apr 2026 05:38:04 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.103.20.64
ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1777268285; cv=fail; b=mcJ57kLrklPFc2+6nJ6tVgaBP/zSw3EuJtdEbRrdPBEEkEE86l5hrpG0rWT2PoYH6W3gq5IOOLMS03lG9h5xUgiPk7xp9JWHMftqrx6vtmSZGCEb8Cj07tZ5ASAJXURlqQs8nuvW8huhtv/m6Uv3fgar8kGxvuSnqz7LebvZvVo=
ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1777268285; c=relaxed/simple;
	bh=23W1w1jfbpsm6oH+QwPMRRnLpNqdiPDi/RhUGJGk+4M=;
	h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:
	 Content-Type:MIME-Version; b=KKELsROvU35IsaGP2+q0F0d6JFB/EYSf98hXFYdouvFwPTIyDcaFffp/z0R5dcMOhShWEckeB85zvBal84PEyhOjTw+QFMB52Ho//IGQteP9thOFpOLHJw98iJjIXv8Q9D/YQInksUBQWsXOw+1tj9JvLLWGHaK1ur5a+an2obQ=
ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=outlook.com; spf=pass smtp.mailfrom=outlook.com; dkim=pass (2048-bit key) header.d=outlook.com header.i=@outlook.com header.b=f1+cKhCC; arc=fail smtp.client-ip=52.103.20.64
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=outlook.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=outlook.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=outlook.com header.i=@outlook.com header.b="f1+cKhCC"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=pQEWil3AX6nO8pvkLeNTwsKoIH3/9weZ+Bw/VHJvY/A3lgdi06Sgss/DeCH7VRlukxktdvlsFlETGbsVxsn7HwcWkCD6KDQHw+iA8/VRzFT/LqtgnH7hfphsNzErKD6zmUsZCia1thoulBakrQuLM+m9JH1Jz+c/Ir8+x3VObeSx4kGXBxWnLCoS0aRYylyPzGRx0pDhkdwoOzYGbjRIz1NPRlR4HQeT9j2NMvLqFUGr2Fsa4I3kwc4dlyZmVV05p6PL1YafISWI8+tnVjy5TSWwrTjuYPvtYpEmZZBrqZ6FMftHr1phm9imj14hImqKI3UlAotGoshyLztPYPLTbw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=QzNX49s8ma2LUbwHFAK21zBkXpHE3+eG9f2U6d1UHHE=;
 b=nuAVwbTnnjK+MxufumCu6wfMU89T8afwwTdy3SAlF/CKaJ1q4hDa/yMLI74Kuv/fhJmcvKg3FT/JKoYoVK4DV5a+t2eEe1aiJL6PuSrluIqpBMvVN2oS2fj7n5tXEayFZB82V2Gq/zra4o3guy17y0IhVlN9CclDs08sLBEj/wT1U0q8bpVMLchkOiB1E++If7/siySHGVTdYwINCVqO9ZIIn2Qlo/YDoh8nfRIWltPdxZ4lOUlbAWIDkYOJfZOqF4vD83syJJKe4CkII7SUhUY7H5kNUO6eIHLPRluW8TBRzqqUhdPCUyZzAsWTkVSheZHnmoNMgBB43KX0EiC71A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=QzNX49s8ma2LUbwHFAK21zBkXpHE3+eG9f2U6d1UHHE=;
 b=f1+cKhCCxk6Wk5vZ71ErTGzeiBv+Ih3E02ACB9bZtHRo5OATpEnJlWnPhTsiRe3gsJW05qjb+Qi953l46DfvSol9uNrUoYgF1WRHu5f7OzQFplIBPDSL5SHw+zS517HVtVG93YQJZB1SH7JTlO+WnReRj6H5Zo2OxO/msLQ0bJqWILSOJ51K1vZeLPu285TUtudXOqriejB+C/9h6jWn0RrLJGLJZjq+ro8sLx5MNHmu3sze11a6GvpDbS9F7lxJWz2JBO3wzRfpvqpLcLitpsohxcNWsXDgoc670BTwTEJMqBg854vvelSmAT41zmJuAkOYpMPo0d2xDEcxCTqUlg==
Received: from SN6PR02MB4157.namprd02.prod.outlook.com (2603:10b6:805:33::23)
 by CO6PR02MB7809.namprd02.prod.outlook.com (2603:10b6:303:a2::22) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9846.26; Mon, 27 Apr
 2026 05:38:00 +0000
Received: from SN6PR02MB4157.namprd02.prod.outlook.com
 ([fe80::900:1ccf:2b1e:52b6]) by SN6PR02MB4157.namprd02.prod.outlook.com
 ([fe80::900:1ccf:2b1e:52b6%6]) with mapi id 15.20.9846.025; Mon, 27 Apr 2026
 05:38:00 +0000
From: Michael Kelley <mhklinux@outlook.com>
To: Naman Jain <namjain@linux.microsoft.com>, "K . Y . Srinivasan"
	<kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu
	<wei.liu@kernel.org>, Dexuan Cui <decui@microsoft.com>, Long Li
	<longli@microsoft.com>, Catalin Marinas <catalin.marinas@arm.com>, Will
 Deacon <will@kernel.org>, Thomas Gleixner <tglx@kernel.org>, Ingo Molnar
	<mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, Dave Hansen
	<dave.hansen@linux.intel.com>, "x86@kernel.org" <x86@kernel.org>, "H . Peter
 Anvin" <hpa@zytor.com>, Arnd Bergmann <arnd@arndb.de>, Paul Walmsley
	<pjw@kernel.org>, Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou
	<aou@eecs.berkeley.edu>, Alexandre Ghiti <alex@ghiti.fr>, Michael Kelley
	<mhklinux@outlook.com>
CC: Marc Zyngier <maz@kernel.org>, Timothy Hayes <timothy.hayes@arm.com>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>, Sascha Bischoff
	<sascha.bischoff@arm.com>, mrigendrachaubey <mrigendra.chaubey@gmail.com>,
	"linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>, "linux-kernel@vger.kernel.org"
	<linux-kernel@vger.kernel.org>, "linux-arch@vger.kernel.org"
	<linux-arch@vger.kernel.org>, "linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>, "vdso@mailbox.org" <vdso@mailbox.org>,
	"ssengar@linux.microsoft.com" <ssengar@linux.microsoft.com>
Subject: RE: [PATCH v2 03/15] Drivers: hv: Move vmbus_handler to common code
Thread-Topic: [PATCH v2 03/15] Drivers: hv: Move vmbus_handler to common code
Thread-Index: AQHc0x6xowCVGOfZ/kaacmAUtH31s7XyacUQ
Date: Mon, 27 Apr 2026 05:38:00 +0000
Message-ID:
 <SN6PR02MB4157E3B0A6F76E4686D8C3E4D4362@SN6PR02MB4157.namprd02.prod.outlook.com>
References: <20260423124206.2410879-1-namjain@linux.microsoft.com>
 <20260423124206.2410879-4-namjain@linux.microsoft.com>
In-Reply-To: <20260423124206.2410879-4-namjain@linux.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: SN6PR02MB4157:EE_|CO6PR02MB7809:EE_
x-ms-office365-filtering-correlation-id: d917da57-ddd5-40d0-3aac-08dea41f250e
x-microsoft-antispam:
 BCL:0;ARA:14566002|51005399006|55001999006|37011999003|13091999003|19101099003|461199028|41001999006|31061999003|19110799012|15080799012|8062599012|8060799015|56899033|40105399003|440099028|3412199025|102099032|12091999003|1710799026;
x-microsoft-antispam-message-info:
 =?us-ascii?Q?NaKZ/JifPSMsOIShsnHpoTf7nrM66O6E7SfdZ+P5wWvL/ki3sx7/FA4s1hNn?=
 =?us-ascii?Q?EQRvLqHcgvcFedvWyhUjivTN6T+0AyRTWyJIgT+w0BQw4j/HhbTHYtZ3BJZ2?=
 =?us-ascii?Q?pSKffrbmjjT8keZmYI2JiqfkLZauyw29KtxjhDvrUM81qKskCkbu5gbtnyAF?=
 =?us-ascii?Q?fw/ddvRWVhgq43ON6XewzHHBKPb7CKCLyStr4/r4rrqrauVRtsxC4K0rBiGm?=
 =?us-ascii?Q?UBr4STB9HXgTZJmYAfd+/kJqjPeHdcRImtw9GdN+10WB+k9n2BLQLUN2VeFD?=
 =?us-ascii?Q?Ry6/8A8A2gXKdO9gCpYJB00qG6hLJweUkTtAIiJHRQLWVH5PqKJEIyy3hB8v?=
 =?us-ascii?Q?vGQoKE8+seqqPKsWxL2QoatGoU5+BBIes1BIHWNQLRjvLSJZHhSYPA1/vYsW?=
 =?us-ascii?Q?2P18xqkcGL9T144wKv6iukiSjQPgdlME6D0jDbwsNGPbMG+o32Q+GOMNtokj?=
 =?us-ascii?Q?O5Hd2X+0Liu4wwzMzz0h6vzQhN7AlT5KKHe0pA7Ms/+hJ42Q2qdMn5k3ej6D?=
 =?us-ascii?Q?mKBn7utp9AvaZ2OYSZYLEvODl7RGY9uprEaSZot4ueCReD4r6KJCmmO536zT?=
 =?us-ascii?Q?w+UC9M7iqy75rQ8uPnDrAPx4SU6fi24VTqsLZE26e21RTWBSSxlyWFzBFtA/?=
 =?us-ascii?Q?9duXtsszm2hkCykgzWjtHWLhaJ75bfQBtBoPQpJVH+xawksyH8POqAHId2qe?=
 =?us-ascii?Q?aRSS0b4vSJDONGuUFBVuhFVwvRgrco4igQVAjrvGUFQf0XzO0/wNfsGtUIBr?=
 =?us-ascii?Q?zI92AEOYDcqSHfa7RBjhcTLrP3/6aV7bMJlpll+HFna5P5uyP0BQwbO6PAlM?=
 =?us-ascii?Q?zXzc1z65G/ESAoPLvc8jeJ8PgskTzQAFwtbAQ7IfrNM6W3OgQaK1IGNhAjmG?=
 =?us-ascii?Q?WjoZgad6mVEgqAgzTKtmsZ1qIqBj6VeZHw+kYPya1WDW7jRb0lR9eE8eOhq3?=
 =?us-ascii?Q?Aev5O/hWCiMQqb6D4TEdbZIngWijHiEggnxfHndpRFUfnI9uqgunQPhqa8xW?=
 =?us-ascii?Q?myG3zDaxbrciUKMpoVRnbNbG62ATo9BOM/Cl42ZvB7l19ZFSEPPPp49J5yMp?=
 =?us-ascii?Q?RmR4t0FVguGPS6qBVVsENPBBGD6vkeIlfER8f+FBKi51YNk4HGxSba5yDeg9?=
 =?us-ascii?Q?Pd/16UFH7t0Z?=
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?aPWp34m2VTQ9o9KLh/l80OnSBlsf6mYDFD5V28Z5VOmgd5VJVrJ9TXLcuR4l?=
 =?us-ascii?Q?kaZCrS4wHPX/iJ1CF6mt4zo9g3u17Qb9ZLaZoI1hMJ8vTW4wHrfJOZRhmClz?=
 =?us-ascii?Q?oZtZGH9u9t5/dLbmewuNNPabIIdaWY/K+A3GldHY2XfFqdS7m2CedgNji8Wj?=
 =?us-ascii?Q?NHHVwMsMlZp+mnwbYq4eey1FVLAKZcyCVu+wBLIzRQpRZm0RLYJMnNe2Yxkk?=
 =?us-ascii?Q?wWXXtk2nS9ERXjpk5xVGEnLoue44hkvXjAcmPWF4D3Jx3HzhCl0rXEJfHqFH?=
 =?us-ascii?Q?EZT84wWDle7HJkv32JU6lM9Dpx7kDzSyK/q5VmF28eyYQJL2JEMA0wmfU9j2?=
 =?us-ascii?Q?yWxF4mgnKyNU5v8r1yJL+XbV/cpxEFZ/MKWT+9IuRni8pMxLgG7c5ER/NSQo?=
 =?us-ascii?Q?OZ+NJb2sEJqXxGl8o4xxYsMcx08H34eaUXCCE4naV3+z3W/XZTgWmnePfMpN?=
 =?us-ascii?Q?A1eJOogrNFJEFLIXVKOjzsF33V2VMmcJu+OcVK6sg8jPglx7cl3uzI8GD7va?=
 =?us-ascii?Q?/gT9gVB8HDFYbJPCurRDTDVX6o7plSZzoep6EBHJeHcvFP3HWBBHHEy3A3D/?=
 =?us-ascii?Q?EFrrNmaw1hmjaiYqGRxP68eOb9E69Da0gY0/d1FpYwUasAs2qrFgXKzlDZZ5?=
 =?us-ascii?Q?N6yVBnEAUCvLv4EQgLT1z/na9lchN/SBBWqJ18OTL0a/KqljFSqk7m3CnmOa?=
 =?us-ascii?Q?JXALgpVkxJCvwyV05+DZwVHAoL4fvnHLzBIsZciP2IYpUS4KEAJzuFNon01w?=
 =?us-ascii?Q?cidghkLKu8AJAmjUhTeGDKHba94osPkBiwF4SaOWDEmwBHvt46ykUv4RPU9y?=
 =?us-ascii?Q?4sVVu/7HRt6Ir1QU478XPDmCfgpu7uFfnhoHcgNZtXPY4FLQltmXE9/OoynU?=
 =?us-ascii?Q?8NhN8r/LTarbrU+HZG8itseEFG0CQkgx/HpTkqeW9dHDZyfB9SkdDS1oMAr0?=
 =?us-ascii?Q?oNEEwDWCJNY9Un8yblqMDPDwOX+gKf5ddNNdOjD7hcHtPK2tD98UXmHX/KfA?=
 =?us-ascii?Q?J0GP1kkE0N/LmIWljH+eNtnd7T7ajSwvZKgicSOz9HuvZARvpsB/oNiv/dek?=
 =?us-ascii?Q?Kef/wffe58VjepD/2XU3xSyMCKNvixMLiJI2mpnwvh1QP+Cni6ycr4fRA2ru?=
 =?us-ascii?Q?AtM0JwTHqu8c88joRPV6B6bq8gjcie63UZn2dVDTZH2Y1O0ur+BZxC5epB9S?=
 =?us-ascii?Q?nLCJ88KFy75uhKBQZkPIp2VXQYblDSA3GEZYj2QHnq5ny85D4HyhaWQ6+5nJ?=
 =?us-ascii?Q?8dwjL+PAQZjKIbJkmEYLmfaXYZicCgfdx6h7XW8CbAQCgLpkznSOCRaPPBeP?=
 =?us-ascii?Q?quAR6hJV9FQ7gcqor9MPvzCdffVNtfu6WHnzWpuuVPQJD1Ctvu/hoaRdXTql?=
 =?us-ascii?Q?lWDtIuA=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
X-Mailing-List: linux-arch@vger.kernel.org
List-Id: <linux-arch.vger.kernel.org>
List-Subscribe: <mailto:linux-arch+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-arch+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SN6PR02MB4157.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: d917da57-ddd5-40d0-3aac-08dea41f250e
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2026 05:38:00.5299
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO6PR02MB7809

From: Naman Jain <namjain@linux.microsoft.com> Sent: Thursday, April 23, 20=
26 5:42 AM
>=20
> Move the vmbus_handler global variable and hv_setup_vmbus_handler()/
> hv_remove_vmbus_handler() from arch/x86 to drivers/hv/hv_common.c.
>=20
> hv_setup_vmbus_handler() is called unconditionally in vmbus_bus_init()
> and works for both x86 (sysvec handler) and arm64 (vmbus_percpu_isr).
>=20
> This eliminates the need for separate percpu vmbus handler setup
> functions and __weak stubs, that are needed for adding ARM64 support
> in MSHV_VTL driver where we need to set a custom per-cpu vmbus handler.
>=20
> Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
> ---
>  arch/x86/kernel/cpu/mshyperv.c | 12 ------------
>  drivers/hv/hv_common.c         |  9 +++++++--
>  drivers/hv/vmbus_drv.c         | 17 +++++++++--------
>  include/asm-generic/mshyperv.h |  1 +
>  4 files changed, 17 insertions(+), 22 deletions(-)
>=20
> diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyper=
v.c
> index 89a2eb8a0722..68706ff5880e 100644
> --- a/arch/x86/kernel/cpu/mshyperv.c
> +++ b/arch/x86/kernel/cpu/mshyperv.c
> @@ -145,7 +145,6 @@ void hv_set_msr(unsigned int reg, u64 value)
>  EXPORT_SYMBOL_GPL(hv_set_msr);
>=20
>  static void (*mshv_handler)(void);
> -static void (*vmbus_handler)(void);
>  static void (*hv_stimer0_handler)(void);
>  static void (*hv_kexec_handler)(void);
>  static void (*hv_crash_handler)(struct pt_regs *regs);
> @@ -172,17 +171,6 @@ void hv_setup_mshv_handler(void (*handler)(void))
>  	mshv_handler =3D handler;
>  }
>=20
> -void hv_setup_vmbus_handler(void (*handler)(void))
> -{
> -	vmbus_handler =3D handler;
> -}
> -
> -void hv_remove_vmbus_handler(void)
> -{
> -	/* We have no way to deallocate the interrupt gate */
> -	vmbus_handler =3D NULL;
> -}
> -
>  /*
>   * Routines to do per-architecture handling of stimer0
>   * interrupts when in Direct Mode
> diff --git a/drivers/hv/hv_common.c b/drivers/hv/hv_common.c
> index e8633bc51d56..eb7b0028b45d 100644
> --- a/drivers/hv/hv_common.c
> +++ b/drivers/hv/hv_common.c
> @@ -758,13 +758,18 @@ bool __weak hv_isolation_type_tdx(void)
>  }
>  EXPORT_SYMBOL_GPL(hv_isolation_type_tdx);
>=20
> -void __weak hv_setup_vmbus_handler(void (*handler)(void))
> +void (*vmbus_handler)(void);
> +EXPORT_SYMBOL_GPL(vmbus_handler);
> +
> +void hv_setup_vmbus_handler(void (*handler)(void))
>  {
> +	vmbus_handler =3D handler;
>  }
>  EXPORT_SYMBOL_GPL(hv_setup_vmbus_handler);
>=20
> -void __weak hv_remove_vmbus_handler(void)
> +void hv_remove_vmbus_handler(void)
>  {
> +	vmbus_handler =3D NULL;
>  }
>  EXPORT_SYMBOL_GPL(hv_remove_vmbus_handler);

I'd suggest moving hv_setup_vmbus_handler() and
hv_remove_vmbus_handler() above or below the group
of __weak stubs in this source code file. There's a comment
describing the purpose of these __weak functions, and
intermixing these two functions that are no longer __weak
produces something of a jumble.

>=20
> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> index bc4fc1951ae1..052ca8b11cee 100644
> --- a/drivers/hv/vmbus_drv.c
> +++ b/drivers/hv/vmbus_drv.c
> @@ -1415,7 +1415,8 @@ EXPORT_SYMBOL_FOR_MODULES(vmbus_isr, "mshv_vtl");
>=20
>  static irqreturn_t vmbus_percpu_isr(int irq, void *dev_id)
>  {
> -	vmbus_isr();
> +	if (vmbus_handler)
> +		vmbus_handler();

Is it necessary to test vmbus_handler first? From what I can
see, it is always set before the per-cpu interrupt is setup.

>  	return IRQ_HANDLED;
>  }
>=20
> @@ -1517,8 +1518,10 @@ static int vmbus_bus_init(void)
>  		vmbus_irq_initialized =3D true;
>  	}
>=20
> +	hv_setup_vmbus_handler(vmbus_isr);
> +
>  	if (vmbus_irq =3D=3D -1) {
> -		hv_setup_vmbus_handler(vmbus_isr);
> +		/* x86: sysvec handler uses vmbus_handler directly */
>  	} else {
>  		ret =3D request_percpu_irq(vmbus_irq, vmbus_percpu_isr,
>  				"Hyper-V VMbus", &vmbus_evt);
> @@ -1553,9 +1556,8 @@ static int vmbus_bus_init(void)
>  	return 0;
>=20
>  err_connect:
> -	if (vmbus_irq =3D=3D -1)
> -		hv_remove_vmbus_handler();
> -	else
> +	hv_remove_vmbus_handler();
> +	if (vmbus_irq !=3D -1)
>  		free_percpu_irq(vmbus_irq, &vmbus_evt);

These operations should be reordered so they are the inverse
of how they are setup.  I.e., free_percpu_irq() first, then remove
the VMBus handler. That's just good standard practice unless
there's a specific reason to do the cleanup ordering differently. In
fact, hv_remove_vmbus_handler() needs to be moved down
to the err_setup label so it's done if request_percpu_irq()
fails.

>  err_setup:
>  	if (IS_ENABLED(CONFIG_PREEMPT_RT) && vmbus_irq_initialized) {
> @@ -3026,9 +3028,8 @@ static void __exit vmbus_exit(void)
>  	vmbus_connection.conn_state =3D DISCONNECTED;
>  	hv_stimer_global_cleanup();
>  	vmbus_disconnect();
> -	if (vmbus_irq =3D=3D -1)
> -		hv_remove_vmbus_handler();
> -	else
> +	hv_remove_vmbus_handler();
> +	if (vmbus_irq !=3D -1)
>  		free_percpu_irq(vmbus_irq, &vmbus_evt);

Ordering should be changed here as well so it is the inverse
of how things are set up.

>  	if (IS_ENABLED(CONFIG_PREEMPT_RT) && vmbus_irq_initialized) {
>  		smpboot_unregister_percpu_thread(&vmbus_irq_threads);
> diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyper=
v.h
> index 2810aa05dc73..db183c8cfb95 100644
> --- a/include/asm-generic/mshyperv.h
> +++ b/include/asm-generic/mshyperv.h
> @@ -179,6 +179,7 @@ static inline u64 hv_generate_guest_id(u64 kernel_ver=
sion)
>=20
>  int hv_get_hypervisor_version(union hv_hypervisor_version_info *info);
>=20
> +extern void (*vmbus_handler)(void);
>  void hv_setup_vmbus_handler(void (*handler)(void));
>  void hv_remove_vmbus_handler(void);
>  void hv_setup_stimer0_handler(void (*handler)(void));
> --
> 2.43.0
>=20


From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from BYAPR05CU005.outbound.protection.outlook.com (mail-westusazolkn19010074.outbound.protection.outlook.com [52.103.2.74])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6E34E40DFA5;
	Mon, 27 Apr 2026 05:38:38 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.103.2.74
ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1777268319; cv=fail; b=W6Z3x6DtqIfhNBxKG73ofr59DlZMYKhWWLA5r6MFNKnA+mWR5xijxB0LFNtc+1y9OkvHs9dRLKGnJ7JLx7Jnzk5qDEfESCN5wumKDKI/HphUJUB4BJ0JmWIjd3c3MH6xJgVAobIf1MTHSWp2JaM6OnSXr2IRBMIWX7mKUyt4AtA=
ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1777268319; c=relaxed/simple;
	bh=nsexESQFzzuQIUeMVEGsVW+ovf7eJs2NQMo2bY/PjYE=;
	h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:
	 Content-Type:MIME-Version; b=Vx3zr8q4zsV3+Dcx3jocMHEzxFuyEIlnHq5WMgQ9L5ykkAc0ZO2e713Bg2tRvGHFqsqieTOxbw6C+fA1OTuZVP+jjrYzjd18mJff+FKpQjiWJEZLC9lDpsilD39tnbWbjPFpulX5l59Tsx6gfd4O9i5lZp5t/ymvkKE1oJ076C4=
ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=outlook.com; spf=pass smtp.mailfrom=outlook.com; dkim=pass (2048-bit key) header.d=outlook.com header.i=@outlook.com header.b=Keo/XI+u; arc=fail smtp.client-ip=52.103.2.74
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=outlook.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=outlook.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=outlook.com header.i=@outlook.com header.b="Keo/XI+u"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=rI7c7BL/cql87GbK93AlsI2ALnjn85aZcFqWbtu/j65TzMJ4vAB/pT2TtlW9zua5eTaaYkHv7oKE/uR4sjRsd9gM8cO053/l7a8WjVPjuCXAXo3I+ukb/1PWMvN5SnuF+T1ollJ1DxiQ0ftViHe42Vhm41u8rdY+gRQIv08AG7aYC+TQov0PoDGZs91bn+YqOXl4j2x//9ShslWcJ8Uh2gIO1fqvvr2k9o5SFNMbbE1ghBJeD/T2DcqrB1bPg/edHayWkBv5q3HwC+Gdc52xyw4t4flxG8uH1OMMM/afnKs049d8gC98BRi/hc0ijkBurHKGpYOM6J2iok8n6VnZdw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=IyCkDfl2b4CE7cMiZKoCxrcBKGyTdycTXlQWTkCvXDU=;
 b=K8mRYdZ7BL93PdjwaeSgP862qUuBPf/GNQkUFGrIsSRsHqCNI7Ss6RH8CeuDZwB9NhkTyXzb5VEyyyWGRytA+7vhlkbmZrcKIklpCue45/r+Wwo26TX06ahRj49B3MSxCsuOZltZ4DBsWRhRJbARXVW+BUCfOpZ37aWs+iFDu+WG1qvGjJtLr6wRZGUKyUUwxOk5KibQkLyM/OTsbBoStHwhd6ym3HKPt3IPOrLB3q/okzH9Q4vTkgf7v4ZYTRcdo+M8BsTXfk7aPg/RxhPcymArDe1TQMpjkqR5DljB3hIAqXpu086mWTmH5tlLoT1PDVEJCWl7+aw9Be4AgkSm1Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=IyCkDfl2b4CE7cMiZKoCxrcBKGyTdycTXlQWTkCvXDU=;
 b=Keo/XI+uJFFBX3nBEh77Uio3hC+1+lTEdRpZEvaF7iOeay4AWfTDTsBDmr1QkPKUf8FnBBaSOyS9nqKimePAIOku6vvt5PUF9O5gP/0OvzLbPvTR0dmJcM0nrPC68IgeSYySqlH2jjyO0IwcIk2mkJbVRAhnfQqmdZ9BuoWl0FZSiK6POwN7tnK+zHbADWcvu2LXn8Qc7Y5UXkkPY8OrDiVymJcxM3w/VhH+i7RVv2dlUjM8YrZauVljuZ7TaKvnil+sV5gEJjfacJzIaY5iECcpHDMpGxmksWwU62AT5UxLABjUTJGRPCabreeP8y9Slj0bjgR1bANJ+0CgHzGznA==
Received: from SN6PR02MB4157.namprd02.prod.outlook.com (2603:10b6:805:33::23)
 by CO6PR02MB7809.namprd02.prod.outlook.com (2603:10b6:303:a2::22) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9846.26; Mon, 27 Apr
 2026 05:38:35 +0000
Received: from SN6PR02MB4157.namprd02.prod.outlook.com
 ([fe80::900:1ccf:2b1e:52b6]) by SN6PR02MB4157.namprd02.prod.outlook.com
 ([fe80::900:1ccf:2b1e:52b6%6]) with mapi id 15.20.9846.025; Mon, 27 Apr 2026
 05:38:35 +0000
From: Michael Kelley <mhklinux@outlook.com>
To: Naman Jain <namjain@linux.microsoft.com>, "K . Y . Srinivasan"
	<kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu
	<wei.liu@kernel.org>, Dexuan Cui <decui@microsoft.com>, Long Li
	<longli@microsoft.com>, Catalin Marinas <catalin.marinas@arm.com>, Will
 Deacon <will@kernel.org>, Thomas Gleixner <tglx@kernel.org>, Ingo Molnar
	<mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, Dave Hansen
	<dave.hansen@linux.intel.com>, "x86@kernel.org" <x86@kernel.org>, "H . Peter
 Anvin" <hpa@zytor.com>, Arnd Bergmann <arnd@arndb.de>, Paul Walmsley
	<pjw@kernel.org>, Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou
	<aou@eecs.berkeley.edu>, Alexandre Ghiti <alex@ghiti.fr>, Michael Kelley
	<mhklinux@outlook.com>
CC: Marc Zyngier <maz@kernel.org>, Timothy Hayes <timothy.hayes@arm.com>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>, Sascha Bischoff
	<sascha.bischoff@arm.com>, mrigendrachaubey <mrigendra.chaubey@gmail.com>,
	"linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>, "linux-kernel@vger.kernel.org"
	<linux-kernel@vger.kernel.org>, "linux-arch@vger.kernel.org"
	<linux-arch@vger.kernel.org>, "linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>, "vdso@mailbox.org" <vdso@mailbox.org>,
	"ssengar@linux.microsoft.com" <ssengar@linux.microsoft.com>
Subject: RE: [PATCH v2 07/15] arm64: hyperv: Add support for
 mshv_vtl_return_call
Thread-Topic: [PATCH v2 07/15] arm64: hyperv: Add support for
 mshv_vtl_return_call
Thread-Index: AQHc0x7Gd+InXWMHLEisx/6viGrEn7Xyae9Q
Date: Mon, 27 Apr 2026 05:38:35 +0000
Message-ID:
 <SN6PR02MB4157C147A1B915F9B45D3B74D4362@SN6PR02MB4157.namprd02.prod.outlook.com>
References: <20260423124206.2410879-1-namjain@linux.microsoft.com>
 <20260423124206.2410879-8-namjain@linux.microsoft.com>
In-Reply-To: <20260423124206.2410879-8-namjain@linux.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: SN6PR02MB4157:EE_|CO6PR02MB7809:EE_
x-ms-office365-filtering-correlation-id: 427b9deb-6a6d-4a75-928d-08dea41f39b6
x-microsoft-antispam:
 BCL:0;ARA:14566002|12121999013|51005399006|55001999006|16051099003|37011999003|13091999003|19101099003|461199028|41001999006|31061999003|19110799012|15080799012|8062599012|8060799015|13041999003|40105399003|440099028|3412199025|102099032|1710799026;
x-microsoft-antispam-message-info:
 =?us-ascii?Q?HTaDs4IlpRGQ0gWQKq4/r/XpgVoShUGVwedrjshdgPo7N1kcH3WUAGXLnku+?=
 =?us-ascii?Q?Ujz0S3Q6S7uFavBt6K/iVueK+CbSJAxhr/snxdTUYUFL4rew9FxQRnxi76k6?=
 =?us-ascii?Q?W50w/0Mm2Za43GIVB0623npYAXFzRDN5aAe9NBVG3oVV2kyuPByPI7ZBAEKX?=
 =?us-ascii?Q?3pqGr2LnUxs8KEJ/kZSYYKVxK7h/nQWdO24FmngX7XxMP6F+cWaEsjzuJ9yw?=
 =?us-ascii?Q?3z7wzdxqQ38hqJt5x1sIPtq92te8ZC0Gb3gNlTKH7SlSWHFhLlZSUA5zln9+?=
 =?us-ascii?Q?VJ541V08uaBsBSKZBIQG2zw2nddRBQSKPwT7jJQc/hDs3/jHOQzpyHRoQM4s?=
 =?us-ascii?Q?A4MSJP9pS3wC5Lt9ef+COuXgzx+qqk5pOUz4S54uCPJM8mqVS8+A0qAraLd7?=
 =?us-ascii?Q?6zuvECOdc31Vo3rPB7o37bijgmbM1sypuGSTFM+ivVjKLt94Mr/GtMpQI4O0?=
 =?us-ascii?Q?aGraT+OQs7T8buvcDCeovMIaFiWxRYdyKrJEaN+BSdu7LPFiNItubgfdk+KU?=
 =?us-ascii?Q?1aRUjCbMAhBXoSLY4fuu8YsNpGBN4PtdWb4m/N8dGQrf89FOo2YZkuFSzUEz?=
 =?us-ascii?Q?6X6TaKwX7rs0LRjjVFccijbv5uwyRTKIQho3CQdiIJwoj1Kqm5CmIYpOUcB1?=
 =?us-ascii?Q?Az7rCuYp1fwihuDLMGHuFx8sxO69LsZE+LttQb7vnMuPj6HLckaoLdyDuAnM?=
 =?us-ascii?Q?swaptmLFUTgGCLm98CORUntjUnM+4R1RxgNoL8box5sFTUnRX8o7gae9x4GR?=
 =?us-ascii?Q?vYdOp2vXdCvVnsEOVhXaVqJmOaHGO1S2mAoZqBiBNLOmHSNuBxfLSXTjgqFw?=
 =?us-ascii?Q?05lgJ+HepU4fw8+OWU7NKazBasPiwq3NBrPqn+ORxtRgmR1623tDsEnALESW?=
 =?us-ascii?Q?4i0TV54AcmkB+b7nDiy3aa46tBPDaHrjgi/hk4yju458+dDqlq3zFAfZZ9CD?=
 =?us-ascii?Q?QNTGS4AsvgxhXxProSDcixuJ82aRO4vNgW/5sEt7nZt0UtTivWulKzIYD4W8?=
 =?us-ascii?Q?PvjUO24G+L72Wj8NexU0Z51cNlcQsI4t/mEuDxhgau6BYoYycO2DafmfVYA7?=
 =?us-ascii?Q?XxKsn/Nmaswo0M9FVKWec6V/f+o/F8Xe6+B4RiRx5I0CW5rR6Kx5BtTer7Ii?=
 =?us-ascii?Q?AmlFy4Ox+7iMrVTOyMUeBMG3KrnGRkyg/5CPGZKMv+fdTLPhuelp8E9NIscB?=
 =?us-ascii?Q?IpPFO2hMbwvWowtf?=
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?hmOzlxiJFtWUscWH1pAlqyP47v5k5qUZHtEqT6wpHCaX2Ru4J6qtVBSZivUu?=
 =?us-ascii?Q?45lsA3mq8GJItzNgG2fO4rAUEG2DyHX0RPgC0zfcQaJ9+idv3yBoeuna3C2a?=
 =?us-ascii?Q?2haoDfB4Z78ajH7rp5gkT1A8SUmevxG1F4T0qYMnCDsD6fc4GW2fycs4Yp1t?=
 =?us-ascii?Q?VKziqPeI7Q+HzfC7+a4bM/dKckEQtnIdA87CZBueIrWHXOW+Oa1xDcmumsmj?=
 =?us-ascii?Q?0tn9rD97vqvEgD/RprHVfNWDe07k6O+ful+eevN6duNzpKXgieWgBae9jz7M?=
 =?us-ascii?Q?EKp00xFIEN60PmsPC/8cDpljJQwOllWrZlW6epFiyq2NlaCaS+t4z4249rff?=
 =?us-ascii?Q?InuzWecz+pRcCfRaTYpPQGmSi9FItdD9MmpTgi+259//3J17PwnbcKqccy+r?=
 =?us-ascii?Q?fzu4/MA/42aoQk4VlZfyrfhh8LtBaGpmusSarvsv4/Ip6KVz6sW59NnU2H1U?=
 =?us-ascii?Q?PIXe6dh5Yis+P+mPOaKRxMte4gBm/q7tl9NbKfBe1MHjFjU96iW3DfyDaFeY?=
 =?us-ascii?Q?3OARDpk+uNTSIhrhvm9jHdCgbK/MpA3WO8lwyQ6s4aOnceJropjGOLrwUBTB?=
 =?us-ascii?Q?nHjgVqmDDFY/GoXuTGRdFxrp3KSFN45F8p/KuezBmApx0uHWle0qUjVQlX8s?=
 =?us-ascii?Q?hA7yc65P8gpOtznYUQ5jmXOZV5Ylga2Ns/tkCltposdxnz/UO2Ogx8jsTx6n?=
 =?us-ascii?Q?YMhJKG4KLPELE4bdqZ8/x8WnU9QUGzJUzXM+B23AXTi+K3xmIGtlc7z3NPRP?=
 =?us-ascii?Q?YYnyBIJL82SLM7AgeVA4YXhLPX8GuK6yrzVaUisP8MkAkg1q+E6u1Ycvk5TQ?=
 =?us-ascii?Q?yS7v9JwEuJRmpjDaNaX+2wBq2Yr93E3S49wMWSzb8s+bnTrAqnteRE3qJa21?=
 =?us-ascii?Q?739se0AhQd6cC+bPWlchSWxINgVzQJ2yny4/9IatlrPWyR2ufv912/PMnTkB?=
 =?us-ascii?Q?BStsA/2SfpVD/Vvl0gTiAXrva/sKF1SEWXuQuiSmdeZN9dRWTDvft2rbZxqp?=
 =?us-ascii?Q?KnEwJXTHEBMPnCX+8X2gt4PL8V7sjhgn4VUICDyFNoSsJVXPkUpPpY487xZn?=
 =?us-ascii?Q?Mf9E95Uga97QqLOSer4DfKAjyvpqSZZqKQHoekzdKgfsCuPd4rspBS+H4kIE?=
 =?us-ascii?Q?MKchvzuhRVbNV3f4pzy548rBlDNEgg+wdlnIkt4mpeEcBezT6SlR+Xb9KtSi?=
 =?us-ascii?Q?VRvhBx5VvRtsFaZ5wvo1VTihroNNoa+6M2ybzaIayLGB9tA08K0A6EXEa0go?=
 =?us-ascii?Q?AD0U3zg7yD/8P8XuQSVv5M0rd1Wrh5pakZzSkFtRmUI18rYikw2g1K0dinhJ?=
 =?us-ascii?Q?rSF7vu3TJZdINp2NgPPF96Gd6YHVqOw8bLxLahN9KgyGY6M+cu4Lz0WM4ubI?=
 =?us-ascii?Q?oChAbr8=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
X-Mailing-List: linux-arch@vger.kernel.org
List-Id: <linux-arch.vger.kernel.org>
List-Subscribe: <mailto:linux-arch+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-arch+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SN6PR02MB4157.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 427b9deb-6a6d-4a75-928d-08dea41f39b6
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2026 05:38:35.1978
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO6PR02MB7809

From: Naman Jain <namjain@linux.microsoft.com> Sent: Thursday, April 23, 20=
26 5:42 AM
>=20
> Add the arm64 variant of mshv_vtl_return_call() to support the MSHV_VTL
> driver on arm64. This function enables the transition between Virtual
> Trust Levels (VTLs) in MSHV_VTL when the kernel acts as a paravisor.
>=20
> Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
> Reviewed-by: Roman Kisel <vdso@mailbox.org>
> Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
> ---
>  arch/arm64/hyperv/Makefile        |   1 +
>  arch/arm64/hyperv/hv_vtl.c        | 158 ++++++++++++++++++++++++++++++
>  arch/arm64/include/asm/mshyperv.h |  13 +++
>  arch/x86/include/asm/mshyperv.h   |   2 -
>  drivers/hv/mshv_vtl.h             |   3 +
>  include/asm-generic/mshyperv.h    |   2 +
>  6 files changed, 177 insertions(+), 2 deletions(-)
>  create mode 100644 arch/arm64/hyperv/hv_vtl.c
>

[snip]

> diff --git a/arch/arm64/include/asm/mshyperv.h b/arch/arm64/include/asm/m=
shyperv.h
> index 585b23a26f1b..9eb0e5999f29 100644
> --- a/arch/arm64/include/asm/mshyperv.h
> +++ b/arch/arm64/include/asm/mshyperv.h
> @@ -60,6 +60,18 @@ static inline u64 hv_get_non_nested_msr(unsigned int r=
eg)
>  				ARM_SMCCC_SMC_64,		\
>  				ARM_SMCCC_OWNER_VENDOR_HYP,	\
>  				HV_SMCCC_FUNC_NUMBER)
> +
> +struct mshv_vtl_cpu_context {
> +/*
> + * x18 is managed by the hypervisor. It won't be reloaded from this arra=
y.
> + * It is included here for convenience in array indexing.
> + * 'rsvd' field serves as alignment padding so q[] starts at offset 32*8=
=3D256.
> + */
> +	__u64 x[31];
> +	__u64 rsvd;
> +	__uint128_t q[32];
> +};
> +
>  #ifdef CONFIG_HYPERV_VTL_MODE
>  /*
>   * Get/Set the register. If the function returns `1`, that must be done =
via
> @@ -69,6 +81,7 @@ static inline int hv_vtl_get_set_reg(struct hv_register=
_assoc *regs,
> bool set, b
>  {
>  	return 1;
>  }
> +

This appears to be a spurious blank line being added since there
are no other changes in the vicinity.

>  #endif
>=20
>  #include <asm-generic/mshyperv.h>
> diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyp=
erv.h
> index 08278547b84c..b4d80c9a673a 100644
> --- a/arch/x86/include/asm/mshyperv.h
> +++ b/arch/x86/include/asm/mshyperv.h
> @@ -286,7 +286,6 @@ struct mshv_vtl_cpu_context {
>  #ifdef CONFIG_HYPERV_VTL_MODE
>  void __init hv_vtl_init_platform(void);
>  int __init hv_vtl_early_init(void);
> -void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0);
>  void mshv_vtl_return_call_init(u64 vtl_return_offset);
>  void mshv_vtl_return_hypercall(void);
>  void __mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0);
> @@ -294,7 +293,6 @@ int hv_vtl_get_set_reg(struct hv_register_assoc *regs=
, bool set,
> bool shared);
>  #else
>  static inline void __init hv_vtl_init_platform(void) {}
>  static inline int __init hv_vtl_early_init(void) { return 0; }
> -static inline void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl=
0) {}
>  static inline void mshv_vtl_return_call_init(u64 vtl_return_offset) {}
>  static inline void mshv_vtl_return_hypercall(void) {}
>  static inline void __mshv_vtl_return_call(struct mshv_vtl_cpu_context *v=
tl0) {}
> diff --git a/drivers/hv/mshv_vtl.h b/drivers/hv/mshv_vtl.h
> index a6eea52f7aa2..103f07371f3f 100644
> --- a/drivers/hv/mshv_vtl.h
> +++ b/drivers/hv/mshv_vtl.h
> @@ -22,4 +22,7 @@ struct mshv_vtl_run {
>  	char vtl_ret_actions[MSHV_MAX_RUN_MSG_SIZE];
>  };
>=20
> +static_assert(sizeof(struct mshv_vtl_cpu_context) <=3D 1024,
> +	      "struct mshv_vtl_cpu_context exceeds reserved space in struct
> mshv_vtl_run");
> +
>  #endif /* _MSHV_VTL_H */
> diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyper=
v.h
> index db183c8cfb95..8cdf2a9fbdfb 100644
> --- a/include/asm-generic/mshyperv.h
> +++ b/include/asm-generic/mshyperv.h
> @@ -396,8 +396,10 @@ static inline int hv_deposit_memory(u64 partition_id=
, u64 status)
>=20
>  #if IS_ENABLED(CONFIG_HYPERV_VTL_MODE)
>  u8 __init get_vtl(void);
> +void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0);
>  #else
>  static inline u8 get_vtl(void) { return 0; }
> +static inline void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl=
0) {}

Is this stub needed? Maybe I missed something, but it looks to me like none
of the code that calls this gets built unless CONFIG_HYPERV_VTL_MODE is set=
.
See further comments about stubs in Patch 8 of this series.

>  #endif
>=20
>  #endif
> --
> 2.43.0
>=20


From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from BL0PR03CU003.outbound.protection.outlook.com (mail-eastusazolkn19012074.outbound.protection.outlook.com [52.103.11.74])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9895E40DFA5;
	Mon, 27 Apr 2026 05:39:44 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.103.11.74
ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1777268386; cv=fail; b=OyQ15lV0EFkrViyQnb5SOkjuRPgze4IOlVGGj2Fz9M/1EYnozkDYq3h1V9fGpVMKGF113dogT/78ZTJM5uBHAUaHBdWMHDs43mOdn81eYIlQcqii710cAPWsLECvIRR9cCSTkEl1ZTcl/pWGSU6wskXzUj82zxjrp/S2R2aQ5rE=
ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1777268386; c=relaxed/simple;
	bh=UB4TTRS/s9ehiZ1V1zKHwHEL/6PDGuTv1E6XdJui4Y8=;
	h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:
	 Content-Type:MIME-Version; b=mE9jVrPMH63vF2KWcv4eFkaPNzIbjth2A34wNwk7XJwcVQkis2vrzncBLkEeHqeokWyGJP7kmGVXQwODah9hO/K9Qyyr2X2PupX+ozxQFk1e0dEAZCp/DYy/tqDm60iu140o4RMieLmW6viMSAKORS3VDIRBfvYfIvNiMmE60JE=
ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=outlook.com; spf=pass smtp.mailfrom=outlook.com; dkim=pass (2048-bit key) header.d=outlook.com header.i=@outlook.com header.b=IpCMVBCf; arc=fail smtp.client-ip=52.103.11.74
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=outlook.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=outlook.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=outlook.com header.i=@outlook.com header.b="IpCMVBCf"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=wc1Xfj3xx8lP6PfbPG22SRqxNfc1d8ck0Q3ybDh3QexniF3Ptiqmv+sjGa7E4Tdry/KhyRPOSdSEGL5+XuI4STau1L0rcS3wDcsHHKB8FNqj+BxP/UWd3qf4dSKSPviYfLyERBZMm9WI4WJphq2FE33VNL41s/4WmeXhCw9AesC/V6masKGROv6WyzeYD1iiyYRZGcQABcUt6Zhp9QZUpCmnJVbrKmCSEwKRSWLSp3u2UkA636GQfHkXQrQJtaCo+8znsPb/CBHgd3VpzeimVOIj4avB0PsO22stxeQ0FfHJjIUFaAm3BO5iqcjESjb++zLjZclRAH9jNrq9+9a7tw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=39I98Eka6Y7j1KT33387jvDeua8mqkAfFVgVIee1a5s=;
 b=CvqFYmVTGknKWBS0LjZGQbgRKnAs7dNafudX8TzfKT4Uh32/omZwq1B0JfOVb4VOwXl7AZaVV1GSHaln/q8ckYX1T9yn7y5D7NiM/r6xGwqE1T+bjX7U/+HJ7AE5ERW4qmdpVWDKXwtuT+YlFlU6g1uGcCluZI4POX9Lf6Q1WRsmlj9Q7PYPP1LBPx1dmSlOZjzTQabEKoIUOqcuxLkLApEImXtZqh10RHO9TNKMWp7O++x/3tYQaCR+vHuFYZRlSj4frAbZRkYvW6GT2yeMbN+YO4CgVHRgKBYt8HShH6RprL1QvQQfemTwSBQq8jbky1Bm+K3T46arGEmq7maq2Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=39I98Eka6Y7j1KT33387jvDeua8mqkAfFVgVIee1a5s=;
 b=IpCMVBCfMCDo2c+arPqEbpv64vWTU1hwM+YOOw6gEeu61mH5T2CDdXGCHae8zzIjscI42n/adXLIJDgBvlq4V2zVyJNipKjMNRHvGHJeHxONpaTYPAxUMUKTfMS8PnQvPWreqxYu2CpIShroXjZKoeYUqUyFnb4hcQTay/YcbXR9u85LfEdpsZ1CWKGW20D3yQ8c9ZDQ86nvetmSec/su9TN8KBP/jO6/Fcx5cCkGZput/aHoCL+Vkz2SaXakmvPwEY8d90O9cS9hDgYt7AaBzPIHvZ4UvX0lBfC9A93m6bcFj3jCOwjdQYR+xtuO3T+thSoDeQOsKLxK6zVb+kH+w==
Received: from SN6PR02MB4157.namprd02.prod.outlook.com (2603:10b6:805:33::23)
 by CO6PR02MB7809.namprd02.prod.outlook.com (2603:10b6:303:a2::22) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9846.26; Mon, 27 Apr
 2026 05:39:41 +0000
Received: from SN6PR02MB4157.namprd02.prod.outlook.com
 ([fe80::900:1ccf:2b1e:52b6]) by SN6PR02MB4157.namprd02.prod.outlook.com
 ([fe80::900:1ccf:2b1e:52b6%6]) with mapi id 15.20.9846.025; Mon, 27 Apr 2026
 05:39:40 +0000
From: Michael Kelley <mhklinux@outlook.com>
To: Naman Jain <namjain@linux.microsoft.com>, "K . Y . Srinivasan"
	<kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu
	<wei.liu@kernel.org>, Dexuan Cui <decui@microsoft.com>, Long Li
	<longli@microsoft.com>, Catalin Marinas <catalin.marinas@arm.com>, Will
 Deacon <will@kernel.org>, Thomas Gleixner <tglx@kernel.org>, Ingo Molnar
	<mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, Dave Hansen
	<dave.hansen@linux.intel.com>, "x86@kernel.org" <x86@kernel.org>, "H . Peter
 Anvin" <hpa@zytor.com>, Arnd Bergmann <arnd@arndb.de>, Paul Walmsley
	<pjw@kernel.org>, Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou
	<aou@eecs.berkeley.edu>, Alexandre Ghiti <alex@ghiti.fr>, Michael Kelley
	<mhklinux@outlook.com>
CC: Marc Zyngier <maz@kernel.org>, Timothy Hayes <timothy.hayes@arm.com>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>, Sascha Bischoff
	<sascha.bischoff@arm.com>, mrigendrachaubey <mrigendra.chaubey@gmail.com>,
	"linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>, "linux-kernel@vger.kernel.org"
	<linux-kernel@vger.kernel.org>, "linux-arch@vger.kernel.org"
	<linux-arch@vger.kernel.org>, "linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>, "vdso@mailbox.org" <vdso@mailbox.org>,
	"ssengar@linux.microsoft.com" <ssengar@linux.microsoft.com>
Subject: RE: [PATCH v2 08/15] Drivers: hv: Move
 hv_call_(get|set)_vp_registers() declarations
Thread-Topic: [PATCH v2 08/15] Drivers: hv: Move
 hv_call_(get|set)_vp_registers() declarations
Thread-Index: AQHc0x7KhQKOv+E980uDaIJzKtjb97Xyaj0w
Date: Mon, 27 Apr 2026 05:39:40 +0000
Message-ID:
 <SN6PR02MB4157852404B5258EF13A5450D4362@SN6PR02MB4157.namprd02.prod.outlook.com>
References: <20260423124206.2410879-1-namjain@linux.microsoft.com>
 <20260423124206.2410879-9-namjain@linux.microsoft.com>
In-Reply-To: <20260423124206.2410879-9-namjain@linux.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: SN6PR02MB4157:EE_|CO6PR02MB7809:EE_
x-ms-office365-filtering-correlation-id: 458a4304-d75e-451f-9fb6-08dea41f60d2
x-microsoft-antispam:
 BCL:0;ARA:14566002|12121999013|51005399006|55001999006|16051099003|37011999003|13091999003|19101099003|461199028|41001999006|31061999003|19110799012|15080799012|8062599012|8060799015|40105399003|440099028|3412199025|102099032|1710799026;
x-microsoft-antispam-message-info:
 =?us-ascii?Q?tKo4W64Hf/Zx95Gmy3QZquUsjZgDgxcHvq4c0azxeTRfIQih6qViye5vgtlo?=
 =?us-ascii?Q?LlIifuvkOjtWWcPII5kjefroYddXfzue+cwVVsUk9kWTgpfwxcXTGh0NY8lQ?=
 =?us-ascii?Q?xY0EuLq2V8+65jdEKcnXPZJybQuNGjT8cW2g8/OaxJRATZPqGfFVH0ON1nIv?=
 =?us-ascii?Q?WBg+bdxU5MBitDfAIYM3U2B7j5cYay1qH5HLmzBhq/UilEjddfqHC8f224E5?=
 =?us-ascii?Q?gWzVCiFYgPLZsC2c17Qj+wXaOoff4PZM1jtsmEPrqgmBGtpOIVgodfu5OSzd?=
 =?us-ascii?Q?TDHHTt6zKWIabYivWrgEeNPFLDv/N13WaEn3OWTYmdwb8zv2b54hUgu4NARL?=
 =?us-ascii?Q?eXDInJpmoVO3w6azyfP8UcuscFda6fl1boaHdcjiQzXLipBkYTPPLYRslQ0r?=
 =?us-ascii?Q?7isEn9vXn2+V/4ovQ7cYZ/aSHqclqk0X+yQYd9AHMSYg4R0I56VLCb+o6YsA?=
 =?us-ascii?Q?jA3oamAm6tF0QuWYc1G9s5ZJ6sLZKeFBoHyyG9zmrlXA9jAgxWk8I4hl+jWc?=
 =?us-ascii?Q?aDercLPHCz4cskyvtHkKguArVJGOzQq/JoyaCXJ65j6F27t2eIUIJBDETMiE?=
 =?us-ascii?Q?WTxP+XNFk7T2XTP5fJUcrczwir63o+PNxPR3YbbpGhEKuhLI51516C/Hroz7?=
 =?us-ascii?Q?1T38lgAK4Gi4Iin8KTSy/GipGly5wGTwYCkCWFEc8wEkUgy7V3BRQFat9+ej?=
 =?us-ascii?Q?UMw4vHx8fRGn0oWVs2sD9Sh+X/YpCecS79QRU0S/QgWq3oMFBxmvUncGBQEY?=
 =?us-ascii?Q?kGuvQJSaJdDykY2SysVu+UeZ/a1JaZ7OUXV7SD7e1Rnb9tf9pBCH9/GUDTEx?=
 =?us-ascii?Q?wAOYQiTsPBnXMgo1rXa6oO1RGPkQgc6EsKgN4MlNeW/3Tveh093jMm7eXnoY?=
 =?us-ascii?Q?anv1q7DzNUsTzcxLQ4iIt8m1VBkxuWDpdLcBeN7qJ9E01PXQRUEtsJl/Xq1x?=
 =?us-ascii?Q?OoDoXRLSmmvO3opImHCQIUAHFyPELLMZgZswML/CF4ZQdOHLf0WNaR9HksW3?=
 =?us-ascii?Q?5nm8+EEMIbCovhk/FLJUY6dyyGvFrfiJAON0kK6x9/DeulvlA854Q80fqiCK?=
 =?us-ascii?Q?bjlPZa0aTM4nrWCXp1pzseCKrEHUPf0bD0HDPdA7Vbdtat8jA0FhuIyTbzVx?=
 =?us-ascii?Q?glaS741Tf9feuInKySs4LZKLIUakln5QKg=3D=3D?=
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?M6MpOWu8/hyA3/Mi9vemHKpvMKzh8zgHHpx4+I9oA6aRWEW982/8dVw0HvAL?=
 =?us-ascii?Q?dG/MQX9ZZ0D1KwZmkm1c5072akRa96Xk0EdVRCds5nuxbyRShsUZCYCysVV6?=
 =?us-ascii?Q?UXWIJje8BPyboZTi3u6FCOtpaCv6VsQlKaaFabEcefIUNeVAdsghblx0l96k?=
 =?us-ascii?Q?yIkcKULWbTECk7Nvvof+5TcUVi11EVJ7f++2cnzkJeOYumqupgZFPyA2kOGB?=
 =?us-ascii?Q?fJklJDMPH/iRqONTx5RnpOAFXhNx8f3EDHIrcQcGwoNKJkI2xrz8hO60aZC/?=
 =?us-ascii?Q?ridn1uuiOuqCUXqK2s+T7f+G6VyZJCNrvOdHD/i5/0UEc3mYfzY+jl+NRlKt?=
 =?us-ascii?Q?IemCZy60y0c9nh+LgvXuuYA20b7RLf2wbJfIjBI0475KotJZYC0+5C51I47j?=
 =?us-ascii?Q?cvB3lEp2LGb1VoDPbv5JvODJSgSh//cYH6miT6MlUItlYFtAcetJxxqBB23V?=
 =?us-ascii?Q?USs4l5nO85dj+VIAgrM4Nvfw1EpJ1ZmZLad+zm8O1B3Vq2r1K4ScfyKX+QYc?=
 =?us-ascii?Q?0rD+HrtZMLQ0pv+ObmZKQ4xuH9JDGNQZyWdcmf9r+5NvP/jzSoDuKPYFPyk3?=
 =?us-ascii?Q?qMBcuY9VtBo/RghwHtNZt2XSPd74yOoBGE0VdLJAr3Q4ct/VGMuXdl2CniLF?=
 =?us-ascii?Q?kYUAm7alP3F8r2d/XpNybNt6tb127AAjcLq4bvV3dFSx0G+AXEY3i1sBL0mP?=
 =?us-ascii?Q?al8f+wikEo098pb7VlpJJEz08dM2bz0/HM44JkGpcinaBHy6k+9FfzwogtJg?=
 =?us-ascii?Q?T5Hxe+J67F4yMJAGFjw8NlQP9k0ifeOJKHiZW0uheSY0xfrCjkxrxROuW2De?=
 =?us-ascii?Q?ndAL8PHi/Pfvw7NmT3Ui9lkagHvMrlD+G5F/qACb+1qeFNGtRWyt+HA1ipt0?=
 =?us-ascii?Q?RWCFCIWxBqt2OXh9aMSR5VLr7gkvDCAi6bDIq12/l8XEupX1P4RnHlQKW3c5?=
 =?us-ascii?Q?tLvp1XaT81bYC/2CwyQ7GZNJufiIWbAGJjUzylGbFdvxOXq8xfQANihLNkiI?=
 =?us-ascii?Q?dRTO07IXAVUcU7XrlAq46i310/H4gzPCfEBQGrS7DCFAFAP+MIm8j87jaNPV?=
 =?us-ascii?Q?GkY47TAfREgq2lcFXIDycL0JToK849emRy4DbOOps5b3XD7r6WPTtszttK8r?=
 =?us-ascii?Q?UrcXJoxE/NPD5hCJqSHB9+tZrx/GCqPws9reW0ofSGNKA3UAvX3gJyUpQ2Mk?=
 =?us-ascii?Q?msR9+pqUNlVnqAEXs7emvP1poXPmW0fOecfnRoWjYJpwsba85VrwuCjoA42S?=
 =?us-ascii?Q?2WZDRUCLJvogi6OaTxT/KOodT0kQyQPoTSaSvkHovmQ6s+S2ygmZEcMK+0fn?=
 =?us-ascii?Q?aLOxIfg9SmgkI6zD3of/BKSRjRoCcT9IbDcswVcOqRK0UyCcC0Gf5mGEsCRJ?=
 =?us-ascii?Q?00SxF2c=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
X-Mailing-List: linux-arch@vger.kernel.org
List-Id: <linux-arch.vger.kernel.org>
List-Subscribe: <mailto:linux-arch+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-arch+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SN6PR02MB4157.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 458a4304-d75e-451f-9fb6-08dea41f60d2
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2026 05:39:40.8138
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO6PR02MB7809

From: Naman Jain <namjain@linux.microsoft.com> Sent: Thursday, April 23, 20=
26 5:42 AM
>=20
> Move hv_call_get_vp_registers() and hv_call_set_vp_registers()
> declarations from drivers/hv/mshv.h to include/asm-generic/mshyperv.h.
>=20
> These functions are defined in mshv_common.c and are going to be called
> from both drivers/hv/ and arch/x86/hyperv/hv_vtl.c. The latter never
> included mshv.h, relying on implicit declaration visibility. Moving the
> declarations to the arch-generic Hyper-V header makes them properly
> visible to all architecture-specific callers.
>=20
> Provide static inline stubs returning -EOPNOTSUPP when neither
> CONFIG_MSHV_ROOT nor CONFIG_MSHV_VTL is enabled.

Looking at the drivers/hv/Kconfig, it's possible to build with
CONFIG_HYPERV_VTL_MODE=3Dy, but not CONFIG_MSHV_VTL. In such a
case, mshv_common.o doesn't get built, which is why the stubs are
needed. Is such a configuration desirable for some scenarios?

I wonder if having CONFIG_HYPERV_VTL_MODE force the building of
mshv_common.o would be a better approach. Then the stubs wouldn't
be needed. The "ifneq" statement in drivers/hv/Makefile could use
CONFIG_HYPERV_VTL_MODE instead of CONFIG_MSHV_VTL, and
everything would be good since CONFIG_MSHV_VTL depends on
CONFIG_HYPERV_VTL_MODE.

>=20
> Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
> ---
>  drivers/hv/mshv.h              |  8 --------
>  include/asm-generic/mshyperv.h | 26 ++++++++++++++++++++++++++
>  2 files changed, 26 insertions(+), 8 deletions(-)
>=20
> diff --git a/drivers/hv/mshv.h b/drivers/hv/mshv.h
> index d4813df92b9c..0fcb7f9ba6a9 100644
> --- a/drivers/hv/mshv.h
> +++ b/drivers/hv/mshv.h
> @@ -14,14 +14,6 @@
>  	memchr_inv(&((STRUCT).MEMBER), \
>  		   0, sizeof_field(typeof(STRUCT), MEMBER))
>=20
> -int hv_call_get_vp_registers(u32 vp_index, u64 partition_id, u16 count,
> -			     union hv_input_vtl input_vtl,
> -			     struct hv_register_assoc *registers);
> -
> -int hv_call_set_vp_registers(u32 vp_index, u64 partition_id, u16 count,
> -			     union hv_input_vtl input_vtl,
> -			     struct hv_register_assoc *registers);
> -
>  int hv_call_get_partition_property(u64 partition_id, u64 property_code,
>  				   u64 *property_value);
>=20
> diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyper=
v.h
> index 8cdf2a9fbdfb..ef0b9466808c 100644
> --- a/include/asm-generic/mshyperv.h
> +++ b/include/asm-generic/mshyperv.h
> @@ -394,6 +394,32 @@ static inline int hv_deposit_memory(u64 partition_id=
, u64
> status)
>  	return hv_deposit_memory_node(NUMA_NO_NODE, partition_id, status);
>  }
>=20
> +#if IS_ENABLED(CONFIG_MSHV_ROOT) || IS_ENABLED(CONFIG_MSHV_VTL)
> +int hv_call_get_vp_registers(u32 vp_index, u64 partition_id, u16 count,
> +			     union hv_input_vtl input_vtl,
> +			     struct hv_register_assoc *registers);
> +
> +int hv_call_set_vp_registers(u32 vp_index, u64 partition_id, u16 count,
> +			     union hv_input_vtl input_vtl,
> +			     struct hv_register_assoc *registers);
> +#else
> +static inline int hv_call_get_vp_registers(u32 vp_index, u64 partition_i=
d,
> +					   u16 count,
> +					   union hv_input_vtl input_vtl,
> +					   struct hv_register_assoc *registers)
> +{
> +	return -EOPNOTSUPP;
> +}
> +
> +static inline int hv_call_set_vp_registers(u32 vp_index, u64 partition_i=
d,
> +					   u16 count,
> +					   union hv_input_vtl input_vtl,
> +					   struct hv_register_assoc *registers)
> +{
> +	return -EOPNOTSUPP;
> +}
> +#endif /* CONFIG_MSHV_ROOT || CONFIG_MSHV_VTL */
> +
>  #if IS_ENABLED(CONFIG_HYPERV_VTL_MODE)
>  u8 __init get_vtl(void);
>  void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0);
> --
> 2.43.0
>=20


From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from CH1PR05CU001.outbound.protection.outlook.com (mail-northcentralusazolkn19010003.outbound.protection.outlook.com [52.103.20.3])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1F0D3223708;
	Mon, 27 Apr 2026 05:40:37 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.103.20.3
ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1777268439; cv=fail; b=Cw9Mgzkji+PREGFBJP5dzB0NajFwJigYOhLoi9NBvBYxtJ3ZXiEtsSscO4wAjfnXDxSqVeFzV2DkEIOQ4jXDLMZ3iyjhxgYNmgKxoW+QMRlEpUPrSG5r0Mrsi/b5t8c8fqj0+GNbIOz0fPorIn5iVRrRss+4oIunXHfkyz1qRuM=
ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1777268439; c=relaxed/simple;
	bh=4+tg069iYj8T/3KGPUn3WlAfB1xTIpkXdJwvXi2ybaA=;
	h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:
	 Content-Type:MIME-Version; b=nX4WzOUSFs2YTst9Ph6utwVW0RFZet4/eFABmNEZ1V8I4vrVfjff2LJSUmoQg3BgLkATjkRytVSgbBps13YU/BQUEGiSyNnGteqbi/D6t2C6AlJZPjAzOmyoQlsGBO+wJyDxa2zBxe08Wkd5svgbO0mFE7y38T3ko4+BoKWrqsI=
ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=outlook.com; spf=pass smtp.mailfrom=outlook.com; dkim=pass (2048-bit key) header.d=outlook.com header.i=@outlook.com header.b=ZQ83An0s; arc=fail smtp.client-ip=52.103.20.3
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=outlook.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=outlook.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=outlook.com header.i=@outlook.com header.b="ZQ83An0s"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=rWDci0pO8ET0A2YlQUttamFAAiT4wjiFpZI3E6pRbwLu+7bHDGv6PZ473CP92cgCh8/n9dq/BIdhWfOiNwEFYatFIZmj619tSIfTgrnx6ArU3Ex54TO6oPfwZToon6SPpcK6VyrV/RtMSlJq25icRT9Tn2j45nZzCIbWAviHrTyrL+fkd34szJ7N+JWwkygKcFwuivFJZbut/sc/b2qUYenuyZiMkx2JdOsZ9rwk92aOfcRkULqrBmwGSHlNBDKgUiBv/lm3tmXsJkKw5pGcCf0ot+K/JtHb/pimgjKZAxdWdfqc5eiJnIt79F8quubP3+SVhaGYjuWx2WqCE4d0vg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=dT+z93y9Cx/sUn1qPXeDCaz74u0OsQiX9nCyVqCiBG4=;
 b=mfWYIAF3GcwBy22ewvEWt2FlTY+jCAUH0QFl4WcD9ljhn4fheHEQNcarem9gDC7yyOYIivI1VXdhfOFh1tnb8mJhhLPj8XNppQ7geael11L3V2LOMREMtjenjC8Sx3NhW0rYzRiJL26ijoGjAmK4GWxNp6X8ARw+0WDEUSvJW6CbzyXvjZEvJA5OfKjSH75nF2oe8wPkURAzz3KOPZ8AZ2KHZ7BaHpuwlURygQWFKcaIXJsZuutln+xTde3zl28FmZwPVLgs1VBqkjQNFqAqw6FjkZj+q0zeEdbA+Bk+15NARyTfqxbmNvg0USQR3A0Re23MUwsZK2SjVYGXcTysVA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=dT+z93y9Cx/sUn1qPXeDCaz74u0OsQiX9nCyVqCiBG4=;
 b=ZQ83An0suaQCL+37ueSyjXANctCHgOr+0Nyi3sgYREJE8/oSMiQEi4EhAXwDOW47sascVwcXaAUldJE7F1Su5xbsSgRCbuivLX4wK8baCXhmitJcWDSzY+JgZJmNsAMFG50uwta+YCpDS3sTj3jW2LnzQ50GctA8sks4sW4seA0iqCiMC3eI9a1Sl5q4q0oazDDYaT0ukMn800F2oPNBdP6KGyfX2hyvD1c2pO8u9RtBlmMErBkIzOhRDUnK9N9fOQDhP1+gCkYzazxdEIdPJdpLhBn2I3l6SVKBdyDTzx6kAGR8axDFe8jCwS+sjCph13YOjBcTvWG3gmlXDZRFtw==
Received: from SN6PR02MB4157.namprd02.prod.outlook.com (2603:10b6:805:33::23)
 by CO6PR02MB7809.namprd02.prod.outlook.com (2603:10b6:303:a2::22) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9846.26; Mon, 27 Apr
 2026 05:40:34 +0000
Received: from SN6PR02MB4157.namprd02.prod.outlook.com
 ([fe80::900:1ccf:2b1e:52b6]) by SN6PR02MB4157.namprd02.prod.outlook.com
 ([fe80::900:1ccf:2b1e:52b6%6]) with mapi id 15.20.9846.025; Mon, 27 Apr 2026
 05:40:34 +0000
From: Michael Kelley <mhklinux@outlook.com>
To: Naman Jain <namjain@linux.microsoft.com>, "K . Y . Srinivasan"
	<kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu
	<wei.liu@kernel.org>, Dexuan Cui <decui@microsoft.com>, Long Li
	<longli@microsoft.com>, Catalin Marinas <catalin.marinas@arm.com>, Will
 Deacon <will@kernel.org>, Thomas Gleixner <tglx@kernel.org>, Ingo Molnar
	<mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, Dave Hansen
	<dave.hansen@linux.intel.com>, "x86@kernel.org" <x86@kernel.org>, "H . Peter
 Anvin" <hpa@zytor.com>, Arnd Bergmann <arnd@arndb.de>, Paul Walmsley
	<pjw@kernel.org>, Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou
	<aou@eecs.berkeley.edu>, Alexandre Ghiti <alex@ghiti.fr>, Michael Kelley
	<mhklinux@outlook.com>
CC: Marc Zyngier <maz@kernel.org>, Timothy Hayes <timothy.hayes@arm.com>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>, Sascha Bischoff
	<sascha.bischoff@arm.com>, mrigendrachaubey <mrigendra.chaubey@gmail.com>,
	"linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>, "linux-kernel@vger.kernel.org"
	<linux-kernel@vger.kernel.org>, "linux-arch@vger.kernel.org"
	<linux-arch@vger.kernel.org>, "linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>, "vdso@mailbox.org" <vdso@mailbox.org>,
	"ssengar@linux.microsoft.com" <ssengar@linux.microsoft.com>
Subject: RE: [PATCH v2 09/15] Drivers: hv: mshv_vtl: Move
 hv_vtl_configure_reg_page() to x86
Thread-Topic: [PATCH v2 09/15] Drivers: hv: mshv_vtl: Move
 hv_vtl_configure_reg_page() to x86
Thread-Index: AQHc0x7PKig5dZReokG7sAarwbgXxbXyan2Q
Date: Mon, 27 Apr 2026 05:40:34 +0000
Message-ID:
 <SN6PR02MB4157467FDBC0203C67A67042D4362@SN6PR02MB4157.namprd02.prod.outlook.com>
References: <20260423124206.2410879-1-namjain@linux.microsoft.com>
 <20260423124206.2410879-10-namjain@linux.microsoft.com>
In-Reply-To: <20260423124206.2410879-10-namjain@linux.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: SN6PR02MB4157:EE_|CO6PR02MB7809:EE_
x-ms-office365-filtering-correlation-id: 37aeab86-ff90-4135-4a9d-08dea41f80ba
x-microsoft-antispam:
 BCL:0;ARA:14566002|2604032031799003|704163111799003|51005399006|55001999006|16051099003|37011999003|13091999003|19101099003|461199028|41001999006|31061999003|19110799012|15080799012|8062599012|8060799015|40105399003|440099028|3412199025|102099032|12091999003|1710799026;
x-microsoft-antispam-message-info:
 =?us-ascii?Q?AKL/g+f4vGVwEPDTueqs/0pGD5sdTrnsk+5xb88LvCiK5B80QBCyULhHWD/F?=
 =?us-ascii?Q?EaoU+pVHbC96tRteibtjuceS8/bKikSY9cRxCFKZFbVMJ0BfQyGOLENKcOuP?=
 =?us-ascii?Q?nIoWdrpWT7f1Z4zHRNJ8+IQgXrX/3HM7bvkUNLttDVDK5ssL61F54smtcb/e?=
 =?us-ascii?Q?uQKw8qe81sUcYck/+3JSCmGPqmLlyu+WP2aUq+xVmBwgT8aCRWCjPKZMgolG?=
 =?us-ascii?Q?Cprgapyr0w0NA/WtcoBY5nRrDYZsfiwAj5dgdKaB+K3A7ZQ1D6V5+8Tdsa3s?=
 =?us-ascii?Q?6E5iyfoUah+lWZSblJtx58LFudW07ovP08vsPbknTq6mQPt9KMaRUQ1IWbja?=
 =?us-ascii?Q?Um5f0lUFU2Vb6GtYRFQVz6U91bIbApT55bI6dZ0CgTid1RcI9syBUhhhY839?=
 =?us-ascii?Q?nyrewVgqkaB91A2g6SyvvipVIu3tOYM99l+2/GOlEbMvCIzFeO5ABATYL5V2?=
 =?us-ascii?Q?/Ck0zqxK+jG8G8mUoOimVcC7zDBaE5hkGJqmSSS0mBbae3vYneJ3uZ7dXAbx?=
 =?us-ascii?Q?8HNJuDuRl6+5W4tpjsBfa/uj4f9xnTiiqhUviJyxqdRz51nLghuL+97Zrhkc?=
 =?us-ascii?Q?LqOnbUKMv11aAWULHIcW33UGktSXDgGXpiFwMfNcjL3on1GlRq/cV+0HnmHR?=
 =?us-ascii?Q?ghm4FSaiDgqGIGghauvISbeN+Nq42lj1N9WZqX0CzAC6QpSLOYgAPf82c1z1?=
 =?us-ascii?Q?Aa3OHmJdSvuXVk2r+W5DcCcyp8uFKMPR1QM8NYz8Tltj3uNTAcbKPE/VElDY?=
 =?us-ascii?Q?PaHAUieYeRPjrF14jpqDA+jCuX2y57Ul8vDEJcu8jpW8s0Thfg2DIvK8iopv?=
 =?us-ascii?Q?xIVPVonymyGi77PZ6CNWpDlt9E4ugq60NdSXGMr4uFGEPv8aeFfFUmxOpTbu?=
 =?us-ascii?Q?lnIO3PhpPlMVKaP0csn+c6olLfAQj31bThUf1DQKA3e8nbrZJleF756vIMkx?=
 =?us-ascii?Q?7E0RTtLCM42DYh6qydPXn3WADkJlV3d8RqfRDcISmizdJhPWrlYRFrL0btiK?=
 =?us-ascii?Q?iWD3sJMnP0CIyQIUbPbr574CKOOVH0Swkggx0dtS1mtu1HziGm6xeg8hql6u?=
 =?us-ascii?Q?rTY/z1oAwn7ENV3FYqWM27UBPC13EKxDMWevaAfcCzO9Zr6PYcbYuVc4qeCL?=
 =?us-ascii?Q?zk9T3ShH/psbYHFYY39WUQNvNlbd3GzGyVT6lUpgAHVZa42p09Sc/CTKf7CS?=
 =?us-ascii?Q?yv58L1Ho3S0IPECwZ1S1NbstydeWlpWqYUzy/MkqMDUTGtm747kN2Uugdxw?=
 =?us-ascii?Q?=3D?=
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?kGQuidTo/ftXD6Na41g1hdy/k/qIgjSfw37YAvg9wq17XZRVenDh8laVwap1?=
 =?us-ascii?Q?XKS7mnidFMSIwadHSZGCoVgka+EdhuyeMrmRg7/x0iEzRa0UreCUwZCSa6P0?=
 =?us-ascii?Q?RtGzMQHn/ir7KX+vM0Pd2bCCl0Nm/7orbLcpSa96h/kRvVk5Y1DPo9U4CGx7?=
 =?us-ascii?Q?HT/6LvmIyvC5u80FIq7CBw9k6GI41QNnsHSmOGbPgd2bBj/NyG6cV+v6/epg?=
 =?us-ascii?Q?g9Wki1cmEfrn93JVeUA0V5MC/oGKYIrA3IXpMeVpxQwg/m0vYo+rWoVfmZ1c?=
 =?us-ascii?Q?KCejlCNN4gA8UvjhAFPi6V1zCL9lJ05rZwHXktW1cnL6VJEyHRWVr8xl0xY6?=
 =?us-ascii?Q?pghjFmhJ0j0qGuLLim6qgYuykP9XIcekG/XVxXhgjffzKjhHCKakWwedM49M?=
 =?us-ascii?Q?tU/fXesV3liwwPIqS2VQ1MsYTF5yqlVWEynk/9qZpygyX4OyKzMWPqS8WCpx?=
 =?us-ascii?Q?eNdhEH+m8HsaLr27uGKpO7JVinh//QB4AVvwtJIdHGKuIlPlAH+q8IrxBQVF?=
 =?us-ascii?Q?YyzUXW+lUq8VZkSKJW0EoqlxkHpiJDbKbHotMqlmmomCGNtrWFmxxsm8PpK0?=
 =?us-ascii?Q?3NeYWNQPQjYw4pgMSibpn+rkII8A4V6tcOHibAbEBCDEDGCgnWVTBMZvqlCN?=
 =?us-ascii?Q?22gm9i5mJmZWZ3m5qQOmuIM9EXThW+QBit+mxqtKEWBoiDmwK1lgcD9oboSn?=
 =?us-ascii?Q?oLuG0FqURGLE/p5LWUYKD4x+CjxEGE9FbeWop+6QQEV2BIoHlNPGcLtVQHcu?=
 =?us-ascii?Q?k7saBOzcgvtGeBWDiW9pPV/hHnqiIkf93qegnHYcwaBijD0bJsTzHEW3Eax1?=
 =?us-ascii?Q?GR8pzdW4j1Yays1GyxT6vvur6CG/99KIrH/+PZlM5E9DBYuk+AaeVV1lXRWP?=
 =?us-ascii?Q?ZuQuzSVp7B0iJ0DU7DvIk+bZhJWhgR7DNKFhqyzJqIxHlkncHKlO/l5/2pJr?=
 =?us-ascii?Q?keMU/k50bZJc5kpu/GO5fYRjRFQ5vdKZB2ZRj5SNR+U8cU8J/gHBlYG7QUDF?=
 =?us-ascii?Q?MWRjCMqiU3S/RpF05GStEWYturPj3eBMtV/Y+T5+4+/vlK/lhcuF22DU//9c?=
 =?us-ascii?Q?ehV0rFIxbFsEUGpsKlxmFssgJcVaBrn1tWvljxNrrlHh3kahbPgtEm/U+i/S?=
 =?us-ascii?Q?j5vDZK/iICnb39doDARebHXqJLVMUpD5Lb+/hCpwk1fry4ICmQ3VGFLvnmXr?=
 =?us-ascii?Q?IgL2uNSZuwEfF3b9M8USuSBO+/dD3zORU/bBb6n1xQqRCn4nn+UiPDBf9IdD?=
 =?us-ascii?Q?ggky0QU/AddpRditPrah52AAip1pgjq/261atDuSU462nvokwVNm1+HvbsjP?=
 =?us-ascii?Q?SEL7bSx3U+/FHFXudIcARsEl6X4sSbwRKmsUgYvbDqzzNRiEl+csQq31dKMK?=
 =?us-ascii?Q?07tPWRk=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
X-Mailing-List: linux-arch@vger.kernel.org
List-Id: <linux-arch.vger.kernel.org>
List-Subscribe: <mailto:linux-arch+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-arch+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SN6PR02MB4157.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 37aeab86-ff90-4135-4a9d-08dea41f80ba
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2026 05:40:34.3525
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO6PR02MB7809

From: Naman Jain <namjain@linux.microsoft.com> Sent: Thursday, April 23, 20=
26 5:42 AM
>=20
> Move hv_vtl_configure_reg_page() from drivers/hv/mshv_vtl_main.c to
> arch/x86/hyperv/hv_vtl.c. The register page overlay is an x86-specific
> feature that uses HV_X64_REGISTER_REG_PAGE, so its configuration belongs
> in architecture-specific code.
>=20
> Move struct mshv_vtl_per_cpu and union hv_synic_overlay_page_msr to
> include/asm-generic/mshyperv.h so they are visible to both arch and
> driver code.
>=20
> Change the return type from void to bool so the caller can determine
> whether the register page was successfully configured and set
> mshv_has_reg_page accordingly.
>=20
> Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
> ---
>  arch/x86/hyperv/hv_vtl.c       | 32 ++++++++++++++++++++++
>  drivers/hv/mshv_vtl_main.c     | 49 +++-------------------------------
>  include/asm-generic/mshyperv.h | 17 ++++++++++++
>  3 files changed, 53 insertions(+), 45 deletions(-)
>=20
> diff --git a/arch/x86/hyperv/hv_vtl.c b/arch/x86/hyperv/hv_vtl.c
> index 09d81f9b853c..f3ffb6a7cb2d 100644
> --- a/arch/x86/hyperv/hv_vtl.c
> +++ b/arch/x86/hyperv/hv_vtl.c
> @@ -20,6 +20,7 @@
>  #include <uapi/asm/mtrr.h>
>  #include <asm/debugreg.h>
>  #include <linux/export.h>
> +#include <linux/hyperv.h>
>  #include <../kernel/smpboot.h>
>  #include "../../kernel/fpu/legacy.h"
>=20
> @@ -259,6 +260,37 @@ int __init hv_vtl_early_init(void)
>  	return 0;
>  }
>=20
> +static const union hv_input_vtl input_vtl_zero;
> +
> +bool hv_vtl_configure_reg_page(struct mshv_vtl_per_cpu *per_cpu)
> +{
> +	struct hv_register_assoc reg_assoc =3D {};
> +	union hv_synic_overlay_page_msr overlay =3D {};
> +	struct page *reg_page;
> +
> +	reg_page =3D alloc_page(GFP_KERNEL | __GFP_ZERO | __GFP_RETRY_MAYFAIL);
> +	if (!reg_page) {
> +		WARN(1, "failed to allocate register page\n");
> +		return false;
> +	}
> +
> +	overlay.enabled =3D 1;
> +	overlay.pfn =3D page_to_hvpfn(reg_page);
> +	reg_assoc.name =3D HV_X64_REGISTER_REG_PAGE;
> +	reg_assoc.value.reg64 =3D overlay.as_uint64;
> +
> +	if (hv_call_set_vp_registers(HV_VP_INDEX_SELF, HV_PARTITION_ID_SELF,
> +				     1, input_vtl_zero, &reg_assoc)) {
> +		WARN(1, "failed to setup register page\n");
> +		__free_page(reg_page);
> +		return false;
> +	}
> +
> +	per_cpu->reg_page =3D reg_page;
> +	return true;
> +}
> +EXPORT_SYMBOL_GPL(hv_vtl_configure_reg_page);
> +
>  DEFINE_STATIC_CALL_NULL(__mshv_vtl_return_hypercall, void (*)(void));
>=20
>  void mshv_vtl_return_call_init(u64 vtl_return_offset)
> diff --git a/drivers/hv/mshv_vtl_main.c b/drivers/hv/mshv_vtl_main.c
> index 91517b45d526..c79d24317b8e 100644
> --- a/drivers/hv/mshv_vtl_main.c
> +++ b/drivers/hv/mshv_vtl_main.c
> @@ -78,21 +78,6 @@ struct mshv_vtl {
>  	u64 id;
>  };
>=20
> -struct mshv_vtl_per_cpu {
> -	struct mshv_vtl_run *run;
> -	struct page *reg_page;
> -};
> -
> -/* SYNIC_OVERLAY_PAGE_MSR - internal, identical to hv_synic_simp */
> -union hv_synic_overlay_page_msr {
> -	u64 as_uint64;
> -	struct {
> -		u64 enabled: 1;
> -		u64 reserved: 11;
> -		u64 pfn: 52;
> -	} __packed;
> -};
> -
>  static struct mutex mshv_vtl_poll_file_lock;
>  static union hv_register_vsm_page_offsets mshv_vsm_page_offsets;
>  static union hv_register_vsm_capabilities mshv_vsm_capabilities;
> @@ -201,34 +186,6 @@ static struct page *mshv_vtl_cpu_reg_page(int cpu)
>  	return *per_cpu_ptr(&mshv_vtl_per_cpu.reg_page, cpu);
>  }
>=20
> -static void mshv_vtl_configure_reg_page(struct mshv_vtl_per_cpu *per_cpu=
)
> -{
> -	struct hv_register_assoc reg_assoc =3D {};
> -	union hv_synic_overlay_page_msr overlay =3D {};
> -	struct page *reg_page;
> -
> -	reg_page =3D alloc_page(GFP_KERNEL | __GFP_ZERO | __GFP_RETRY_MAYFAIL);
> -	if (!reg_page) {
> -		WARN(1, "failed to allocate register page\n");
> -		return;
> -	}
> -
> -	overlay.enabled =3D 1;
> -	overlay.pfn =3D page_to_hvpfn(reg_page);
> -	reg_assoc.name =3D HV_X64_REGISTER_REG_PAGE;
> -	reg_assoc.value.reg64 =3D overlay.as_uint64;
> -
> -	if (hv_call_set_vp_registers(HV_VP_INDEX_SELF, HV_PARTITION_ID_SELF,
> -				     1, input_vtl_zero, &reg_assoc)) {
> -		WARN(1, "failed to setup register page\n");
> -		__free_page(reg_page);
> -		return;
> -	}
> -
> -	per_cpu->reg_page =3D reg_page;
> -	mshv_has_reg_page =3D true;
> -}
> -
>  static void mshv_vtl_synic_enable_regs(unsigned int cpu)
>  {
>  	union hv_synic_sint sint;
> @@ -329,8 +286,10 @@ static int mshv_vtl_alloc_context(unsigned int cpu)
>  	if (!per_cpu->run)
>  		return -ENOMEM;
>=20
> -	if (mshv_vsm_capabilities.intercept_page_available)
> -		mshv_vtl_configure_reg_page(per_cpu);
> +	if (mshv_vsm_capabilities.intercept_page_available) {
> +		if (hv_vtl_configure_reg_page(per_cpu))
> +			mshv_has_reg_page =3D true;
> +	}
>=20
>  	mshv_vtl_synic_enable_regs(cpu);
>=20
> diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyper=
v.h
> index ef0b9466808c..9e86178c182e 100644
> --- a/include/asm-generic/mshyperv.h
> +++ b/include/asm-generic/mshyperv.h
> @@ -420,12 +420,29 @@ static inline int hv_call_set_vp_registers(u32 vp_i=
ndex, u64
> partition_id,
>  }
>  #endif /* CONFIG_MSHV_ROOT || CONFIG_MSHV_VTL */
>=20
> +struct mshv_vtl_per_cpu {
> +	struct mshv_vtl_run *run;
> +	struct page *reg_page;
> +};
> +
>  #if IS_ENABLED(CONFIG_HYPERV_VTL_MODE)
> +/* SYNIC_OVERLAY_PAGE_MSR - internal, identical to hv_synic_simp */

This comment pre-dates your patch, but I don't understand the point
it is trying to make. The comment is factually true, but I don't know
why calling that out is relevant. The REG_PAGE MSR seems to be
conceptually separate and distinct from the SIMP MSR, so the fact
that the layouts are the same is just a coincidence. Or is there some
relationship between the two MSRs that I'm not aware of, and the
comment is trying (and failing?) to point out?

> +union hv_synic_overlay_page_msr {
> +	u64 as_uint64;
> +	struct {
> +		u64 enabled: 1;
> +		u64 reserved: 11;
> +		u64 pfn: 52;
> +	} __packed;
> +};
> +
>  u8 __init get_vtl(void);
>  void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0);
> +bool hv_vtl_configure_reg_page(struct mshv_vtl_per_cpu *per_cpu);
>  #else
>  static inline u8 get_vtl(void) { return 0; }
>  static inline void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl=
0) {}
> +static inline bool hv_vtl_configure_reg_page(struct mshv_vtl_per_cpu *pe=
r_cpu) { return false; }

As with Patch 8, if CONFIG_HYPERV_VTL_MODE caused mshv_common.o
to be built, this stub wouldn't be needed.

>  #endif
>=20
>  #endif
> --
> 2.43.0
>=20


From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from BL2PR02CU003.outbound.protection.outlook.com (mail-eastusazolkn19011008.outbound.protection.outlook.com [52.103.1.8])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id EFCC431AAAA;
	Mon, 27 Apr 2026 05:40:55 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.103.1.8
ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1777268457; cv=fail; b=M2nE4I9THzD4XjzrilHjA2XBzAOSXdSXoGoARTAgSOvh3gg4n9DllDORapYAvzuoq/Ioe6ERXUWjBf7X0ryKU93ZKv2jpMx7orJC+mj7YEaCT4y19xslWJyLqFKSWqy6QczdQj9m5Urtd39MgRVzIC7x4tMv16OPfbYRJvDSF/4=
ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1777268457; c=relaxed/simple;
	bh=hENXaIKAj7JUwz4/RSXRU1vyxsfWfcd2p4WIhfubHLY=;
	h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:
	 Content-Type:MIME-Version; b=D9Ua+57780SmH9dPnCB1Sow73/D/CJLhcfPn5BasW4gJ9LhGysW/K7oZ6G/vT/wYdKtsToeCnYdWiNiUQdhGQOHzyqp4SVKLoXKmrrRlnbXl9hdPkqBh1BAMRExtKZHwIeGxxYV+4kyIwNiamuHH/SYqivJa6G+nGlfH+L0jqYg=
ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=outlook.com; spf=pass smtp.mailfrom=outlook.com; dkim=pass (2048-bit key) header.d=outlook.com header.i=@outlook.com header.b=cuUIpWIH; arc=fail smtp.client-ip=52.103.1.8
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=outlook.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=outlook.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=outlook.com header.i=@outlook.com header.b="cuUIpWIH"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=Veu21Ec1ksh5PnRMniiAjIjUfe5VNLwXgkA2mU2TCUS6cjkxNL7mjB/xgv6uv6pyYP7HVmNV6fT7/fSxkkILge8ykbvZsvKSzy9w5s2JCXV2H4FjeykIxFbJFfCoDbtAbNhzSDgdWRf43OnUvdzJ0esI4o63VBbBhfR34edqAal20MnZI3gJI90bfYI9iLVeMYWoKeY4B8wF0TwkKS8GabXdZFt/oIB7idirMKWn2PNfkRoLHBF5zcrNu98nzDf5kXNGLtqHSPnkh5iexbPT6V6DfArXbO36Lkj1+X2KhZEPLfinYWqAskZl7VyzAYPVHYKnldhvld6/lfuP8JJIzw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=lAWuHYP5PjwxCYpcv50N32lDLH65mOubH0uDSpPgD90=;
 b=WXjWqljH4jPGG8beCrN3rRGaN7ePs0zMB7vZaxHnPVE0w5fXwspXnlVS6YsYi5A8fUlhvWWk51zsaA6/96DqljDZaSIcVXeZBqvulhd3DoowpgLqDGI3Sydb4tNLd7Cdzplmel/Q/LTiJBCCnEKTTM6Z6NQSScERnS7bibbiFJsyCZsh8jWeAxj8Ip+EfoW6LkRqT8u1wTyBmp9cEkD/hmq4JYoOHuT4TD9Pm4ettk0728S/PO7eGmvNWFnuFHJEI3OeY5G1JcdsvxlvNDfFosZ6u/B7Kw2zun+1tCadDw/sOyZ9IPCAXx0dUy2bH1dX+P0n3rVzT8APIOlNk10i7g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=lAWuHYP5PjwxCYpcv50N32lDLH65mOubH0uDSpPgD90=;
 b=cuUIpWIHHYmiMLrRvj2nkCL8e8lS7Zu2+uynJWe/Xdvu/MK11kS+Lk9UPEaF9i4stTv2w1PoAA1GUFYyzAy/p4ZWaNTEFhtLQhOI/sliVpdmOkVt4+JusDU8BRRagjDQ8WsjIkfzBlxdVIphDN0jOBcWhpHgsOApsltCwU3l8wBuYBWjEOJE11kGad7+0N+lPat6UiSS6VRIDkBIRq4ROyMZgNeYsOidOKg0S4/Yns/TeUA+1FlosCCEVz7CMoV6NSvKrVZZndzxQ0qFNKtjb8BjN8dCLcNRofy/LRLs+fh/fDF+AIUfb7DDMTZUk4TvyhRSqMn2g+DAsERhmwbllQ==
Received: from SN6PR02MB4157.namprd02.prod.outlook.com (2603:10b6:805:33::23)
 by CO6PR02MB7809.namprd02.prod.outlook.com (2603:10b6:303:a2::22) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9846.26; Mon, 27 Apr
 2026 05:40:52 +0000
Received: from SN6PR02MB4157.namprd02.prod.outlook.com
 ([fe80::900:1ccf:2b1e:52b6]) by SN6PR02MB4157.namprd02.prod.outlook.com
 ([fe80::900:1ccf:2b1e:52b6%6]) with mapi id 15.20.9846.025; Mon, 27 Apr 2026
 05:40:52 +0000
From: Michael Kelley <mhklinux@outlook.com>
To: Naman Jain <namjain@linux.microsoft.com>, "K . Y . Srinivasan"
	<kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu
	<wei.liu@kernel.org>, Dexuan Cui <decui@microsoft.com>, Long Li
	<longli@microsoft.com>, Catalin Marinas <catalin.marinas@arm.com>, Will
 Deacon <will@kernel.org>, Thomas Gleixner <tglx@kernel.org>, Ingo Molnar
	<mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, Dave Hansen
	<dave.hansen@linux.intel.com>, "x86@kernel.org" <x86@kernel.org>, "H . Peter
 Anvin" <hpa@zytor.com>, Arnd Bergmann <arnd@arndb.de>, Paul Walmsley
	<pjw@kernel.org>, Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou
	<aou@eecs.berkeley.edu>, Alexandre Ghiti <alex@ghiti.fr>, Michael Kelley
	<mhklinux@outlook.com>
CC: Marc Zyngier <maz@kernel.org>, Timothy Hayes <timothy.hayes@arm.com>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>, Sascha Bischoff
	<sascha.bischoff@arm.com>, mrigendrachaubey <mrigendra.chaubey@gmail.com>,
	"linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>, "linux-kernel@vger.kernel.org"
	<linux-kernel@vger.kernel.org>, "linux-arch@vger.kernel.org"
	<linux-arch@vger.kernel.org>, "linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>, "vdso@mailbox.org" <vdso@mailbox.org>,
	"ssengar@linux.microsoft.com" <ssengar@linux.microsoft.com>
Subject: RE: [PATCH v2 12/15] mshv_vtl: Move VSM code page offset logic to x86
 files
Thread-Topic: [PATCH v2 12/15] mshv_vtl: Move VSM code page offset logic to
 x86 files
Thread-Index: AQHc0x7dvoxTT1xj6U+jCn0YEoiRorXyapGw
Date: Mon, 27 Apr 2026 05:40:52 +0000
Message-ID:
 <SN6PR02MB4157E0525DDDD153888F5AFBD4362@SN6PR02MB4157.namprd02.prod.outlook.com>
References: <20260423124206.2410879-1-namjain@linux.microsoft.com>
 <20260423124206.2410879-13-namjain@linux.microsoft.com>
In-Reply-To: <20260423124206.2410879-13-namjain@linux.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: SN6PR02MB4157:EE_|CO6PR02MB7809:EE_
x-ms-office365-filtering-correlation-id: f0cb2edb-9040-438f-696c-08dea41f8b42
x-microsoft-antispam:
 BCL:0;ARA:14566002|2604032031799003|704163111799003|51005399006|55001999006|16051099003|37011999003|13091999003|19101099003|461199028|41001999006|31061999003|19110799012|15080799012|8062599012|8060799015|40105399003|440099028|3412199025|102099032|12091999003|1710799026;
x-microsoft-antispam-message-info:
 =?us-ascii?Q?MvvVeg8fXOA63QZFLtb2auJdqql//zfHx5rk55KGa8Hc32fuZe1AzaZpJYP5?=
 =?us-ascii?Q?eJ+xEsLdTg8Varg+14aUGfCpYwV+NQKi7N1DNBepAq/XUkld138vL3/a3UDg?=
 =?us-ascii?Q?fCK03zC2IrqW5l+UIOzszsGIxOaDePtql2A0mNV8G8jZxuVbmdBPW5e9wI6P?=
 =?us-ascii?Q?j7y5UAno5y1mPFN4IyNghTbdXiXNqzUfSEK/3aXBFmqVVqJbHtHpPyOWjwQH?=
 =?us-ascii?Q?6bvMDXBvEQoZQ5RbYzLjM4GapXEWH+gG9AguJ30qBT6dmJCTXDBnVfWBdIo/?=
 =?us-ascii?Q?sT1DimPymh/mgWEOc4BuXJ3bsHZuK2SvyjRJMbPM4dbV4ELZyLTE+13daebv?=
 =?us-ascii?Q?nFIYtSG3D8vgIJiCZnyChsEWM7C37j2m268kDHh8CIj2EIU138Ohe656yBZv?=
 =?us-ascii?Q?pZaSlrSsLBHNlzN73/xifzROqlfBt1Of+CzzQfPrp3MItaK+B/UQCOE9MXKb?=
 =?us-ascii?Q?0K+oVJNJrWQJGC9KzvU0Yrq33uCZmPozPaUfmcGQqvGQPxl5JN4vDVSpy/Tq?=
 =?us-ascii?Q?Kvs9dbM084Yq1ocMEepCmDR9fweFqVO/nLqN+wQzft4FCw+mLHQXnpud+2J9?=
 =?us-ascii?Q?8UcuRVuC7XoXwsyM18YHOJxC33NJ6dqRuzYJhTbSASmVPtyWbB5hKz7NmaQR?=
 =?us-ascii?Q?pVhsyEtp81D6/x8k59dhAunwB3xA5LjZpFTU/8LPY+r9WnHcJnlRUL0VPkfN?=
 =?us-ascii?Q?9AwHV0eAUSUfAHZYt2Valut5CkznyL8A6TpxS/eeWSQN4jIHu2R3rTkoabmJ?=
 =?us-ascii?Q?JfMAQNGrVAqKZtUDRYS9oFSqULV+1JoW1s+qHtijfHa4+ZEVD8e4vXe97K7p?=
 =?us-ascii?Q?Dmz1eegU5hremRHTtteRtj2PKvOqmdhRucN1KEbS7ljxZ10QmQ7cpJp9p5D3?=
 =?us-ascii?Q?wHPH2uDmMZcJdgj69nUUh1fkk+ANRiUqB21djv49KWinAPQki3CWAbz4n/jh?=
 =?us-ascii?Q?zZSNmNs+umu8j+tue/tpF/3NRWqYDkvgToH0iqfuyQck/X7skd36OjtPMh6Q?=
 =?us-ascii?Q?RTVESkGDs2ccaVDlMJLoOCIam7FlxNpgdxLwnG/aZzDqLlDBwZmhrNhYsDzL?=
 =?us-ascii?Q?xYYHm588aXi1QlvSiL6c88OvgujFcKEjXOneENc5Cgt0u8jPA/jV6t9bOWwI?=
 =?us-ascii?Q?AS2tCrtHg0rASRS5IVZZG5Ajj0lCFj2y3grtbwibGTkJxz/RHCBardV1jzba?=
 =?us-ascii?Q?ECX7QtOEgYOO9RzhySh8556/GBRLz7xFF547Hahonoxvv3CNKNDuk/kFNrM?=
 =?us-ascii?Q?=3D?=
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?FSPrHNDWBeXk48Y5c1xCbr+s16Z5DhDdq7vHNvN4sTarryI7tPZzPzJxp3eQ?=
 =?us-ascii?Q?7Clnv/pNyoKzu75aQScUkhOr4ygmYikCLTV50grzV6rSN+d++6sQvMuJ1bCo?=
 =?us-ascii?Q?BL5bvvzYijE9MDlagnoS4+VT1VEB0yY9zZqZRApzU+3drZ9ELCu1s845vdux?=
 =?us-ascii?Q?oA67NNXvV79mfWweFt5XIs5tqUEbVQ6ErlDoxUuDcV0KLTmqwhaEDgANckuZ?=
 =?us-ascii?Q?b/MleIamJhEoSWbmIpVFYqeBBhn+EG+0+Ez+j78ZtStPMhIgXPPCC++RJOq+?=
 =?us-ascii?Q?xikua/Lzskd94mSEd5cupBRYudETIhn3KbPNTcieetwNLXHaXDfnbt+9cyIe?=
 =?us-ascii?Q?MYxOZFG1zXxuYxCtOkDHf8KSMGoAbtAx4kS71fCnAOhbUPQ+pDpNmPNn5vRL?=
 =?us-ascii?Q?6dV9JF/r5aXdbJauon/pUOIewaYmQjUKfR4VntgjucyO1QgdFMjwGoLwBUtl?=
 =?us-ascii?Q?bg/J9cs72eNGx0fcg5TSjFebzrnAaFkAABbxJcd85nyUMCl37UngkRAZxOSv?=
 =?us-ascii?Q?9n2YJjRlRrJtEt6OjG+gEkUTVKSFUAfcz/qvneXQwjO5nfwAwY4Dq2kMPGxR?=
 =?us-ascii?Q?a6um63f3xSYi7Y2x2yqDPl/8A7+VwX9THb3Q4abR55+0RnrITP5TXQYcNQjA?=
 =?us-ascii?Q?4WszQCa82JOiiEm0ydkUUQuEAR9frWZIWEKH0Y6g+/qtC/Foe7lBjD4MXvmz?=
 =?us-ascii?Q?hgeeyIxRDyI5a8aDqFB4cRZovttB1NYve1wAdMdP1Qf4rEQjaYUqmL5pFDv4?=
 =?us-ascii?Q?6GcNgLZB0+XU5wpYow6LcGVcA49LbD/bJtWdrfj/7XTUGKS2jnu8cZnwozyj?=
 =?us-ascii?Q?8bmrpzIQX+U0p/VLzbRGWrzB2OdAD5mKC4BaerpHTzEhUUt/YiEpYUVm2Zav?=
 =?us-ascii?Q?M+915+ajkO+VAkxKnfVmPxSznv9b9AuNO9nGsghPVhnyCwkCb5b7UcBvZXoG?=
 =?us-ascii?Q?5ZqIajoJz8W4mP72Jy+Xtjn7EhvKyX/JadLkbU5GXbOjhD5EMQ5HvFSuwJvr?=
 =?us-ascii?Q?EsFhlkLoWuVbUN6ePmrTPLFHqccQqy/qHZNaZvzQYBBsgq61eWWYQ9ktKgon?=
 =?us-ascii?Q?N+qXvSPhKov3g9vtmW5sgYuqeuyea9Z8WBA4e1QOxX6ts7E7c2YmxMMdh5Fz?=
 =?us-ascii?Q?yNiEhkMZXh2+ygsjNp/1BBvcOX5Hhw7ummGy1+fQCkm2ZNflDEaEgUC0OqgY?=
 =?us-ascii?Q?mrmsHkP1iKvCvhWFcpsL5Qo3aAz0MErHLdCylfSrGVmpsPY7WigWcb/CSJ/2?=
 =?us-ascii?Q?Yu0M/h6Fe9Q5yVigfK8rqSYOK2WZXmZZDwb7mfJXH+8aYif5md/PAAuHm/vH?=
 =?us-ascii?Q?sarzSjfJE9iGzwtGltQ7onbljckNSpNaOAEuBtxOBI/j/mGwL6WdDzya+uzY?=
 =?us-ascii?Q?BwxMi4Q=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
X-Mailing-List: linux-arch@vger.kernel.org
List-Id: <linux-arch.vger.kernel.org>
List-Subscribe: <mailto:linux-arch+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-arch+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SN6PR02MB4157.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: f0cb2edb-9040-438f-696c-08dea41f8b42
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2026 05:40:52.0419
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO6PR02MB7809

From: Naman Jain <namjain@linux.microsoft.com> Sent: Thursday, April 23, 20=
26 5:42 AM
>=20
> The VSM code page offset register (HV_REGISTER_VSM_CODE_PAGE_OFFSETS)
> is x86 specific, its value configures the static call used to return
> to VTL0 via the hypercall page. Move the register read from the common
> mshv_vtl_get_vsm_regs() into the x86 mshv_vtl_return_call_init(),
> which is the sole consumer of the offset.
>=20
> Change mshv_vtl_return_call_init() from taking a u64 parameter
> to taking no arguments, and rename mshv_vtl_get_vsm_regs() to
> mshv_vtl_get_vsm_cap_reg() since it now only fetches
> HV_REGISTER_VSM_CAPABILITIES.
>=20
> No functional change on x86. This prepares the common driver code for
> ARM64 where VSM code page offsets do not apply.
>=20
> Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
> ---
>  arch/x86/hyperv/hv_vtl.c        | 19 +++++++++++++++++--
>  arch/x86/include/asm/mshyperv.h |  4 ++--
>  drivers/hv/mshv_vtl_main.c      | 24 +++++++++++++-----------
>  3 files changed, 32 insertions(+), 15 deletions(-)
>=20
> diff --git a/arch/x86/hyperv/hv_vtl.c b/arch/x86/hyperv/hv_vtl.c
> index f3ffb6a7cb2d..7c10b34cf8a4 100644
> --- a/arch/x86/hyperv/hv_vtl.c
> +++ b/arch/x86/hyperv/hv_vtl.c
> @@ -293,10 +293,25 @@ EXPORT_SYMBOL_GPL(hv_vtl_configure_reg_page);
>=20
>  DEFINE_STATIC_CALL_NULL(__mshv_vtl_return_hypercall, void (*)(void));
>=20
> -void mshv_vtl_return_call_init(u64 vtl_return_offset)
> +int mshv_vtl_return_call_init(void)
>  {
> +	struct hv_register_assoc vsm_pg_offset_reg;
> +	union hv_register_vsm_page_offsets offsets;
> +	int ret;
> +
> +	vsm_pg_offset_reg.name =3D HV_REGISTER_VSM_CODE_PAGE_OFFSETS;
> +
> +	ret =3D hv_call_get_vp_registers(HV_VP_INDEX_SELF, HV_PARTITION_ID_SELF=
,
> +				       1, input_vtl_zero, &vsm_pg_offset_reg);
> +	if (ret)
> +		return ret;
> +
> +	offsets.as_uint64 =3D vsm_pg_offset_reg.value.reg64;
> +
>  	static_call_update(__mshv_vtl_return_hypercall,
> -			   (void *)((u8 *)hv_hypercall_pg + vtl_return_offset));
> +			   (void *)((u8 *)hv_hypercall_pg + offsets.vtl_return_offset));
> +
> +	return 0;
>  }
>  EXPORT_SYMBOL(mshv_vtl_return_call_init);
>=20
> diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyp=
erv.h
> index b4d80c9a673a..b48f115c1292 100644
> --- a/arch/x86/include/asm/mshyperv.h
> +++ b/arch/x86/include/asm/mshyperv.h
> @@ -286,14 +286,14 @@ struct mshv_vtl_cpu_context {
>  #ifdef CONFIG_HYPERV_VTL_MODE
>  void __init hv_vtl_init_platform(void);
>  int __init hv_vtl_early_init(void);
> -void mshv_vtl_return_call_init(u64 vtl_return_offset);
> +int mshv_vtl_return_call_init(void);
>  void mshv_vtl_return_hypercall(void);
>  void __mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0);
>  int hv_vtl_get_set_reg(struct hv_register_assoc *regs, bool set, bool sh=
ared);
>  #else
>  static inline void __init hv_vtl_init_platform(void) {}
>  static inline int __init hv_vtl_early_init(void) { return 0; }
> -static inline void mshv_vtl_return_call_init(u64 vtl_return_offset) {}
> +static inline int mshv_vtl_return_call_init(void) { return 0; }
>  static inline void mshv_vtl_return_hypercall(void) {}
>  static inline void __mshv_vtl_return_call(struct mshv_vtl_cpu_context *v=
tl0) {}
>  #endif
> diff --git a/drivers/hv/mshv_vtl_main.c b/drivers/hv/mshv_vtl_main.c
> index 4c9ae65ad3e8..be498c9234fd 100644
> --- a/drivers/hv/mshv_vtl_main.c
> +++ b/drivers/hv/mshv_vtl_main.c
> @@ -79,7 +79,6 @@ struct mshv_vtl {
>  };
>=20
>  static struct mutex mshv_vtl_poll_file_lock;
> -static union hv_register_vsm_page_offsets mshv_vsm_page_offsets;
>  static union hv_register_vsm_capabilities mshv_vsm_capabilities;
>=20
>  static DEFINE_PER_CPU(struct mshv_vtl_poll_file, mshv_vtl_poll_file);
> @@ -203,21 +202,19 @@ static void mshv_vtl_synic_enable_regs(unsigned int=
 cpu)
>  	/* VTL2 Host VSP SINT is (un)masked when the user mode requests that */
>  }
>=20
> -static int mshv_vtl_get_vsm_regs(void)
> +static int mshv_vtl_get_vsm_cap_reg(void)
>  {
> -	struct hv_register_assoc registers[2];
> -	int ret, count =3D 2;
> +	struct hv_register_assoc vsm_capability_reg;
> +	int ret;
>=20
> -	registers[0].name =3D HV_REGISTER_VSM_CODE_PAGE_OFFSETS;
> -	registers[1].name =3D HV_REGISTER_VSM_CAPABILITIES;
> +	vsm_capability_reg.name =3D HV_REGISTER_VSM_CAPABILITIES;
>=20
>  	ret =3D hv_call_get_vp_registers(HV_VP_INDEX_SELF, HV_PARTITION_ID_SELF=
,
> -				       count, input_vtl_zero, registers);
> +				       1, input_vtl_zero, &vsm_capability_reg);
>  	if (ret)
>  		return ret;
>=20
> -	mshv_vsm_page_offsets.as_uint64 =3D registers[0].value.reg64;
> -	mshv_vsm_capabilities.as_uint64 =3D registers[1].value.reg64;
> +	mshv_vsm_capabilities.as_uint64 =3D vsm_capability_reg.value.reg64;
>=20
>  	return ret;

Nit: This could be just "return 0".

>  }
> @@ -1139,13 +1136,18 @@ static int __init mshv_vtl_init(void)
>  	tasklet_init(&msg_dpc, mshv_vtl_sint_on_msg_dpc, 0);
>  	init_waitqueue_head(&fd_wait_queue);
>=20
> -	if (mshv_vtl_get_vsm_regs()) {
> +	if (mshv_vtl_get_vsm_cap_reg()) {
>  		dev_emerg(dev, "Unable to get VSM capabilities !!\n");

Why is this failure an emergency message, while the other failures
here in mshv_vtl_init() are just error messages? When there's lack
of consistency, I always wonder if there is a reason ..... :-)

>  		ret =3D -ENODEV;
>  		goto free_dev;
>  	}
>=20
> -	mshv_vtl_return_call_init(mshv_vsm_page_offsets.vtl_return_offset);
> +	ret =3D mshv_vtl_return_call_init();
> +	if (ret) {
> +		dev_err(dev, "mshv_vtl_return_call_init failed: %d\n", ret);
> +		goto free_dev;
> +	}
> +
>  	ret =3D hv_vtl_setup_synic();
>  	if (ret)
>  		goto free_dev;
> --
> 2.43.0
>=20


From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 0FE8E3C063B;
	Wed, 29 Apr 2026 09:55:15 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=13.77.154.182
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1777456520; cv=none; b=Mx0K0ZLhDOmCJ8idqzQO3sy+nNwoLspIgFBtE6TfM2oV5ktK0nNTDxFn7Ov6QKENlPTI+FrxOXiBqFtfLsFkw77ZOqmVR1BGqhpWJ8CjdxxkHmVtuoV7lIzu0+T85f5kl40gQaltCa6bmvlGp8/nP3raPSceC9VwHuUpV3uHPcE=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1777456520; c=relaxed/simple;
	bh=e2iU8tsVRtHKEbKnXfsa1M6VKEiOaYh54i4Hs8Qi+r0=;
	h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
	 In-Reply-To:Content-Type; b=W9upei89EYXZ2RpxeRZ/SGNRGU/RZRQCwjN5kgbwNMrTG79eg4a1Vs8u7Hr0wGtuvZsRWkxpGfZQDKRmJtrOZKUfb6YlcVdQb0df+accUi70nk0q9k8zUA7WBiZ78CXk09CYsaFs6gjK5LejCm3MylOlyGpQluSFrrM4cUfiL/Y=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com; spf=pass smtp.mailfrom=linux.microsoft.com; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b=E05q9a42; arc=none smtp.client-ip=13.77.154.182
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="E05q9a42"
Received: from [10.95.65.160] (unknown [167.220.238.0])
	by linux.microsoft.com (Postfix) with ESMTPSA id 6F23720B716C;
	Wed, 29 Apr 2026 02:55:07 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 6F23720B716C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1777456514;
	bh=iLG5Xdzg5UMWeGId8TT8BIKIR6ihO3btgl5r+mmYztY=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=E05q9a42/LyIAQVrLn1ZujBoyIrLBtA0Dsi5O0BcMjj74yvtObGzz6jRdHIwHYdvs
	 X+1N28PIKVapL5OsFaly+I7NY/OkqaSSPMg2XLyNbg/zs+rJbX2iL7RGGQK+NpvU0l
	 EfkTepa71AsDZ+AT2tWhep4vOOEOvbRuSEVWEqts=
Message-ID: <f8a15328-b084-4d5f-a089-57fcf743afbf@linux.microsoft.com>
Date: Wed, 29 Apr 2026 15:25:03 +0530
Precedence: bulk
X-Mailing-List: linux-arch@vger.kernel.org
List-Id: <linux-arch.vger.kernel.org>
List-Subscribe: <mailto:linux-arch+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-arch+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 02/15] Drivers: hv: Move hv_vp_assist_page to common
 files
To: Michael Kelley <mhklinux@outlook.com>,
 "K . Y . Srinivasan" <kys@microsoft.com>,
 Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>,
 Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>,
 Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>,
 Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
 Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>,
 "x86@kernel.org" <x86@kernel.org>, "H . Peter Anvin" <hpa@zytor.com>,
 Arnd Bergmann <arnd@arndb.de>, Paul Walmsley <pjw@kernel.org>,
 Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu>,
 Alexandre Ghiti <alex@ghiti.fr>
Cc: Marc Zyngier <maz@kernel.org>, Timothy Hayes <timothy.hayes@arm.com>,
 Lorenzo Pieralisi <lpieralisi@kernel.org>,
 Sascha Bischoff <sascha.bischoff@arm.com>,
 mrigendrachaubey <mrigendra.chaubey@gmail.com>,
 "linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
 "linux-arm-kernel@lists.infradead.org"
 <linux-arm-kernel@lists.infradead.org>,
 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
 "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
 "linux-riscv@lists.infradead.org" <linux-riscv@lists.infradead.org>,
 "vdso@mailbox.org" <vdso@mailbox.org>,
 "ssengar@linux.microsoft.com" <ssengar@linux.microsoft.com>
References: <20260423124206.2410879-1-namjain@linux.microsoft.com>
 <20260423124206.2410879-3-namjain@linux.microsoft.com>
 <SN6PR02MB4157BEAF5480D931C3756B7DD4362@SN6PR02MB4157.namprd02.prod.outlook.com>
Content-Language: en-US
From: Naman Jain <namjain@linux.microsoft.com>
In-Reply-To: <SN6PR02MB4157BEAF5480D931C3756B7DD4362@SN6PR02MB4157.namprd02.prod.outlook.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit



On 4/27/2026 11:07 AM, Michael Kelley wrote:
> From: Naman Jain <namjain@linux.microsoft.com> Sent: Thursday, April 23, 2026 5:42 AM
>>
>> Move the logic to initialize and export hv_vp_assist_page from x86
>> architecture code to Hyper-V common code to allow it to be used for
>> upcoming arm64 support in MSHV_VTL driver.
>> Note: This change also improves error handling - if VP assist page
>> allocation fails, hyperv_init() now returns early instead of
>> continuing with partial initialization.
>>
>> Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
>> Reviewed-by: Roman Kisel <vdso@mailbox.org>
>> Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
>> ---
>>   arch/x86/hyperv/hv_init.c       | 88 +-----------------------------
>>   arch/x86/include/asm/mshyperv.h | 14 -----
>>   drivers/hv/hv_common.c          | 94 ++++++++++++++++++++++++++++++++-
>>   include/asm-generic/mshyperv.h  | 16 ++++++
>>   include/hyperv/hvgdk_mini.h     |  6 ++-
>>   5 files changed, 115 insertions(+), 103 deletions(-)
>>
>> diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
>> index 323adc93f2dc..75a98b5e451b 100644
>> --- a/arch/x86/hyperv/hv_init.c
>> +++ b/arch/x86/hyperv/hv_init.c
>> @@ -81,9 +81,6 @@ union hv_ghcb * __percpu *hv_ghcb_pg;
>>   /* Storage to save the hypercall page temporarily for hibernation */
>>   static void *hv_hypercall_pg_saved;
>>
>> -struct hv_vp_assist_page **hv_vp_assist_page;
>> -EXPORT_SYMBOL_GPL(hv_vp_assist_page);
>> -
>>   static int hyperv_init_ghcb(void)
>>   {
>>   	u64 ghcb_gpa;
>> @@ -117,59 +114,12 @@ static int hyperv_init_ghcb(void)
>>
>>   static int hv_cpu_init(unsigned int cpu)
>>   {
>> -	union hv_vp_assist_msr_contents msr = { 0 };
>> -	struct hv_vp_assist_page **hvp;
>>   	int ret;
>>
>>   	ret = hv_common_cpu_init(cpu);
>>   	if (ret)
>>   		return ret;
>>
>> -	if (!hv_vp_assist_page)
>> -		return 0;
>> -
>> -	hvp = &hv_vp_assist_page[cpu];
>> -	if (hv_root_partition()) {
>> -		/*
>> -		 * For root partition we get the hypervisor provided VP assist
>> -		 * page, instead of allocating a new page.
>> -		 */
>> -		rdmsrq(HV_X64_MSR_VP_ASSIST_PAGE, msr.as_uint64);
>> -		*hvp = memremap(msr.pfn << HV_X64_MSR_VP_ASSIST_PAGE_ADDRESS_SHIFT,
>> -				PAGE_SIZE, MEMREMAP_WB);
>> -	} else {
>> -		/*
>> -		 * The VP assist page is an "overlay" page (see Hyper-V TLFS's
>> -		 * Section 5.2.1 "GPA Overlay Pages"). Here it must be zeroed
>> -		 * out to make sure we always write the EOI MSR in
>> -		 * hv_apic_eoi_write() *after* the EOI optimization is disabled
>> -		 * in hv_cpu_die(), otherwise a CPU may not be stopped in the
>> -		 * case of CPU offlining and the VM will hang.
>> -		 */
>> -		if (!*hvp) {
>> -			*hvp = __vmalloc(PAGE_SIZE, GFP_KERNEL | __GFP_ZERO);
>> -
>> -			/*
>> -			 * Hyper-V should never specify a VM that is a Confidential
>> -			 * VM and also running in the root partition. Root partition
>> -			 * is blocked to run in Confidential VM. So only decrypt assist
>> -			 * page in non-root partition here.
>> -			 */
>> -			if (*hvp && !ms_hyperv.paravisor_present && hv_isolation_type_snp()) {
>> -				WARN_ON_ONCE(set_memory_decrypted((unsigned long)(*hvp), 1));
>> -				memset(*hvp, 0, PAGE_SIZE);
>> -			}
>> -		}
>> -
>> -		if (*hvp)
>> -			msr.pfn = vmalloc_to_pfn(*hvp);
>> -
>> -	}
>> -	if (!WARN_ON(!(*hvp))) {
>> -		msr.enable = 1;
>> -		wrmsrq(HV_X64_MSR_VP_ASSIST_PAGE, msr.as_uint64);
>> -	}
>> -
>>   	/* Allow Hyper-V stimer vector to be injected from Hypervisor. */
>>   	if (ms_hyperv.misc_features & HV_STIMER_DIRECT_MODE_AVAILABLE)
>>   		apic_update_vector(cpu, HYPERV_STIMER0_VECTOR, true);
>> @@ -286,23 +236,6 @@ static int hv_cpu_die(unsigned int cpu)
>>
>>   	hv_common_cpu_die(cpu);
>>
>> -	if (hv_vp_assist_page && hv_vp_assist_page[cpu]) {
>> -		union hv_vp_assist_msr_contents msr = { 0 };
>> -		if (hv_root_partition()) {
>> -			/*
>> -			 * For root partition the VP assist page is mapped to
>> -			 * hypervisor provided page, and thus we unmap the
>> -			 * page here and nullify it, so that in future we have
>> -			 * correct page address mapped in hv_cpu_init.
>> -			 */
>> -			memunmap(hv_vp_assist_page[cpu]);
>> -			hv_vp_assist_page[cpu] = NULL;
>> -			rdmsrq(HV_X64_MSR_VP_ASSIST_PAGE, msr.as_uint64);
>> -			msr.enable = 0;
>> -		}
>> -		wrmsrq(HV_X64_MSR_VP_ASSIST_PAGE, msr.as_uint64);
>> -	}
>> -
>>   	if (hv_reenlightenment_cb == NULL)
>>   		return 0;
>>
>> @@ -460,21 +393,6 @@ void __init hyperv_init(void)
>>   	if (hv_common_init())
>>   		return;
>>
>> -	/*
>> -	 * The VP assist page is useless to a TDX guest: the only use we
>> -	 * would have for it is lazy EOI, which can not be used with TDX.
>> -	 */
>> -	if (hv_isolation_type_tdx())
>> -		hv_vp_assist_page = NULL;
>> -	else
>> -		hv_vp_assist_page = kzalloc_objs(*hv_vp_assist_page, nr_cpu_ids);
>> -	if (!hv_vp_assist_page) {
>> -		ms_hyperv.hints &= ~HV_X64_ENLIGHTENED_VMCS_RECOMMENDED;
>> -
>> -		if (!hv_isolation_type_tdx())
>> -			goto common_free;
>> -	}
>> -
>>   	if (ms_hyperv.paravisor_present && hv_isolation_type_snp()) {
>>   		/* Negotiate GHCB Version. */
>>   		if (!hv_ghcb_negotiate_protocol())
>> @@ -483,7 +401,7 @@ void __init hyperv_init(void)
>>
>>   		hv_ghcb_pg = alloc_percpu(union hv_ghcb *);
>>   		if (!hv_ghcb_pg)
>> -			goto free_vp_assist_page;
>> +			goto free_ghcb_page;
> 
> Seems like this should be "goto common_free". The allocation of
> hv_ghcb_pg has failed, so going to a label where hv_ghcb_pg is
> freed seems redundant. It works since free_percpu() checks for
> a NULL argument, but it's a bit unexpected since the common_free
> label is already there.

Thanks for catching this, I'll fix it.


> 
>>   	}
>>
>>   	cpuhp = cpuhp_setup_state(CPUHP_AP_HYPERV_ONLINE, "x86/hyperv_init:online",
>> @@ -613,10 +531,6 @@ void __init hyperv_init(void)
>>   	cpuhp_remove_state(CPUHP_AP_HYPERV_ONLINE);
>>   free_ghcb_page:
>>   	free_percpu(hv_ghcb_pg);
>> -free_vp_assist_page:
>> -	kfree(hv_vp_assist_page);
>> -	hv_vp_assist_page = NULL;
>> -common_free:
>>   	hv_common_free();
>>   }
>>
>> diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
>> index f64393e853ee..95b452387969 100644
>> --- a/arch/x86/include/asm/mshyperv.h
>> +++ b/arch/x86/include/asm/mshyperv.h
>> @@ -155,16 +155,6 @@ static inline u64 hv_do_fast_hypercall16(u16 code, u64 input1, u64 input2)
>>   	return _hv_do_fast_hypercall16(control, input1, input2);
>>   }
>>
>> -extern struct hv_vp_assist_page **hv_vp_assist_page;
>> -
>> -static inline struct hv_vp_assist_page *hv_get_vp_assist_page(unsigned int cpu)
>> -{
>> -	if (!hv_vp_assist_page)
>> -		return NULL;
>> -
>> -	return hv_vp_assist_page[cpu];
>> -}
>> -
>>   void __init hyperv_init(void);
>>   void hyperv_setup_mmu_ops(void);
>>   void set_hv_tscchange_cb(void (*cb)(void));
>> @@ -254,10 +244,6 @@ static inline void hyperv_setup_mmu_ops(void) {}
>>   static inline void set_hv_tscchange_cb(void (*cb)(void)) {}
>>   static inline void clear_hv_tscchange_cb(void) {}
>>   static inline void hyperv_stop_tsc_emulation(void) {};
>> -static inline struct hv_vp_assist_page *hv_get_vp_assist_page(unsigned int cpu)
>> -{
>> -	return NULL;
>> -}
>>   static inline int hyperv_flush_guest_mapping(u64 as) { return -1; }
>>   static inline int hyperv_flush_guest_mapping_range(u64 as,
>>   		hyperv_fill_flush_list_func fill_func, void *data)
>> diff --git a/drivers/hv/hv_common.c b/drivers/hv/hv_common.c
>> index 6b67ac616789..e8633bc51d56 100644
>> --- a/drivers/hv/hv_common.c
>> +++ b/drivers/hv/hv_common.c
>> @@ -28,7 +28,11 @@
>>   #include <linux/slab.h>
>>   #include <linux/dma-map-ops.h>
>>   #include <linux/set_memory.h>
>> +#include <linux/vmalloc.h>
>> +#include <linux/io.h>
>> +#include <linux/hyperv.h>
>>   #include <hyperv/hvhdk.h>
>> +#include <hyperv/hvgdk.h>
>>   #include <asm/mshyperv.h>
>>
>>   u64 hv_current_partition_id = HV_PARTITION_ID_SELF;
>> @@ -78,6 +82,8 @@ static struct ctl_table_header *hv_ctl_table_hdr;
>>   u8 * __percpu *hv_synic_eventring_tail;
>>   EXPORT_SYMBOL_GPL(hv_synic_eventring_tail);
>>
>> +struct hv_vp_assist_page **hv_vp_assist_page;
>> +EXPORT_SYMBOL_GPL(hv_vp_assist_page);
>>   /*
>>    * Hyper-V specific initialization and shutdown code that is
>>    * common across all architectures.  Called from architecture
>> @@ -92,6 +98,9 @@ void __init hv_common_free(void)
>>   	if (ms_hyperv.misc_features & HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE)
>>   		hv_kmsg_dump_unregister();
>>
>> +	kfree(hv_vp_assist_page);
>> +	hv_vp_assist_page = NULL;
>> +
>>   	kfree(hv_vp_index);
>>   	hv_vp_index = NULL;
>>
>> @@ -394,6 +403,23 @@ int __init hv_common_init(void)
>>   	for (i = 0; i < nr_cpu_ids; i++)
>>   		hv_vp_index[i] = VP_INVAL;
>>
>> +	/*
>> +	 * The VP assist page is useless to a TDX guest: the only use we
>> +	 * would have for it is lazy EOI, which can not be used with TDX.
>> +	 */
>> +	if (hv_isolation_type_tdx()) {
>> +		hv_vp_assist_page = NULL;
>> +#ifdef CONFIG_X86_64
>> +		ms_hyperv.hints &= ~HV_X64_ENLIGHTENED_VMCS_RECOMMENDED;
>> +#endif
> 
> I realize that this #ifdef went away for the reason I flagged in v1 of
> this patch set, but it's back again for a different reason.
> 
> Let me suggest another approach. hv_common_init() is called from
> both the x86/64 and arm64 hyperv_init() functions. Immediately after
> the call to hv_common_init() in the x86/64 hyperv_init(), test
> hv_vp_assist_page for NULL and clear
> HV_X64_ENLIGHTENED_VMCS_RECOMMENDED if it is. No #ifdef is
> needed, and x86/64 specific hackery stays under arch/x86 instead of
> being in common code.

Acked. Thanks.

> 
>> +	} else {
>> +		hv_vp_assist_page = kzalloc_objs(*hv_vp_assist_page, nr_cpu_ids);
>> +		if (!hv_vp_assist_page) {
>> +			hv_common_free();
>> +			return -ENOMEM;
>> +		}
>> +	}
>> +
>>   	return 0;
>>   }
>>
>> @@ -471,6 +497,8 @@ void __init ms_hyperv_late_init(void)
>>
>>   int hv_common_cpu_init(unsigned int cpu)
>>   {
>> +	union hv_vp_assist_msr_contents msr = { 0 };
>> +	struct hv_vp_assist_page **hvp;
>>   	void **inputarg, **outputarg;
>>   	u8 **synic_eventring_tail;
>>   	u64 msr_vp_index;
>> @@ -539,7 +567,53 @@ int hv_common_cpu_init(unsigned int cpu)
>>   						sizeof(u8), flags);
>>   		/* No need to unwind any of the above on failure here */
>>   		if (unlikely(!*synic_eventring_tail))
>> -			ret = -ENOMEM;
>> +			return -ENOMEM;
>> +	}
>> +
>> +	if (!hv_vp_assist_page)
>> +		return ret;
>> +
>> +	hvp = &hv_vp_assist_page[cpu];
>> +	if (hv_root_partition()) {
>> +		/*
>> +		 * For root partition we get the hypervisor provided VP assist
>> +		 * page, instead of allocating a new page.
>> +		 */
>> +		msr.as_uint64 = hv_get_msr(HV_MSR_VP_ASSIST_PAGE);
>> +		*hvp = memremap(msr.pfn << HV_VP_ASSIST_PAGE_ADDRESS_SHIFT,
>> +				HV_HYP_PAGE_SIZE, MEMREMAP_WB);
>> +	} else {
>> +		/*
>> +		 * The VP assist page is an "overlay" page (see Hyper-V TLFS's
>> +		 * Section 5.2.1 "GPA Overlay Pages"). Here it must be zeroed
>> +		 * out to make sure that on x86/x64, we always write the EOI MSR in
>> +		 * hv_apic_eoi_write() *after* the EOI optimization is disabled
>> +		 * in hv_cpu_die(), otherwise a CPU may not be stopped in the
>> +		 * case of CPU offlining and the VM will hang.
>> +		 */
>> +		if (!*hvp) {
>> +			*hvp = __vmalloc(HV_HYP_PAGE_SIZE, flags | __GFP_ZERO);
>> +
>> +			/*
>> +			 * Hyper-V should never specify a VM that is a Confidential
>> +			 * VM and also running in the root partition. Root partition
>> +			 * is blocked to run in Confidential VM. So only decrypt assist
>> +			 * page in non-root partition here.
>> +			 */
>> +			if (*hvp &&
>> +			    !ms_hyperv.paravisor_present &&
>> +			    hv_isolation_type_snp()) {
>> +				WARN_ON_ONCE(set_memory_decrypted((unsigned long)(*hvp), 1));
>> +				memset(*hvp, 0, HV_HYP_PAGE_SIZE);
>> +			}
>> +		}
>> +
>> +		if (*hvp)
>> +			msr.pfn = page_to_hvpfn(vmalloc_to_page(*hvp));
> 
> Your Patch 0 changelog mentions adding a comment about vmalloc_to_pfn(), which
> I didn't see anywhere. I'm not sure what that comment would say, so maybe it
> became unnecessary.

I think I mixed up two things. Changelog was about your suggestion to 
add "x86/x64" in above comment about GPA Overlay Pages.
I also changed this function to page_to_hvpfn(vmalloc_to_page(*hvp)) as 
per your suggestion.
Apologies for the confusion.

> 
>> +	}
>> +	if (!WARN_ON(!(*hvp))) {
>> +		msr.enable = 1;
>> +		hv_set_msr(HV_MSR_VP_ASSIST_PAGE, msr.as_uint64);
>>   	}
>>
>>   	return ret;
>> @@ -566,6 +640,24 @@ int hv_common_cpu_die(unsigned int cpu)
>>   		*synic_eventring_tail = NULL;
>>   	}
>>
>> +	if (hv_vp_assist_page && hv_vp_assist_page[cpu]) {
>> +		union hv_vp_assist_msr_contents msr = { 0 };
>> +
>> +		if (hv_root_partition()) {
>> +			/*
>> +			 * For root partition the VP assist page is mapped to
>> +			 * hypervisor provided page, and thus we unmap the
>> +			 * page here and nullify it, so that in future we have
>> +			 * correct page address mapped in hv_cpu_init.
>> +			 */
>> +			memunmap(hv_vp_assist_page[cpu]);
>> +			hv_vp_assist_page[cpu] = NULL;
>> +			msr.as_uint64 = hv_get_msr(HV_MSR_VP_ASSIST_PAGE);
>> +			msr.enable = 0;
>> +		}
>> +		hv_set_msr(HV_MSR_VP_ASSIST_PAGE, msr.as_uint64);
>> +	}
>> +
>>   	return 0;
>>   }
>>
>> diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyperv.h
>> index d37b68238c97..2810aa05dc73 100644
>> --- a/include/asm-generic/mshyperv.h
>> +++ b/include/asm-generic/mshyperv.h
>> @@ -25,6 +25,7 @@
>>   #include <linux/nmi.h>
>>   #include <asm/ptrace.h>
>>   #include <hyperv/hvhdk.h>
>> +#include <hyperv/hvgdk.h>
>>
>>   #define VTPM_BASE_ADDRESS 0xfed40000
>>
>> @@ -299,6 +300,16 @@ do { \
>>   #define hv_status_debug(status, fmt, ...) \
>>   	hv_status_printk(debug, status, fmt, ##__VA_ARGS__)
>>
>> +extern struct hv_vp_assist_page **hv_vp_assist_page;
>> +
>> +static inline struct hv_vp_assist_page *hv_get_vp_assist_page(unsigned int cpu)
>> +{
>> +	if (!hv_vp_assist_page)
>> +		return NULL;
>> +
>> +	return hv_vp_assist_page[cpu];
>> +}
>> +
>>   const char *hv_result_to_string(u64 hv_status);
>>   int hv_result_to_errno(u64 status);
>>   void hyperv_report_panic(struct pt_regs *regs, long err, bool in_die);
>> @@ -327,6 +338,11 @@ static inline enum hv_isolation_type hv_get_isolation_type(void)
>>   {
>>   	return HV_ISOLATION_TYPE_NONE;
>>   }
>> +
>> +static inline struct hv_vp_assist_page *hv_get_vp_assist_page(unsigned int cpu)
>> +{
>> +	return NULL;
>> +}
>>   #endif /* CONFIG_HYPERV */
>>
>>   #if IS_ENABLED(CONFIG_MSHV_ROOT)
>> diff --git a/include/hyperv/hvgdk_mini.h b/include/hyperv/hvgdk_mini.h
>> index 056ef7b6b360..c72d04cd5ae4 100644
>> --- a/include/hyperv/hvgdk_mini.h
>> +++ b/include/hyperv/hvgdk_mini.h
>> @@ -149,6 +149,7 @@ struct hv_u128 {
>>   #define HV_X64_MSR_VP_ASSIST_PAGE_ADDRESS_SHIFT	12
> 
> Can this X64 specific definition of the shift be eliminated entirely,
> and a single common definition for x86/64 and arm64 be used?
> As I understand it, the MSR layout is the same on both architectures.
> The one gotcha is that kvm_hv_set_msr() would need to be updated.
> 
> HV_X64_MSR_VP_ASSIST_PAGE_ADDRESS_MASK defined below isn't
> used anywhere, so it could go away too.  (The KVM selftest usage has
> its own definition.)
> 
> I realize these are changes to a source code file that is derived from
> Windows, and I'm not sure of the guidelines for such changes. So maybe
> these suggestions have to be ignored ....

The VP assist page definition is common to both x86 and arm64, so the 
address mask and shift can be shared. Also, I don't see the shift and 
mask definitions in the Hyper-V header so seem to be specific to in 
kernel usage.

> 
>>   #define HV_X64_MSR_VP_ASSIST_PAGE_ADDRESS_MASK	\
>>   		(~((1ull << HV_X64_MSR_VP_ASSIST_PAGE_ADDRESS_SHIFT) - 1))
>> +#define HV_MSR_VP_ASSIST_PAGE              (HV_X64_MSR_VP_ASSIST_PAGE)
> 
> This is the correct file for this #define, but it should be placed down around
> line 1148 or so with the other HV_MSR_* definitions in terms of HV_X64_MSR_*
> 

Acked.

>>
>>   /* Hyper-V Enlightened VMCS version mask in nested features CPUID */
>>   #define HV_X64_ENLIGHTENED_VMCS_VERSION		0xff
>> @@ -410,6 +411,7 @@ union hv_x64_msr_hypercall_contents {
>>   #if defined(CONFIG_ARM64)
>>   #define HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE	BIT(8)
>>   #define HV_STIMER_DIRECT_MODE_AVAILABLE		BIT(13)
>> +#define HV_VP_ASSIST_PAGE_ADDRESS_SHIFT 12
>>   #endif /* CONFIG_ARM64 */
>>
>>   #if defined(CONFIG_X86)
>> @@ -1163,6 +1165,8 @@ enum hv_register_name {
>>   #define HV_MSR_STIMER0_CONFIG	(HV_X64_MSR_STIMER0_CONFIG)
>>   #define HV_MSR_STIMER0_COUNT	(HV_X64_MSR_STIMER0_COUNT)
>>
>> +#define HV_VP_ASSIST_PAGE_ADDRESS_SHIFT HV_X64_MSR_VP_ASSIST_PAGE_ADDRESS_SHIFT
>> +
>>   #elif defined(CONFIG_ARM64) /* CONFIG_X86 */
>>
>>   #define HV_MSR_CRASH_P0		(HV_REGISTER_GUEST_CRASH_P0)
>> @@ -1185,7 +1189,7 @@ enum hv_register_name {
>>
>>   #define HV_MSR_STIMER0_CONFIG	(HV_REGISTER_STIMER0_CONFIG)
>>   #define HV_MSR_STIMER0_COUNT	(HV_REGISTER_STIMER0_COUNT)
>> -
>> +#define HV_MSR_VP_ASSIST_PAGE    (HV_REGISTER_VP_ASSIST_PAGE)
> 
> Nit: This definition is slightly mis-aligned. It has spaces where there
> should be a tab to match the similar definitions above it.
> 

Acked.

>>   #endif /* CONFIG_ARM64 */
>>
>>   union hv_explicit_suspend_register {
>> --
>> 2.43.0
>>

Regards,
Naman


From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 28CF23C063B;
	Wed, 29 Apr 2026 09:56:09 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=13.77.154.182
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1777456572; cv=none; b=dCERMN6GrrToKw/Xngbn2PebIuWOrQ30tTgPmZPCD01HKIZMGn6mR0uLrhCF5aO7ymT9yIMe6ODtONIyI45gVbHAVIHfEnkDqdjs7YDsI+09N1kQNuXSNdLwLRvAr0eDSaTC+xWrVsT+PtqMOrnxvUV4hbMvPdKUjgWkbvG86DI=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1777456572; c=relaxed/simple;
	bh=vEWoJownw+5W+hTP3smOvgta2AR1WsxNBLddquqfH/c=;
	h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
	 In-Reply-To:Content-Type; b=H1xPKEU2mgmlOm9hy6Nwd0FtLUTuxksApqsXJPcbgQWWxlKckUjEOdDALhmtv05RpBdAUsANBwaYPzIKqkwn/qlDaYd/6SQOiw4GpadnJPD9TQY9w7azBErRj3XW74IVpeN8N5dGImQVKSGXPYCZ3W8NpeXoFb2GVNRHLpR2JIQ=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com; spf=pass smtp.mailfrom=linux.microsoft.com; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b=T8QQBSnu; arc=none smtp.client-ip=13.77.154.182
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="T8QQBSnu"
Received: from [10.95.65.160] (unknown [167.220.238.0])
	by linux.microsoft.com (Postfix) with ESMTPSA id 64EEC20B716D;
	Wed, 29 Apr 2026 02:55:55 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 64EEC20B716D
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1777456562;
	bh=fPeBJsFqpoo+2GdY4mHjPpIMHuwqDUdZaSruCXTJrak=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=T8QQBSnuhbdga7x4qEdwC5GZPzFgwlYf2WqARJb11uBsZQpYGJmwXoDwqDXFtzto5
	 fPLHAG0knbJHiSxvTqL44F14Cc2BFS+PyBGByoqAywuQ8/vZQellbl02B5e1OOdsJ6
	 DjHGtk8P6ExJYnkJrl2siSeOafxOqtujr+xxRSFE=
Message-ID: <f0d97ca9-4620-4448-90ca-ecc327be5efa@linux.microsoft.com>
Date: Wed, 29 Apr 2026 15:25:51 +0530
Precedence: bulk
X-Mailing-List: linux-arch@vger.kernel.org
List-Id: <linux-arch.vger.kernel.org>
List-Subscribe: <mailto:linux-arch+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-arch+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 03/15] Drivers: hv: Move vmbus_handler to common code
To: Michael Kelley <mhklinux@outlook.com>,
 "K . Y . Srinivasan" <kys@microsoft.com>,
 Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>,
 Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>,
 Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>,
 Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
 Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>,
 "x86@kernel.org" <x86@kernel.org>, "H . Peter Anvin" <hpa@zytor.com>,
 Arnd Bergmann <arnd@arndb.de>, Paul Walmsley <pjw@kernel.org>,
 Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu>,
 Alexandre Ghiti <alex@ghiti.fr>
Cc: Marc Zyngier <maz@kernel.org>, Timothy Hayes <timothy.hayes@arm.com>,
 Lorenzo Pieralisi <lpieralisi@kernel.org>,
 Sascha Bischoff <sascha.bischoff@arm.com>,
 mrigendrachaubey <mrigendra.chaubey@gmail.com>,
 "linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
 "linux-arm-kernel@lists.infradead.org"
 <linux-arm-kernel@lists.infradead.org>,
 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
 "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
 "linux-riscv@lists.infradead.org" <linux-riscv@lists.infradead.org>,
 "vdso@mailbox.org" <vdso@mailbox.org>,
 "ssengar@linux.microsoft.com" <ssengar@linux.microsoft.com>
References: <20260423124206.2410879-1-namjain@linux.microsoft.com>
 <20260423124206.2410879-4-namjain@linux.microsoft.com>
 <SN6PR02MB4157E3B0A6F76E4686D8C3E4D4362@SN6PR02MB4157.namprd02.prod.outlook.com>
Content-Language: en-US
From: Naman Jain <namjain@linux.microsoft.com>
In-Reply-To: <SN6PR02MB4157E3B0A6F76E4686D8C3E4D4362@SN6PR02MB4157.namprd02.prod.outlook.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit



On 4/27/2026 11:08 AM, Michael Kelley wrote:
> From: Naman Jain <namjain@linux.microsoft.com> Sent: Thursday, April 23, 2026 5:42 AM
>>
>> Move the vmbus_handler global variable and hv_setup_vmbus_handler()/
>> hv_remove_vmbus_handler() from arch/x86 to drivers/hv/hv_common.c.
>>
>> hv_setup_vmbus_handler() is called unconditionally in vmbus_bus_init()
>> and works for both x86 (sysvec handler) and arm64 (vmbus_percpu_isr).
>>
>> This eliminates the need for separate percpu vmbus handler setup
>> functions and __weak stubs, that are needed for adding ARM64 support
>> in MSHV_VTL driver where we need to set a custom per-cpu vmbus handler.
>>
>> Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
>> ---
>>   arch/x86/kernel/cpu/mshyperv.c | 12 ------------
>>   drivers/hv/hv_common.c         |  9 +++++++--
>>   drivers/hv/vmbus_drv.c         | 17 +++++++++--------
>>   include/asm-generic/mshyperv.h |  1 +
>>   4 files changed, 17 insertions(+), 22 deletions(-)
>>
>> diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
>> index 89a2eb8a0722..68706ff5880e 100644
>> --- a/arch/x86/kernel/cpu/mshyperv.c
>> +++ b/arch/x86/kernel/cpu/mshyperv.c
>> @@ -145,7 +145,6 @@ void hv_set_msr(unsigned int reg, u64 value)
>>   EXPORT_SYMBOL_GPL(hv_set_msr);
>>
>>   static void (*mshv_handler)(void);
>> -static void (*vmbus_handler)(void);
>>   static void (*hv_stimer0_handler)(void);
>>   static void (*hv_kexec_handler)(void);
>>   static void (*hv_crash_handler)(struct pt_regs *regs);
>> @@ -172,17 +171,6 @@ void hv_setup_mshv_handler(void (*handler)(void))
>>   	mshv_handler = handler;
>>   }
>>
>> -void hv_setup_vmbus_handler(void (*handler)(void))
>> -{
>> -	vmbus_handler = handler;
>> -}
>> -
>> -void hv_remove_vmbus_handler(void)
>> -{
>> -	/* We have no way to deallocate the interrupt gate */
>> -	vmbus_handler = NULL;
>> -}
>> -
>>   /*
>>    * Routines to do per-architecture handling of stimer0
>>    * interrupts when in Direct Mode
>> diff --git a/drivers/hv/hv_common.c b/drivers/hv/hv_common.c
>> index e8633bc51d56..eb7b0028b45d 100644
>> --- a/drivers/hv/hv_common.c
>> +++ b/drivers/hv/hv_common.c
>> @@ -758,13 +758,18 @@ bool __weak hv_isolation_type_tdx(void)
>>   }
>>   EXPORT_SYMBOL_GPL(hv_isolation_type_tdx);
>>
>> -void __weak hv_setup_vmbus_handler(void (*handler)(void))
>> +void (*vmbus_handler)(void);
>> +EXPORT_SYMBOL_GPL(vmbus_handler);
>> +
>> +void hv_setup_vmbus_handler(void (*handler)(void))
>>   {
>> +	vmbus_handler = handler;
>>   }
>>   EXPORT_SYMBOL_GPL(hv_setup_vmbus_handler);
>>
>> -void __weak hv_remove_vmbus_handler(void)
>> +void hv_remove_vmbus_handler(void)
>>   {
>> +	vmbus_handler = NULL;
>>   }
>>   EXPORT_SYMBOL_GPL(hv_remove_vmbus_handler);
> 
> I'd suggest moving hv_setup_vmbus_handler() and
> hv_remove_vmbus_handler() above or below the group
> of __weak stubs in this source code file. There's a comment
> describing the purpose of these __weak functions, and
> intermixing these two functions that are no longer __weak
> produces something of a jumble.
> 

Acked.

>>
>> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
>> index bc4fc1951ae1..052ca8b11cee 100644
>> --- a/drivers/hv/vmbus_drv.c
>> +++ b/drivers/hv/vmbus_drv.c
>> @@ -1415,7 +1415,8 @@ EXPORT_SYMBOL_FOR_MODULES(vmbus_isr, "mshv_vtl");
>>
>>   static irqreturn_t vmbus_percpu_isr(int irq, void *dev_id)
>>   {
>> -	vmbus_isr();
>> +	if (vmbus_handler)
>> +		vmbus_handler();
> 
> Is it necessary to test vmbus_handler first? From what I can
> see, it is always set before the per-cpu interrupt is setup.

After the shuffle of hv_remove_vmbus_handler() and freeing the irq, it 
can be safely removed. When I was setting the vmbus_handler to NULL 
first, before freeing the IRQ, this was required.

> 
>>   	return IRQ_HANDLED;
>>   }
>>
>> @@ -1517,8 +1518,10 @@ static int vmbus_bus_init(void)
>>   		vmbus_irq_initialized = true;
>>   	}
>>
>> +	hv_setup_vmbus_handler(vmbus_isr);
>> +
>>   	if (vmbus_irq == -1) {
>> -		hv_setup_vmbus_handler(vmbus_isr);
>> +		/* x86: sysvec handler uses vmbus_handler directly */
>>   	} else {
>>   		ret = request_percpu_irq(vmbus_irq, vmbus_percpu_isr,
>>   				"Hyper-V VMbus", &vmbus_evt);
>> @@ -1553,9 +1556,8 @@ static int vmbus_bus_init(void)
>>   	return 0;
>>
>>   err_connect:
>> -	if (vmbus_irq == -1)
>> -		hv_remove_vmbus_handler();
>> -	else
>> +	hv_remove_vmbus_handler();
>> +	if (vmbus_irq != -1)
>>   		free_percpu_irq(vmbus_irq, &vmbus_evt);
> 
> These operations should be reordered so they are the inverse
> of how they are setup.  I.e., free_percpu_irq() first, then remove
> the VMBus handler. That's just good standard practice unless
> there's a specific reason to do the cleanup ordering differently. In
> fact, hv_remove_vmbus_handler() needs to be moved down
> to the err_setup label so it's done if request_percpu_irq()
> fails.


Acked. I will do the same for other hv_remove_vmbus_handler() as well.

> 
>>   err_setup:
>>   	if (IS_ENABLED(CONFIG_PREEMPT_RT) && vmbus_irq_initialized) {
>> @@ -3026,9 +3028,8 @@ static void __exit vmbus_exit(void)
>>   	vmbus_connection.conn_state = DISCONNECTED;
>>   	hv_stimer_global_cleanup();
>>   	vmbus_disconnect();
>> -	if (vmbus_irq == -1)
>> -		hv_remove_vmbus_handler();
>> -	else
>> +	hv_remove_vmbus_handler();
>> +	if (vmbus_irq != -1)
>>   		free_percpu_irq(vmbus_irq, &vmbus_evt);
> 
> Ordering should be changed here as well so it is the inverse
> of how things are set up.
> 
>>   	if (IS_ENABLED(CONFIG_PREEMPT_RT) && vmbus_irq_initialized) {
>>   		smpboot_unregister_percpu_thread(&vmbus_irq_threads);
>> diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyperv.h
>> index 2810aa05dc73..db183c8cfb95 100644
>> --- a/include/asm-generic/mshyperv.h
>> +++ b/include/asm-generic/mshyperv.h
>> @@ -179,6 +179,7 @@ static inline u64 hv_generate_guest_id(u64 kernel_version)
>>
>>   int hv_get_hypervisor_version(union hv_hypervisor_version_info *info);
>>
>> +extern void (*vmbus_handler)(void);
>>   void hv_setup_vmbus_handler(void (*handler)(void));
>>   void hv_remove_vmbus_handler(void);
>>   void hv_setup_stimer0_handler(void (*handler)(void));
>> --
>> 2.43.0
>>


Regards,
Naman


From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 78E8637A4B9;
	Wed, 29 Apr 2026 09:56:21 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=13.77.154.182
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1777456582; cv=none; b=LMHTyyjJ3K2BgsccHKxXxYlXu9g1D7QdvKWrAc41hO2aVpzmsHgnFFA5i3JAiRvDrrOTaZiNH2VaEaK/LWaXLqxZkQfI+K7PPe55GaI+J50uwd0vbPa0Y08FfNJLG8e08k6jA6MMM5N1IfY9ztx05Lq06ogqfY9nWgw7oULXHrI=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1777456582; c=relaxed/simple;
	bh=9IQPYGsCC8MNRxxreHbr7G9gvHL7AHkj3MT4L14YPMI=;
	h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
	 In-Reply-To:Content-Type; b=QOW2mvUZDBa16rEy3aDHI+5RzhashG0YAC9iX5ndyArN1mJ1Ig96HV9V0MEhqxK309dh/EVxN63unXmfvP+ywm2L9j4Ol1Q9tQR/iOhu+BHLSbb4C09ktxTmjOlXSdgkpPdGTGwaECSoi/ev2z8k2vEwrHDSYzDkj3iWTbeehpw=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com; spf=pass smtp.mailfrom=linux.microsoft.com; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b=ILCjIujf; arc=none smtp.client-ip=13.77.154.182
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="ILCjIujf"
Received: from [10.95.65.160] (unknown [167.220.238.0])
	by linux.microsoft.com (Postfix) with ESMTPSA id 2103F20B716C;
	Wed, 29 Apr 2026 02:56:13 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 2103F20B716C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1777456581;
	bh=jSJDu6U+dMGP84Q05SBTqIA3q3Seu4SJCCzESfH4Y30=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=ILCjIujfPfcMaiUqimA6X2yISFYX2kESPbh9QbO0KgBHOI0fElpyh2Nz6I7toMeNj
	 oPya2ORByjQhi5Un9bNdLQVnoaDnDSa7dOZYOeY7j/kOutZaT0fySJMgAyrDhOQZgn
	 FG+1X5uRaBt0DepLt6oOL+AChQHCQAFewmyQ7XKA=
Message-ID: <f4059f5d-a82b-40c2-942e-3e24cefab94f@linux.microsoft.com>
Date: Wed, 29 Apr 2026 15:26:11 +0530
Precedence: bulk
X-Mailing-List: linux-arch@vger.kernel.org
List-Id: <linux-arch.vger.kernel.org>
List-Subscribe: <mailto:linux-arch+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-arch+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 07/15] arm64: hyperv: Add support for
 mshv_vtl_return_call
To: Mark Rutland <mark.rutland@arm.com>, Marc Zyngier <maz@kernel.org>
Cc: "K . Y . Srinivasan" <kys@microsoft.com>,
 Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>,
 Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>,
 Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>,
 Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
 Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>,
 x86@kernel.org, "H . Peter Anvin" <hpa@zytor.com>,
 Arnd Bergmann <arnd@arndb.de>, Paul Walmsley <pjw@kernel.org>,
 Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu>,
 Alexandre Ghiti <alex@ghiti.fr>, Michael Kelley <mhklinux@outlook.com>,
 Marc Zyngier <maz@kernel.org>, Timothy Hayes <timothy.hayes@arm.com>,
 Lorenzo Pieralisi <lpieralisi@kernel.org>,
 Sascha Bischoff <sascha.bischoff@arm.com>,
 mrigendrachaubey <mrigendra.chaubey@gmail.com>,
 linux-hyperv@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
 linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
 linux-riscv@lists.infradead.org, vdso@mailbox.org,
 ssengar@linux.microsoft.com
References: <20260423124206.2410879-1-namjain@linux.microsoft.com>
 <20260423124206.2410879-8-namjain@linux.microsoft.com>
 <aeolHwXHFH4AnX_n@J2N7QTR9R3.cambridge.arm.com>
Content-Language: en-US
From: Naman Jain <namjain@linux.microsoft.com>
In-Reply-To: <aeolHwXHFH4AnX_n@J2N7QTR9R3.cambridge.arm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit



On 4/23/2026 7:26 PM, Mark Rutland wrote:
> On Thu, Apr 23, 2026 at 12:41:57PM +0000, Naman Jain wrote:
>> Add the arm64 variant of mshv_vtl_return_call() to support the MSHV_VTL
>> driver on arm64. This function enables the transition between Virtual
>> Trust Levels (VTLs) in MSHV_VTL when the kernel acts as a paravisor.
>>
>> Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
>> Reviewed-by: Roman Kisel <vdso@mailbox.org>
>> Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
>> ---
>>   arch/arm64/hyperv/Makefile        |   1 +
>>   arch/arm64/hyperv/hv_vtl.c        | 158 ++++++++++++++++++++++++++++++
>>   arch/arm64/include/asm/mshyperv.h |  13 +++
>>   arch/x86/include/asm/mshyperv.h   |   2 -
>>   drivers/hv/mshv_vtl.h             |   3 +
>>   include/asm-generic/mshyperv.h    |   2 +
>>   6 files changed, 177 insertions(+), 2 deletions(-)
>>   create mode 100644 arch/arm64/hyperv/hv_vtl.c
>>
>> diff --git a/arch/arm64/hyperv/Makefile b/arch/arm64/hyperv/Makefile
>> index 87c31c001da9..9701a837a6e1 100644
>> --- a/arch/arm64/hyperv/Makefile
>> +++ b/arch/arm64/hyperv/Makefile
>> @@ -1,2 +1,3 @@
>>   # SPDX-License-Identifier: GPL-2.0
>>   obj-y		:= hv_core.o mshyperv.o
>> +obj-$(CONFIG_HYPERV_VTL_MODE)	+= hv_vtl.o
>> diff --git a/arch/arm64/hyperv/hv_vtl.c b/arch/arm64/hyperv/hv_vtl.c
>> new file mode 100644
>> index 000000000000..59cbeb74e7b9
>> --- /dev/null
>> +++ b/arch/arm64/hyperv/hv_vtl.c
>> @@ -0,0 +1,158 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Copyright (C) 2026, Microsoft, Inc.
>> + *
>> + * Authors:
>> + *     Roman Kisel <romank@linux.microsoft.com>
>> + *     Naman Jain <namjain@linux.microsoft.com>
>> + */
>> +
>> +#include <asm/mshyperv.h>
>> +#include <asm/neon.h>
>> +#include <linux/export.h>
>> +
>> +void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0)
>> +{
>> +	struct user_fpsimd_state fpsimd_state;
>> +	u64 base_ptr = (u64)vtl0->x;
>> +
>> +	/*
>> +	 * Obtain the CPU FPSIMD registers for VTL context switch.
>> +	 * This saves the current task's FP/NEON state and allows us to
>> +	 * safely load VTL0's FP/NEON context for the hypercall.
>> +	 */
>> +	kernel_neon_begin(&fpsimd_state);
>> +
>> +	/*
>> +	 * VTL switch for ARM64 platform - managing VTL0's CPU context.
>> +	 * We explicitly use the stack to save the base pointer, and use x16
>> +	 * as our working register for accessing the context structure.
>> +	 *
>> +	 * Register Handling:
>> +	 * - X0-X17: Saved/restored (general-purpose, shared for VTL communication)
>> +	 * - X18: NOT touched - hypervisor-managed per-VTL (platform register)
>> +	 * - X19-X30: Saved/restored (part of VTL0's execution context)
>> +	 * - Q0-Q31: Saved/restored (128-bit NEON/floating-point registers, shared)
>> +	 * - SP: Not in structure, hypervisor-managed per-VTL
>> +	 *
>> +	 * X29 (FP) and X30 (LR) are in the structure and must be saved/restored
>> +	 * as part of VTL0's complete execution state.
>> +	 */
>> +	asm __volatile__ (
>> +		/* Save base pointer to stack explicitly, then load into x16 */
>> +		"str %0, [sp, #-16]!\n\t"     /* Push base pointer onto stack */
>> +		"mov x16, %0\n\t"             /* Load base pointer into x16 */
>> +		/* Volatile registers (Windows ARM64 ABI: x0-x17) */
>> +		"ldp x0, x1, [x16]\n\t"
>> +		"ldp x2, x3, [x16, #(2*8)]\n\t"
>> +		"ldp x4, x5, [x16, #(4*8)]\n\t"
>> +		"ldp x6, x7, [x16, #(6*8)]\n\t"
>> +		"ldp x8, x9, [x16, #(8*8)]\n\t"
>> +		"ldp x10, x11, [x16, #(10*8)]\n\t"
>> +		"ldp x12, x13, [x16, #(12*8)]\n\t"
>> +		"ldp x14, x15, [x16, #(14*8)]\n\t"
>> +		/* x16 will be loaded last, after saving base pointer */
>> +		"ldr x17, [x16, #(17*8)]\n\t"
>> +		/* x18 is hypervisor-managed per-VTL - DO NOT LOAD */
>> +
>> +		/* General-purpose registers: x19-x30 */
>> +		"ldp x19, x20, [x16, #(19*8)]\n\t"
>> +		"ldp x21, x22, [x16, #(21*8)]\n\t"
>> +		"ldp x23, x24, [x16, #(23*8)]\n\t"
>> +		"ldp x25, x26, [x16, #(25*8)]\n\t"
>> +		"ldp x27, x28, [x16, #(27*8)]\n\t"
>> +
>> +		/* Frame pointer and link register */
>> +		"ldp x29, x30, [x16, #(29*8)]\n\t"
>> +
>> +		/* Shared NEON/FP registers: Q0-Q31 (128-bit) */
>> +		"ldp q0, q1, [x16, #(32*8)]\n\t"
>> +		"ldp q2, q3, [x16, #(32*8 + 2*16)]\n\t"
>> +		"ldp q4, q5, [x16, #(32*8 + 4*16)]\n\t"
>> +		"ldp q6, q7, [x16, #(32*8 + 6*16)]\n\t"
>> +		"ldp q8, q9, [x16, #(32*8 + 8*16)]\n\t"
>> +		"ldp q10, q11, [x16, #(32*8 + 10*16)]\n\t"
>> +		"ldp q12, q13, [x16, #(32*8 + 12*16)]\n\t"
>> +		"ldp q14, q15, [x16, #(32*8 + 14*16)]\n\t"
>> +		"ldp q16, q17, [x16, #(32*8 + 16*16)]\n\t"
>> +		"ldp q18, q19, [x16, #(32*8 + 18*16)]\n\t"
>> +		"ldp q20, q21, [x16, #(32*8 + 20*16)]\n\t"
>> +		"ldp q22, q23, [x16, #(32*8 + 22*16)]\n\t"
>> +		"ldp q24, q25, [x16, #(32*8 + 24*16)]\n\t"
>> +		"ldp q26, q27, [x16, #(32*8 + 26*16)]\n\t"
>> +		"ldp q28, q29, [x16, #(32*8 + 28*16)]\n\t"
>> +		"ldp q30, q31, [x16, #(32*8 + 30*16)]\n\t"
>> +
>> +		/* Now load x16 itself */
>> +		"ldr x16, [x16, #(16*8)]\n\t"
>> +
>> +		/* Return to the lower VTL */
>> +		"hvc #3\n\t"
> 
> NAK to this.
> 
> * This is a non-SMCCC hypercall, which we have NAK'd in general in the
>    past for various reasons that I am not going to rehash here.
> 
> * It's not clear how this is going to be extended with necessary
>    architecture state in future (e.g. SVE, SME). This is not
>    future-proof, and I don't believe this is maintainable.
> 
> * This breaks general requirements for reliable stacktracing by
>    clobbering state (e.g. x29) that we depend upon being valid AT ALL
>    TIMES outside of entry code.
> 
> * IMO, if this needs to be saved/restored, that should happen in
>    whatever you are calling.
> 
> Mark.


Merging threads for addressing comments from Mark Rutland and Marc 
Zyngier on this patch.

Thanks for reviewing the changes. Please allow me to briefly explain the 
use case here and then address your comments.

Hyper-V's Virtual Trust Levels (VTLs) provide hardware-enforced 
isolation within a single VM, analogous to ARM TrustZone. The kernel 
runs in VTL2 (higher privilege) as a "paravisor", a security monitor 
that handles intercepts for the primary OS in VTL0 (lower privilege). 
The VTL switch (mshv_vtl_return_call) is functionally equivalent to 
KVM's guest enter/exit. It saves VTL2 state, loads VTL0's GPRs other 
registers from a shared context structure, issues hvc #3 to let VTL0 
run, and on return saves VTL0's updated state back.

Coming to the problems with the code, I have identified a few ways to 
address them.

I can put the assembly code in a separate .S file with 
SYM_FUNC_START/SYM_FUNC_END and marked as noinstr, to prevent 
ftrace/kprobes from instrumenting between the GPR load and the hvc, 
which could have corrupted VTL0 register state. This should solve x29 
clobbering, stack tracing problems.

I should use kernel_neon_begin()/kernel_neon_end() to save/restore the 
full extended FP state of the current task in VTL2. VTL0's Q0-Q31 can be 
loaded/saved separately via fpsimd_load_state()/fpsimd_save_state(). 
This way, the assembly touches none of the SIMD registers. This is 
SVE/SME-safe for VTL2's task state. VTL0 still only carries Q0-Q31 in 
the context struct, and extending to SVE, SME is a future context struct 
change, which will need Hyper-V arm64 ABI support.
This way, VTL2's callee-saved regs (x19-x28, x29, x30) are explicitly 
saved to the stack frame at the top and restored at the bottom of 
assembly code. The C caller (in hv_vtl.c) is a clean function call.

Regarding Non-SMCCC "hvc #3" call, I have a limitation here owing to the 
ABI that is defined by the Hyper-V hypervisor. Fixing this requires a 
hypervisor-side change to support SMCCC-style dispatch for VTL return. 
Until then, hvc #3 is the only working interface. Moreover there would 
be backward compatibility issues with this new ABI interface, if at all 
it is added.

Link to TLFS: 
https://learn.microsoft.com/en-us/virtualization/hyper-v-on-windows/tlfs/vsm#on-arm64-platforms-3

Please correct me if any of the above is incorrect or if I should be 
looking at some other existing examples to solve these problems.

Regards,
Naman

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 485931AC44D;
	Wed, 29 Apr 2026 09:56:55 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=13.77.154.182
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1777456619; cv=none; b=VCL9Su0kKEsFP1PocCGXua0P4BkDzjvTjH+ypqQwwRt4AwUkKLMheB3ZxKc1gMJQ74l0NQE1MiZ21I7OkXuVD7fqxbgsdeh7SoBNBJhas9265L30L4ndYqklaO3UdwKlvguDLVoyBEk4F66SC3wvEIfF2NJYf+mLQFtjQ7JOXss=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1777456619; c=relaxed/simple;
	bh=S4Ys+ZR/A3fxX+pYyXStcLU1VTVHaP0MC1rIdwbZbGw=;
	h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
	 In-Reply-To:Content-Type; b=iMsFCLmbyL3jGgJc23dKtNf2GQ0ylJ5HBTnJEPgJ9o0s5aVkS2wtC66PU0FMTvGCZC6ZBHATIxQVaNsWS1lK573KZJj9lKLY7/G7qJUE/04oWpK23kNH+EOUA5wfU92oA4uZz5xPLy7kQwyXZtZxQZnHI+FSu9daiKuNaHxvzZE=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com; spf=pass smtp.mailfrom=linux.microsoft.com; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b=j3t1KqCo; arc=none smtp.client-ip=13.77.154.182
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="j3t1KqCo"
Received: from [10.95.65.160] (unknown [167.220.238.0])
	by linux.microsoft.com (Postfix) with ESMTPSA id 022BB20B716D;
	Wed, 29 Apr 2026 02:56:47 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 022BB20B716D
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1777456615;
	bh=QgIpyU8QZGJkXf492lXwNUttCaD3J45IhKenqaCb8JU=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=j3t1KqCo0xfeLFi9dtOHcVl1enYVvkTTCWZf/S6+1njDs+5WLIKxyCr+MaZT+dX6s
	 1GtfPpoCrizCdwBgAuRmIgUqS6cRpZ84PZrt9W+C1tH19AeqXBBCOSZB5ScCq91arB
	 2ycNK80H4Ji9sx2/5Zebo999PZQBXpkGPAZqdQ58=
Message-ID: <516a4e65-3a4d-4e09-b445-28cb740b5653@linux.microsoft.com>
Date: Wed, 29 Apr 2026 15:26:43 +0530
Precedence: bulk
X-Mailing-List: linux-arch@vger.kernel.org
List-Id: <linux-arch.vger.kernel.org>
List-Subscribe: <mailto:linux-arch+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-arch+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 07/15] arm64: hyperv: Add support for
 mshv_vtl_return_call
To: Michael Kelley <mhklinux@outlook.com>,
 "K . Y . Srinivasan" <kys@microsoft.com>,
 Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>,
 Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>,
 Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>,
 Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
 Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>,
 "x86@kernel.org" <x86@kernel.org>, "H . Peter Anvin" <hpa@zytor.com>,
 Arnd Bergmann <arnd@arndb.de>, Paul Walmsley <pjw@kernel.org>,
 Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu>,
 Alexandre Ghiti <alex@ghiti.fr>
Cc: Marc Zyngier <maz@kernel.org>, Timothy Hayes <timothy.hayes@arm.com>,
 Lorenzo Pieralisi <lpieralisi@kernel.org>,
 Sascha Bischoff <sascha.bischoff@arm.com>,
 mrigendrachaubey <mrigendra.chaubey@gmail.com>,
 "linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
 "linux-arm-kernel@lists.infradead.org"
 <linux-arm-kernel@lists.infradead.org>,
 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
 "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
 "linux-riscv@lists.infradead.org" <linux-riscv@lists.infradead.org>,
 "vdso@mailbox.org" <vdso@mailbox.org>,
 "ssengar@linux.microsoft.com" <ssengar@linux.microsoft.com>
References: <20260423124206.2410879-1-namjain@linux.microsoft.com>
 <20260423124206.2410879-8-namjain@linux.microsoft.com>
 <SN6PR02MB4157C147A1B915F9B45D3B74D4362@SN6PR02MB4157.namprd02.prod.outlook.com>
Content-Language: en-US
From: Naman Jain <namjain@linux.microsoft.com>
In-Reply-To: <SN6PR02MB4157C147A1B915F9B45D3B74D4362@SN6PR02MB4157.namprd02.prod.outlook.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit



On 4/27/2026 11:08 AM, Michael Kelley wrote:
> From: Naman Jain <namjain@linux.microsoft.com> Sent: Thursday, April 23, 2026 5:42 AM
>>
>> Add the arm64 variant of mshv_vtl_return_call() to support the MSHV_VTL
>> driver on arm64. This function enables the transition between Virtual
>> Trust Levels (VTLs) in MSHV_VTL when the kernel acts as a paravisor.
>>
>> Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
>> Reviewed-by: Roman Kisel <vdso@mailbox.org>
>> Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
>> ---
>>   arch/arm64/hyperv/Makefile        |   1 +
>>   arch/arm64/hyperv/hv_vtl.c        | 158 ++++++++++++++++++++++++++++++
>>   arch/arm64/include/asm/mshyperv.h |  13 +++
>>   arch/x86/include/asm/mshyperv.h   |   2 -
>>   drivers/hv/mshv_vtl.h             |   3 +
>>   include/asm-generic/mshyperv.h    |   2 +
>>   6 files changed, 177 insertions(+), 2 deletions(-)
>>   create mode 100644 arch/arm64/hyperv/hv_vtl.c
>>
> 
> [snip]
> 
>> diff --git a/arch/arm64/include/asm/mshyperv.h b/arch/arm64/include/asm/mshyperv.h
>> index 585b23a26f1b..9eb0e5999f29 100644
>> --- a/arch/arm64/include/asm/mshyperv.h
>> +++ b/arch/arm64/include/asm/mshyperv.h
>> @@ -60,6 +60,18 @@ static inline u64 hv_get_non_nested_msr(unsigned int reg)
>>   				ARM_SMCCC_SMC_64,		\
>>   				ARM_SMCCC_OWNER_VENDOR_HYP,	\
>>   				HV_SMCCC_FUNC_NUMBER)
>> +
>> +struct mshv_vtl_cpu_context {
>> +/*
>> + * x18 is managed by the hypervisor. It won't be reloaded from this array.
>> + * It is included here for convenience in array indexing.
>> + * 'rsvd' field serves as alignment padding so q[] starts at offset 32*8=256.
>> + */
>> +	__u64 x[31];
>> +	__u64 rsvd;
>> +	__uint128_t q[32];
>> +};
>> +
>>   #ifdef CONFIG_HYPERV_VTL_MODE
>>   /*
>>    * Get/Set the register. If the function returns `1`, that must be done via
>> @@ -69,6 +81,7 @@ static inline int hv_vtl_get_set_reg(struct hv_register_assoc *regs,
>> bool set, b
>>   {
>>   	return 1;
>>   }
>> +
> 
> This appears to be a spurious blank line being added since there
> are no other changes in the vicinity.

Acked.

> 
>>   #endif
>>
>>   #include <asm-generic/mshyperv.h>
>> diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
>> index 08278547b84c..b4d80c9a673a 100644
>> --- a/arch/x86/include/asm/mshyperv.h
>> +++ b/arch/x86/include/asm/mshyperv.h
>> @@ -286,7 +286,6 @@ struct mshv_vtl_cpu_context {
>>   #ifdef CONFIG_HYPERV_VTL_MODE
>>   void __init hv_vtl_init_platform(void);
>>   int __init hv_vtl_early_init(void);
>> -void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0);
>>   void mshv_vtl_return_call_init(u64 vtl_return_offset);
>>   void mshv_vtl_return_hypercall(void);
>>   void __mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0);
>> @@ -294,7 +293,6 @@ int hv_vtl_get_set_reg(struct hv_register_assoc *regs, bool set,
>> bool shared);
>>   #else
>>   static inline void __init hv_vtl_init_platform(void) {}
>>   static inline int __init hv_vtl_early_init(void) { return 0; }
>> -static inline void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0) {}
>>   static inline void mshv_vtl_return_call_init(u64 vtl_return_offset) {}
>>   static inline void mshv_vtl_return_hypercall(void) {}
>>   static inline void __mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0) {}
>> diff --git a/drivers/hv/mshv_vtl.h b/drivers/hv/mshv_vtl.h
>> index a6eea52f7aa2..103f07371f3f 100644
>> --- a/drivers/hv/mshv_vtl.h
>> +++ b/drivers/hv/mshv_vtl.h
>> @@ -22,4 +22,7 @@ struct mshv_vtl_run {
>>   	char vtl_ret_actions[MSHV_MAX_RUN_MSG_SIZE];
>>   };
>>
>> +static_assert(sizeof(struct mshv_vtl_cpu_context) <= 1024,
>> +	      "struct mshv_vtl_cpu_context exceeds reserved space in struct
>> mshv_vtl_run");
>> +
>>   #endif /* _MSHV_VTL_H */
>> diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyperv.h
>> index db183c8cfb95..8cdf2a9fbdfb 100644
>> --- a/include/asm-generic/mshyperv.h
>> +++ b/include/asm-generic/mshyperv.h
>> @@ -396,8 +396,10 @@ static inline int hv_deposit_memory(u64 partition_id, u64 status)
>>
>>   #if IS_ENABLED(CONFIG_HYPERV_VTL_MODE)
>>   u8 __init get_vtl(void);
>> +void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0);
>>   #else
>>   static inline u8 get_vtl(void) { return 0; }
>> +static inline void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0) {}
> 
> Is this stub needed? Maybe I missed something, but it looks to me like none
> of the code that calls this gets built unless CONFIG_HYPERV_VTL_MODE is set.
> See further comments about stubs in Patch 8 of this series.
> 

Config dependencies would handle such cases, and this is not required. I 
saw similar stubs added in the code, so I thought this is a norm that 
should be followed, and not rely on config dependencies.
I can remove it.

Regards,
Naman


From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 070BD39B962;
	Wed, 29 Apr 2026 09:57:32 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=13.77.154.182
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1777456653; cv=none; b=St87I+Xu/qamZtHUno9r1yt+Si9pWm66d3n7j6j+kTSg/2x5DuyAbK1oD3GSZCqxGnbSpQGfCWRd1WHt+2g+KhHZxH7rwO6e+Jm9hISMQG+VDNmDcnPMkCX9ZMVY2B0WCXGoqhpB4nR+5gPQczAdJdg5Hxz4zXy7cY9UN8VZpnI=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1777456653; c=relaxed/simple;
	bh=DgWvSVm0t3Tm58/J3QHKKBz4VeXvse0bJERoO+L+XOA=;
	h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
	 In-Reply-To:Content-Type; b=QQRBxaQr6phThinVG9gwPqcKm6nxDyQKtp1cBQGc2/Pp7UnNolbfN5bKotadg8/G4+eEL3fR30ewSe3RgI1SO0tD48y1TGCC4fAaTX3Tk99LdHE1aplaeOlm4GJinsF+C1s/yk4PknjO+nYWFT5xmGDuD97O9P3FAe/AKL3glk8=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com; spf=pass smtp.mailfrom=linux.microsoft.com; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b=Q31XCORO; arc=none smtp.client-ip=13.77.154.182
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="Q31XCORO"
Received: from [10.95.65.160] (unknown [167.220.238.0])
	by linux.microsoft.com (Postfix) with ESMTPSA id 5250A20B716C;
	Wed, 29 Apr 2026 02:57:25 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 5250A20B716C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1777456652;
	bh=Umh2GNLzS0ZLJ1ouGA7sN5L/Audjee+GTfXIQgbar64=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=Q31XCOROwAjmtXRERBx2iF+/+sJsH2ybABfnJCzFn77NWB9EVyO4d6UDaaSUN2seb
	 YQ7d0/CyN4ooJv9sS8ZRGDqMJBY896FQHOvEKQgI5tVaj4mJi2D6hDXN+gA0IZ5wgq
	 80ZbIizjLbl6bTb0czS/dH3jkSHeHVV2s6z/Ha8s=
Message-ID: <80efa86b-de96-438c-ac04-fda22c655500@linux.microsoft.com>
Date: Wed, 29 Apr 2026 15:27:20 +0530
Precedence: bulk
X-Mailing-List: linux-arch@vger.kernel.org
List-Id: <linux-arch.vger.kernel.org>
List-Subscribe: <mailto:linux-arch+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-arch+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 08/15] Drivers: hv: Move
 hv_call_(get|set)_vp_registers() declarations
To: Michael Kelley <mhklinux@outlook.com>,
 "K . Y . Srinivasan" <kys@microsoft.com>,
 Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>,
 Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>,
 Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>,
 Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
 Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>,
 "x86@kernel.org" <x86@kernel.org>, "H . Peter Anvin" <hpa@zytor.com>,
 Arnd Bergmann <arnd@arndb.de>, Paul Walmsley <pjw@kernel.org>,
 Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu>,
 Alexandre Ghiti <alex@ghiti.fr>
Cc: Marc Zyngier <maz@kernel.org>, Timothy Hayes <timothy.hayes@arm.com>,
 Lorenzo Pieralisi <lpieralisi@kernel.org>,
 Sascha Bischoff <sascha.bischoff@arm.com>,
 mrigendrachaubey <mrigendra.chaubey@gmail.com>,
 "linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
 "linux-arm-kernel@lists.infradead.org"
 <linux-arm-kernel@lists.infradead.org>,
 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
 "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
 "linux-riscv@lists.infradead.org" <linux-riscv@lists.infradead.org>,
 "vdso@mailbox.org" <vdso@mailbox.org>,
 "ssengar@linux.microsoft.com" <ssengar@linux.microsoft.com>
References: <20260423124206.2410879-1-namjain@linux.microsoft.com>
 <20260423124206.2410879-9-namjain@linux.microsoft.com>
 <SN6PR02MB4157852404B5258EF13A5450D4362@SN6PR02MB4157.namprd02.prod.outlook.com>
Content-Language: en-US
From: Naman Jain <namjain@linux.microsoft.com>
In-Reply-To: <SN6PR02MB4157852404B5258EF13A5450D4362@SN6PR02MB4157.namprd02.prod.outlook.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit



On 4/27/2026 11:09 AM, Michael Kelley wrote:
> From: Naman Jain <namjain@linux.microsoft.com> Sent: Thursday, April 23, 2026 5:42 AM
>>
>> Move hv_call_get_vp_registers() and hv_call_set_vp_registers()
>> declarations from drivers/hv/mshv.h to include/asm-generic/mshyperv.h.
>>
>> These functions are defined in mshv_common.c and are going to be called
>> from both drivers/hv/ and arch/x86/hyperv/hv_vtl.c. The latter never
>> included mshv.h, relying on implicit declaration visibility. Moving the
>> declarations to the arch-generic Hyper-V header makes them properly
>> visible to all architecture-specific callers.
>>
>> Provide static inline stubs returning -EOPNOTSUPP when neither
>> CONFIG_MSHV_ROOT nor CONFIG_MSHV_VTL is enabled.
> 
> Looking at the drivers/hv/Kconfig, it's possible to build with
> CONFIG_HYPERV_VTL_MODE=y, but not CONFIG_MSHV_VTL. In such a
> case, mshv_common.o doesn't get built, which is why the stubs are
> needed. Is such a configuration desirable for some scenarios?
> 
> I wonder if having CONFIG_HYPERV_VTL_MODE force the building of
> mshv_common.o would be a better approach. Then the stubs wouldn't
> be needed. The "ifneq" statement in drivers/hv/Makefile could use
> CONFIG_HYPERV_VTL_MODE instead of CONFIG_MSHV_VTL, and
> everything would be good since CONFIG_MSHV_VTL depends on
> CONFIG_HYPERV_VTL_MODE.
> 

This looks good. I'll try this and make the changes. In case there are 
some challenges with that, I'll revert back.


Regards,
Naman

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 7ACE83C555B;
	Wed, 29 Apr 2026 09:58:00 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=13.77.154.182
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1777456681; cv=none; b=oa88kzd9db1xN2Nm6ZsK18Cv4UdCJg/rLMSo0zfzstVQW3+BWEVuNK1Xt2E2mZKOwz3/hYXWIwYcMfz11B8uLrWTKZ6tAviA3sQBY/wzF+5RlYIqLhIzU2IUC2wD4j00s8rYBbNNNPxDNqz6mJheczaxPFDrGjRpZ6yPKXBePq8=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1777456681; c=relaxed/simple;
	bh=SGFpjDx3Fh1/hVA49l0HXV517Okej9pbdw/Axq6b/Ss=;
	h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
	 In-Reply-To:Content-Type; b=lZZxLQD4h5t2uSzL1Tibfzc7VW45+b5Ts9hEbJiftxFAhQ0hVq/uMniZJ9Nyulcoq/OuFP7Moh33vdD8kcJ3n/rs67V469+4mm69U2VV/OTVCr9Ld6v9syeaTKgqxyBNyPULUbKktiPJTmWa421/YGZ+sGLGqKyqlhIzNm8lTjg=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com; spf=pass smtp.mailfrom=linux.microsoft.com; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b=DwwTmFw8; arc=none smtp.client-ip=13.77.154.182
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="DwwTmFw8"
Received: from [10.95.65.160] (unknown [167.220.238.0])
	by linux.microsoft.com (Postfix) with ESMTPSA id AAA8120B716C;
	Wed, 29 Apr 2026 02:57:53 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com AAA8120B716C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1777456680;
	bh=glqfSPnZSBsC5GJM5wPOsyYjmETqsJsgYXJ3trO0o1Y=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=DwwTmFw8lT7PO8/kvWlFCX434M1go88YAYUFiOB7xJ1F+kocEhvrlQaUtuLbFgsgs
	 qpczmKHfDoN6xdxyX2dSLL7A3qYuWuJopov32H33TocopnxktApYAXXhDjaAJcsMV+
	 D/AJqX3CMxDfu3j87LG09egBB30+fv785wOjDaK0=
Message-ID: <567cf73b-6a48-4fc3-b312-9be6d71e2f22@linux.microsoft.com>
Date: Wed, 29 Apr 2026 15:27:49 +0530
Precedence: bulk
X-Mailing-List: linux-arch@vger.kernel.org
List-Id: <linux-arch.vger.kernel.org>
List-Subscribe: <mailto:linux-arch+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-arch+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 09/15] Drivers: hv: mshv_vtl: Move
 hv_vtl_configure_reg_page() to x86
To: Michael Kelley <mhklinux@outlook.com>,
 "K . Y . Srinivasan" <kys@microsoft.com>,
 Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>,
 Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>,
 Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>,
 Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
 Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>,
 "x86@kernel.org" <x86@kernel.org>, "H . Peter Anvin" <hpa@zytor.com>,
 Arnd Bergmann <arnd@arndb.de>, Paul Walmsley <pjw@kernel.org>,
 Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu>,
 Alexandre Ghiti <alex@ghiti.fr>
Cc: Marc Zyngier <maz@kernel.org>, Timothy Hayes <timothy.hayes@arm.com>,
 Lorenzo Pieralisi <lpieralisi@kernel.org>,
 Sascha Bischoff <sascha.bischoff@arm.com>,
 mrigendrachaubey <mrigendra.chaubey@gmail.com>,
 "linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
 "linux-arm-kernel@lists.infradead.org"
 <linux-arm-kernel@lists.infradead.org>,
 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
 "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
 "linux-riscv@lists.infradead.org" <linux-riscv@lists.infradead.org>,
 "vdso@mailbox.org" <vdso@mailbox.org>,
 "ssengar@linux.microsoft.com" <ssengar@linux.microsoft.com>
References: <20260423124206.2410879-1-namjain@linux.microsoft.com>
 <20260423124206.2410879-10-namjain@linux.microsoft.com>
 <SN6PR02MB4157467FDBC0203C67A67042D4362@SN6PR02MB4157.namprd02.prod.outlook.com>
Content-Language: en-US
From: Naman Jain <namjain@linux.microsoft.com>
In-Reply-To: <SN6PR02MB4157467FDBC0203C67A67042D4362@SN6PR02MB4157.namprd02.prod.outlook.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit



On 4/27/2026 11:10 AM, Michael Kelley wrote:
> From: Naman Jain <namjain@linux.microsoft.com> Sent: Thursday, April 23, 2026 5:42 AM
>>
>> Move hv_vtl_configure_reg_page() from drivers/hv/mshv_vtl_main.c to
>> arch/x86/hyperv/hv_vtl.c. The register page overlay is an x86-specific
>> feature that uses HV_X64_REGISTER_REG_PAGE, so its configuration belongs
>> in architecture-specific code.
>>
>> Move struct mshv_vtl_per_cpu and union hv_synic_overlay_page_msr to
>> include/asm-generic/mshyperv.h so they are visible to both arch and
>> driver code.
>>
>> Change the return type from void to bool so the caller can determine
>> whether the register page was successfully configured and set
>> mshv_has_reg_page accordingly.
>>
>> Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
>> ---
>>   arch/x86/hyperv/hv_vtl.c       | 32 ++++++++++++++++++++++
>>   drivers/hv/mshv_vtl_main.c     | 49 +++-------------------------------
>>   include/asm-generic/mshyperv.h | 17 ++++++++++++
>>   3 files changed, 53 insertions(+), 45 deletions(-)
>>

<snip>

>>   #if IS_ENABLED(CONFIG_HYPERV_VTL_MODE)
>> +/* SYNIC_OVERLAY_PAGE_MSR - internal, identical to hv_synic_simp */
> 
> This comment pre-dates your patch, but I don't understand the point
> it is trying to make. The comment is factually true, but I don't know
> why calling that out is relevant. The REG_PAGE MSR seems to be
> conceptually separate and distinct from the SIMP MSR, so the fact
> that the layouts are the same is just a coincidence. Or is there some
> relationship between the two MSRs that I'm not aware of, and the
> comment is trying (and failing?) to point out?

This was added as per suggestion from Nuno in my initial series for 
MSHV_VTL. If the reference in "identical to" is misleading, I should 
remove it.

https://lore.kernel.org/all/68143eb0-e6a7-4579-bedb-4c2ec5aaef6b@linux.microsoft.com/

Quoting:
"""
it is a generic structure that
appears to be used for several overlay page MSRs (SIMP, SIEF, etc).

But, the type doesn't appear in the hv*dk headers explicitly; it's just
used internally by the hypervisor.

I think it should be renamed with a hv_ prefix to indicate it's part of
the hypervisor ABI, and a brief comment with the provenance:

/* SYNIC_OVERLAY_PAGE_MSR - internal, identical to hv_synic_simp */
union hv_synic_overlay_page_msr {
	/* <snip> */
};
"""

> 
>> +union hv_synic_overlay_page_msr {
>> +	u64 as_uint64;
>> +	struct {
>> +		u64 enabled: 1;
>> +		u64 reserved: 11;
>> +		u64 pfn: 52;
>> +	} __packed;
>> +};
>> +
>>   u8 __init get_vtl(void);
>>   void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0);
>> +bool hv_vtl_configure_reg_page(struct mshv_vtl_per_cpu *per_cpu);
>>   #else
>>   static inline u8 get_vtl(void) { return 0; }
>>   static inline void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0) {}
>> +static inline bool hv_vtl_configure_reg_page(struct mshv_vtl_per_cpu *per_cpu) { return false; }
> 
> As with Patch 8, if CONFIG_HYPERV_VTL_MODE caused mshv_common.o
> to be built, this stub wouldn't be needed.
> 

Acked.


>>   #endif
>>
>>   #endif
>> --
>> 2.43.0
>>

Regards,
Naman

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id F3AF330B529;
	Wed, 29 Apr 2026 10:00:42 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=13.77.154.182
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1777456844; cv=none; b=kSyeRZpBOw3f01b9ayov7PBbbQpoOMySeIG4e6lGX3Zfpf1wKg0OTHuGHFpmYDFjzHY6LDNq5MExmDpbHjHkFlNjP+yjjeZ3xuy64+l4eUiryjRq5ZpmxYlror7PDAkWUJAP628DuEOwt9xlCpfxwe6kzAwLOa6ergMzkfi/uug=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1777456844; c=relaxed/simple;
	bh=nKq21MWKpJ9JRF+8U25wGOhHT9RcuOxZrDC3uu6+8yI=;
	h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
	 In-Reply-To:Content-Type; b=DhRUCbZk0reMixHho2qNs4rNl2CVJ6KmdGix7GVL7qz6z1xuxgB71pFflWOXJHklnK06aSwzJ7igwtfU5D3WjxzSJa3J8lBmsTx++3fUPRdASqH+pEatEMFqNgMJ2GYR1kgw2xB7BCukFzeELxJQjhqeMqrQOf+cPlslpKbdqtE=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com; spf=pass smtp.mailfrom=linux.microsoft.com; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b=pmZBcQL5; arc=none smtp.client-ip=13.77.154.182
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="pmZBcQL5"
Received: from [10.95.65.160] (unknown [167.220.238.0])
	by linux.microsoft.com (Postfix) with ESMTPSA id 78CBF20B716C;
	Wed, 29 Apr 2026 03:00:35 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 78CBF20B716C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1777456842;
	bh=BLsXGKx0T3J/8O/IzlEtJAB/hh15qSfJxIj3wYO8c+k=;
	h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
	b=pmZBcQL55VntaOUwjnbe7yQ613XZmm0eAELWs4e8kqgjMJ/vAx5wINzKEINE6T6UF
	 pC5sHNK0ET3Ppsu6Mk/rPZK3QdO80LceWGSGMUPMiwIGjuBfBDdVmyC9Xz/qG7ve0z
	 56Quia5hZp6RFqg7rp2xfw51fkC4J20f80jRQnBA=
Message-ID: <e47c0bbc-f46f-426d-bf3a-675df5b872d0@linux.microsoft.com>
Date: Wed, 29 Apr 2026 15:30:31 +0530
Precedence: bulk
X-Mailing-List: linux-arch@vger.kernel.org
List-Id: <linux-arch.vger.kernel.org>
List-Subscribe: <mailto:linux-arch+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-arch+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 12/15] mshv_vtl: Move VSM code page offset logic to x86
 files
To: Michael Kelley <mhklinux@outlook.com>,
 "K . Y . Srinivasan" <kys@microsoft.com>,
 Haiyang Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>,
 Dexuan Cui <decui@microsoft.com>, Long Li <longli@microsoft.com>,
 Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>,
 Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
 Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>,
 "x86@kernel.org" <x86@kernel.org>, "H . Peter Anvin" <hpa@zytor.com>,
 Arnd Bergmann <arnd@arndb.de>, Paul Walmsley <pjw@kernel.org>,
 Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu>,
 Alexandre Ghiti <alex@ghiti.fr>
Cc: Marc Zyngier <maz@kernel.org>, Timothy Hayes <timothy.hayes@arm.com>,
 Lorenzo Pieralisi <lpieralisi@kernel.org>,
 Sascha Bischoff <sascha.bischoff@arm.com>,
 mrigendrachaubey <mrigendra.chaubey@gmail.com>,
 "linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
 "linux-arm-kernel@lists.infradead.org"
 <linux-arm-kernel@lists.infradead.org>,
 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
 "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
 "linux-riscv@lists.infradead.org" <linux-riscv@lists.infradead.org>,
 "vdso@mailbox.org" <vdso@mailbox.org>,
 "ssengar@linux.microsoft.com" <ssengar@linux.microsoft.com>
References: <20260423124206.2410879-1-namjain@linux.microsoft.com>
 <20260423124206.2410879-13-namjain@linux.microsoft.com>
 <SN6PR02MB4157E0525DDDD153888F5AFBD4362@SN6PR02MB4157.namprd02.prod.outlook.com>
Content-Language: en-US
From: Naman Jain <namjain@linux.microsoft.com>
In-Reply-To: <SN6PR02MB4157E0525DDDD153888F5AFBD4362@SN6PR02MB4157.namprd02.prod.outlook.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit



On 4/27/2026 11:10 AM, Michael Kelley wrote:
> From: Naman Jain <namjain@linux.microsoft.com> Sent: Thursday, April 23, 2026 5:42 AM
>>
>> The VSM code page offset register (HV_REGISTER_VSM_CODE_PAGE_OFFSETS)
>> is x86 specific, its value configures the static call used to return
>> to VTL0 via the hypercall page. Move the register read from the common
>> mshv_vtl_get_vsm_regs() into the x86 mshv_vtl_return_call_init(),
>> which is the sole consumer of the offset.
>>
>> Change mshv_vtl_return_call_init() from taking a u64 parameter
>> to taking no arguments, and rename mshv_vtl_get_vsm_regs() to
>> mshv_vtl_get_vsm_cap_reg() since it now only fetches
>> HV_REGISTER_VSM_CAPABILITIES.
>>
>> No functional change on x86. This prepares the common driver code for
>> ARM64 where VSM code page offsets do not apply.
>>
>> Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
>> ---
>>   arch/x86/hyperv/hv_vtl.c        | 19 +++++++++++++++++--
>>   arch/x86/include/asm/mshyperv.h |  4 ++--
>>   drivers/hv/mshv_vtl_main.c      | 24 +++++++++++++-----------
>>   3 files changed, 32 insertions(+), 15 deletions(-)
>>
>> diff --git a/arch/x86/hyperv/hv_vtl.c b/arch/x86/hyperv/hv_vtl.c
>> index f3ffb6a7cb2d..7c10b34cf8a4 100644
>> --- a/arch/x86/hyperv/hv_vtl.c
>> +++ b/arch/x86/hyperv/hv_vtl.c
>> @@ -293,10 +293,25 @@ EXPORT_SYMBOL_GPL(hv_vtl_configure_reg_page);
>>
>>   DEFINE_STATIC_CALL_NULL(__mshv_vtl_return_hypercall, void (*)(void));
>>
>> -void mshv_vtl_return_call_init(u64 vtl_return_offset)
>> +int mshv_vtl_return_call_init(void)
>>   {
>> +	struct hv_register_assoc vsm_pg_offset_reg;
>> +	union hv_register_vsm_page_offsets offsets;
>> +	int ret;
>> +
>> +	vsm_pg_offset_reg.name = HV_REGISTER_VSM_CODE_PAGE_OFFSETS;
>> +
>> +	ret = hv_call_get_vp_registers(HV_VP_INDEX_SELF, HV_PARTITION_ID_SELF,
>> +				       1, input_vtl_zero, &vsm_pg_offset_reg);
>> +	if (ret)
>> +		return ret;
>> +
>> +	offsets.as_uint64 = vsm_pg_offset_reg.value.reg64;
>> +
>>   	static_call_update(__mshv_vtl_return_hypercall,
>> -			   (void *)((u8 *)hv_hypercall_pg + vtl_return_offset));
>> +			   (void *)((u8 *)hv_hypercall_pg + offsets.vtl_return_offset));
>> +
>> +	return 0;
>>   }
>>   EXPORT_SYMBOL(mshv_vtl_return_call_init);
>>
>> diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
>> index b4d80c9a673a..b48f115c1292 100644
>> --- a/arch/x86/include/asm/mshyperv.h
>> +++ b/arch/x86/include/asm/mshyperv.h
>> @@ -286,14 +286,14 @@ struct mshv_vtl_cpu_context {
>>   #ifdef CONFIG_HYPERV_VTL_MODE
>>   void __init hv_vtl_init_platform(void);
>>   int __init hv_vtl_early_init(void);
>> -void mshv_vtl_return_call_init(u64 vtl_return_offset);
>> +int mshv_vtl_return_call_init(void);
>>   void mshv_vtl_return_hypercall(void);
>>   void __mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0);
>>   int hv_vtl_get_set_reg(struct hv_register_assoc *regs, bool set, bool shared);
>>   #else
>>   static inline void __init hv_vtl_init_platform(void) {}
>>   static inline int __init hv_vtl_early_init(void) { return 0; }
>> -static inline void mshv_vtl_return_call_init(u64 vtl_return_offset) {}
>> +static inline int mshv_vtl_return_call_init(void) { return 0; }
>>   static inline void mshv_vtl_return_hypercall(void) {}
>>   static inline void __mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0) {}
>>   #endif
>> diff --git a/drivers/hv/mshv_vtl_main.c b/drivers/hv/mshv_vtl_main.c
>> index 4c9ae65ad3e8..be498c9234fd 100644
>> --- a/drivers/hv/mshv_vtl_main.c
>> +++ b/drivers/hv/mshv_vtl_main.c
>> @@ -79,7 +79,6 @@ struct mshv_vtl {
>>   };
>>
>>   static struct mutex mshv_vtl_poll_file_lock;
>> -static union hv_register_vsm_page_offsets mshv_vsm_page_offsets;
>>   static union hv_register_vsm_capabilities mshv_vsm_capabilities;
>>
>>   static DEFINE_PER_CPU(struct mshv_vtl_poll_file, mshv_vtl_poll_file);
>> @@ -203,21 +202,19 @@ static void mshv_vtl_synic_enable_regs(unsigned int cpu)
>>   	/* VTL2 Host VSP SINT is (un)masked when the user mode requests that */
>>   }
>>
>> -static int mshv_vtl_get_vsm_regs(void)
>> +static int mshv_vtl_get_vsm_cap_reg(void)
>>   {
>> -	struct hv_register_assoc registers[2];
>> -	int ret, count = 2;
>> +	struct hv_register_assoc vsm_capability_reg;
>> +	int ret;
>>
>> -	registers[0].name = HV_REGISTER_VSM_CODE_PAGE_OFFSETS;
>> -	registers[1].name = HV_REGISTER_VSM_CAPABILITIES;
>> +	vsm_capability_reg.name = HV_REGISTER_VSM_CAPABILITIES;
>>
>>   	ret = hv_call_get_vp_registers(HV_VP_INDEX_SELF, HV_PARTITION_ID_SELF,
>> -				       count, input_vtl_zero, registers);
>> +				       1, input_vtl_zero, &vsm_capability_reg);
>>   	if (ret)
>>   		return ret;
>>
>> -	mshv_vsm_page_offsets.as_uint64 = registers[0].value.reg64;
>> -	mshv_vsm_capabilities.as_uint64 = registers[1].value.reg64;
>> +	mshv_vsm_capabilities.as_uint64 = vsm_capability_reg.value.reg64;
>>
>>   	return ret;
> 
> Nit: This could be just "return 0".

Acked.

> 
>>   }
>> @@ -1139,13 +1136,18 @@ static int __init mshv_vtl_init(void)
>>   	tasklet_init(&msg_dpc, mshv_vtl_sint_on_msg_dpc, 0);
>>   	init_waitqueue_head(&fd_wait_queue);
>>
>> -	if (mshv_vtl_get_vsm_regs()) {
>> +	if (mshv_vtl_get_vsm_cap_reg()) {
>>   		dev_emerg(dev, "Unable to get VSM capabilities !!\n");
> 
> Why is this failure an emergency message, while the other failures
> here in mshv_vtl_init() are just error messages? When there's lack
> of consistency, I always wonder if there is a reason ..... :-)

It might be because I didn’t pay enough attention to the old code :)
dev_err() should work just fine, I'll change it.


> 
>>   		ret = -ENODEV;
>>   		goto free_dev;
>>   	}
>>
>> -	mshv_vtl_return_call_init(mshv_vsm_page_offsets.vtl_return_offset);
>> +	ret = mshv_vtl_return_call_init();
>> +	if (ret) {
>> +		dev_err(dev, "mshv_vtl_return_call_init failed: %d\n", ret);
>> +		goto free_dev;
>> +	}
>> +
>>   	ret = hv_vtl_setup_synic();
>>   	if (ret)
>>   		goto free_dev;
>> --
>> 2.43.0
>>

Regards,
Naman

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from MW6PR02CU001.outbound.protection.outlook.com (mail-westus2azolkn19012053.outbound.protection.outlook.com [52.103.10.53])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5559537883D;
	Mon,  4 May 2026 16:06:14 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.103.10.53
ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1777910775; cv=fail; b=aV2AZkpYqzs6LvBA/rhmzqHfMvT1tshJJqMsI0c73gwlce+h6h6S1mZLUxUN33y7KnqtO4CHU1dm16GaKKodGY7iMH4SLINOOB78Fr+O2/hJjDfhX5vVr4PaneGkoBLq8eHIwWuQ8/RjYloFivYVToSz/xFTCRwvWi6+LagIByU=
ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1777910775; c=relaxed/simple;
	bh=2lMtkjlHN8ZcxffhICAz30pLEH/WiWvcqYPmcbJ71lw=;
	h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:
	 Content-Type:MIME-Version; b=G2MdQHg2axA1c3VJ6pcWaRXai/gotFhsG5naatrhimeHBvbd+D+B6mKpBQl6ERpzeKmeyOIAfezzhT51oNg643fivo8ZgFEMIFp3YabS3csxR3/Pap9XZa4JFvQUJ6U5MSu1Cd+nPnm8EKAwBzitt2kvtfAeElWQ7REyZ7fk0P0=
ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=outlook.com; spf=pass smtp.mailfrom=outlook.com; dkim=pass (2048-bit key) header.d=outlook.com header.i=@outlook.com header.b=EFSmVmSJ; arc=fail smtp.client-ip=52.103.10.53
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=outlook.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=outlook.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=outlook.com header.i=@outlook.com header.b="EFSmVmSJ"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=GVQdgXzkwyKwN9E9uYrjNXC2obHnp5TAbUb4UroaqngU2GSSDIztouFNfG65XShVMAZneHIeIWn4eJbsiDdaY85Zz6dZKwzenSFttEvdCiIaV1GRnFX3jd6I3dflw6V+8xEzB2Z2a93AXh1AeQ7qxnKWT5zdLMSdPFMqZRIdYM2YTlimHpHf6zYgZrJ8OkvHo+tcgaAeTVzdUImur/GApsMI0RaE0tcqpze+Vr7iWPq8oLIdp4HdxPaEZ8xwsZc+5Xt0SsW6Qaf8qvijwF3OoiydiLwunl5EjJosu21ANgZov1grlQ2WO3lWUN491L2mYDTcpI9WBtpNqiL9kjvOwQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=2lMtkjlHN8ZcxffhICAz30pLEH/WiWvcqYPmcbJ71lw=;
 b=I0HkrWGtuypKliu/77tz/h6UGcZwCJ6G+HMDbwK93tJzkFCnPto1ht2PsdcVuhtwNb+MfJLqRzDwJCR2SPEnEvvRRnocnN1NkRmufpYxfWjL43jMl4k2SNf7rP4tRnhzVAoHmdZ3sv8yi1vkZ14TD+vY03p/m9w1QlTCmAFUlv16V6oBA0ozgHsmeZwXSeu2M3q7p9BUUpFgPH6A5eZbWA8FzsgDjIRWl1/y3Of+oNsinQYNyN0SRa1LE44924rVGu3L60Xe2CzWjJojrLHBnoTOOs6IKexxGB+l6/dMtITeelmNGEvUEvAWUNzTfC0oOTYN+WULi1lyDSUrCeI2Jg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=2lMtkjlHN8ZcxffhICAz30pLEH/WiWvcqYPmcbJ71lw=;
 b=EFSmVmSJO+2R3WakBdLBiAHA+BiOlF5co8ADfMOehFJhXv6QaUrBMtKArG7tO1NBpemVu5Mv18XB2yr/RL42IHuc+axNxhK7u9UUjlCbe/6OUYYQPmAuvLZqBZoWeWiirM+mSp5rrcZXZeceAZt07usaxfnnujmQZYQ6d0yShIcba7eHA8qBedCq2pDuqAqe6GlLOYK4U03xWC79sOYkpwfnnVXIZuURfP37pSeGhzLsPnypULQHRdsrW2/tboKyAe+TrcCnEVr8YFNErhNlKf3P+MjTkIeDcfgfTv0Y7op9cFHmJpKfHgGX5ywFWy7BPQAA86iOY70oHmJKakJrZQ==
Received: from SN6PR02MB4157.namprd02.prod.outlook.com (2603:10b6:805:33::23)
 by DM4PR02MB9167.namprd02.prod.outlook.com (2603:10b6:8:10c::16) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9870.25; Mon, 4 May
 2026 16:06:10 +0000
Received: from SN6PR02MB4157.namprd02.prod.outlook.com
 ([fe80::900:1ccf:2b1e:52b6]) by SN6PR02MB4157.namprd02.prod.outlook.com
 ([fe80::900:1ccf:2b1e:52b6%6]) with mapi id 15.20.9870.023; Mon, 4 May 2026
 16:06:10 +0000
From: Michael Kelley <mhklinux@outlook.com>
To: Naman Jain <namjain@linux.microsoft.com>, Michael Kelley
	<mhklinux@outlook.com>, "K . Y . Srinivasan" <kys@microsoft.com>, Haiyang
 Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, Dexuan Cui
	<decui@microsoft.com>, Long Li <longli@microsoft.com>, Catalin Marinas
	<catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Thomas Gleixner
	<tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov
	<bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>, "x86@kernel.org"
	<x86@kernel.org>, "H . Peter Anvin" <hpa@zytor.com>, Arnd Bergmann
	<arnd@arndb.de>, Paul Walmsley <pjw@kernel.org>, Palmer Dabbelt
	<palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu>, Alexandre Ghiti
	<alex@ghiti.fr>
CC: Marc Zyngier <maz@kernel.org>, Timothy Hayes <timothy.hayes@arm.com>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>, Sascha Bischoff
	<sascha.bischoff@arm.com>, mrigendrachaubey <mrigendra.chaubey@gmail.com>,
	"linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>, "linux-kernel@vger.kernel.org"
	<linux-kernel@vger.kernel.org>, "linux-arch@vger.kernel.org"
	<linux-arch@vger.kernel.org>, "linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>, "vdso@mailbox.org" <vdso@mailbox.org>,
	"ssengar@linux.microsoft.com" <ssengar@linux.microsoft.com>
Subject: RE: [PATCH v2 09/15] Drivers: hv: mshv_vtl: Move
 hv_vtl_configure_reg_page() to x86
Thread-Topic: [PATCH v2 09/15] Drivers: hv: mshv_vtl: Move
 hv_vtl_configure_reg_page() to x86
Thread-Index: AQHc0x7PKig5dZReokG7sAarwbgXxbXyan2QgANsi4CACEKMcA==
Date: Mon, 4 May 2026 16:06:10 +0000
Message-ID:
 <SN6PR02MB4157AD364DE0755DE070D286D4312@SN6PR02MB4157.namprd02.prod.outlook.com>
References: <20260423124206.2410879-1-namjain@linux.microsoft.com>
 <20260423124206.2410879-10-namjain@linux.microsoft.com>
 <SN6PR02MB4157467FDBC0203C67A67042D4362@SN6PR02MB4157.namprd02.prod.outlook.com>
 <567cf73b-6a48-4fc3-b312-9be6d71e2f22@linux.microsoft.com>
In-Reply-To: <567cf73b-6a48-4fc3-b312-9be6d71e2f22@linux.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: SN6PR02MB4157:EE_|DM4PR02MB9167:EE_
x-ms-office365-filtering-correlation-id: 30ef6419-9c5d-4074-e8c9-08dea9f70ef7
x-microsoft-antispam:
 BCL:0;ARA:14566002|15080799012|37011999003|41001999006|8060799015|19110799012|8062599012|461199028|13091999003|51005399006|16051099003|55001999006|19101099003|31061999003|10035399007|440099028|3412199025|4302099013|102099032|1602099012|40105399003|1710799026;
x-microsoft-antispam-message-info:
 =?utf-8?B?OUl0cFAzQVo4Mk4xLzl4WTFiWmZtWHpCeU5xRG5yZVExVVd6WEVURW9DVkd6?=
 =?utf-8?B?MGE4L2hEd2Q3Y2pLUVY1TVUwS0hEM2xucnBMYzA5T1kxNzVpQ0ZsQkFCVDd1?=
 =?utf-8?B?ZGQwYWtuZ3dya0g2ZWxBdEhYcUJqNisrLzhjUWZ4TjJPVTRndXFYaEZLelRr?=
 =?utf-8?B?VWxZVTNzWjVFOXB0bHVWN0lhNWJvcGFIQVhtTExvbENiTmt4WlhqY2M4YVo2?=
 =?utf-8?B?ZkFHZUdZdXNaM1o4MDFXN2ZvSjdNM0VKSHc0aG55VnpjQXlFS1orSXFnYUZN?=
 =?utf-8?B?SWpXclpIUVNxWUE0bFAwbCtTaXJXNXFYOGtsUWsrNGlKRXVZU2RkNjBraUdW?=
 =?utf-8?B?ZHYyeEpCcHRuMlJBbXNFZXhLL081SUJkYjN4OTZaMWNkZmRCMFUrc0RzU3hs?=
 =?utf-8?B?SXh6Q0VaNDJQL1g4TlQvRUFMTUZYeGJqSGJ0WWRGTmF5ZU5kUHo0OXJCOHpt?=
 =?utf-8?B?aVBpaUVlbUtpREMycHRHWTNSbURPcHFXdm5UaGx0eEZSeHNkNlgwZHhQRDhm?=
 =?utf-8?B?cWRwZlpteTZVY2FwRDdNZlRtMDAya2tvOExjS2lUNGhyRnhpalRqZGRCb2NG?=
 =?utf-8?B?ZlpxYnJWbWQ5aVRqTHJzMEZ3MUhzODFrT3NlWTBKUFlwMG9nd2FFdjhldXQz?=
 =?utf-8?B?bXd6VHhVckljeUtoSkZwZTJ2anFPV0NMbkNsRSs2Ky9ENWZ5U0xQSFpTQ1VH?=
 =?utf-8?B?L00reTZTd1UzMnFYOVFKK2YyMitNcFh0MGVmeERqNWpNbUFpc2pjZVpUL25x?=
 =?utf-8?B?SG1ZMzNXdk9qblZ1YWZsYlRLSnFyKy9WRC8vVUhHaWU0RXltb3Z4ODhEcGhY?=
 =?utf-8?B?RFpQRTdzSUNETjc2ektlR2pBRVY5UmlSS1AvUTN3VzFjbFFYd3JKUTVRTmEz?=
 =?utf-8?B?REppSFpWNmY5dEZ6NzlUSThYb09CVWR5eUl5OWtjUXgzeVlKdDBEV241QWNE?=
 =?utf-8?B?dDBkUmZ4OW9Nd091NGsxVVFWQk5TQzN2eXM3T1pKa2xsQ0dZdWUxRTBRcFVW?=
 =?utf-8?B?RHJOV3lwZTlXTlpwUHJsVm9udTErOWZBREgwVW1hQXUwUXVDYjFobm1WN2dT?=
 =?utf-8?B?Mk9VOGlpeFIvaUVxUHZnNjA1eWpHWVFJci95UVltL2FXZkgrRGxLTUNOVVFD?=
 =?utf-8?B?M0F0YkM3V1VFU1cvY0lIVHlVRVdnd2h6dS8zMnovd0xFWCt1d0hrS3ZvcG1E?=
 =?utf-8?B?VSt2YU5YZzhSUTdNNXlrNU01YXc3U1lwaUxDTmNXUzdHZzdoMktQbEpQbnhz?=
 =?utf-8?B?aHRkdSt2SzloYTBWYnJraWxxc0RvWW43YWJyVjM4QmVYOW1ZVldnUHRvVEZW?=
 =?utf-8?B?RXM4UVkxc0t1aFVmS3JtQmRJZnJMcUR6OXYzakNJYmlLd0lPelQ4WVdaRkYx?=
 =?utf-8?B?WFFQWDNEWlN1VksyNlhPY0NnUUdyM2prSFNnWGFpSzRMK0lBdlJIdnpkZ2N5?=
 =?utf-8?B?YTh4aTZpSnFSSG9QM2xQYjRrWXF0WlY5c1NBd0hmUFhYYm9mTnpza21ieXJz?=
 =?utf-8?B?NlMvcWFIZktFR1F0bm5hSSthaUJicml3OEduTDgrd2JLYmc0U1JFaFhMUE9N?=
 =?utf-8?B?V0NCQkh2RTRyMXBFcXpYZTZUelAxN0xFS3RvWnpiZE1kYVZvQVVPQkJOY1BZ?=
 =?utf-8?Q?BwN0AF4d6Av+y5axTLkELWzuRRvh8egvk2bmDI3mJe5M=3D?=
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?OGQ4Z3BnNnlLdVluWkhIQ0xpRnZqd29JSHZTL3EvNmwvL1hjL3p3SzR6SWRu?=
 =?utf-8?B?Rk9FR0NWK0s2WDBHVmIzN0hVVWhicmZqS2s4L0l1dFhKcWxtNjZUNkdrNEd6?=
 =?utf-8?B?YzRVTWVJNWhQYitJOHYyQjFoeko4YklEUzJnZHVZQlVCblVXMjVvTWJpK1RW?=
 =?utf-8?B?WVc1QjlvUjBFVXU5NEJrOUllNEZvd1A5bkRxU1dtcXI3cUFna3V3MVhoaExN?=
 =?utf-8?B?OE1qeXFnQmpJeWxpTm9BUVRSNWJtS0NMUmlHZ0hZMmx1UC8vMjUwdjFsUjNY?=
 =?utf-8?B?OHFMaWRqWUtaK0JDVFRqR0p0R1lvd2ZhTjgzNEVGanl3YlYxMjFKK05mRFNS?=
 =?utf-8?B?YW82QUd1R1VhVi9ydFhRQkZFZlZ0MVJHNjVKcXd6WUV4Z2FpdE4yQkpwc1Yr?=
 =?utf-8?B?VTFZY2VFQnhmeUZXc05FMnE1QUZzblN4cndWaW9GNHB4d1lENkk4Ky96M0t5?=
 =?utf-8?B?NE40VFc0NWdnRnp3YnJBRCtmaER6RHQ0K1NlZWRXZlR5R3l6R1dtVE8zbWU4?=
 =?utf-8?B?S2xKTFYyK0RQcmh6YU54RFg2ejBOc0t1ZHQ1VC9oNHg4dXpUZEsra0ZYYzlk?=
 =?utf-8?B?dzVkbWhXMWhkRW9DWnRmdXkycUdEc1h6elRTWDdVaHFSZ25rQ0tGSWYwMktX?=
 =?utf-8?B?QVhaTjkyQ0JVaDB6R0d6bXdFU0Q1VzlJMXJyWHFKSTNtc0FwcXNpVXpLSVFz?=
 =?utf-8?B?VE1YTitQUHZiTDlMWkJxbmNoc2FJWUtwU3ZSa3JQb0QyTHArV2wzVzNqY3ZK?=
 =?utf-8?B?aXlndllwU2xXZEVFN05hY0h2ekEyQlpVNmJmMXA0aE94c2YxMUZwK1g2cUVL?=
 =?utf-8?B?TkdzU0g1Y3RRQ1FNRHZoTFl6UFgvL1VwM091MWxPNHFjMkZGMEEzYVVkZ09C?=
 =?utf-8?B?NXMrZm01RDJIV1U0ZkdZemdjWGFHOUlwdWpTK3ZybnorQ2dzSThqTnJXK2Ji?=
 =?utf-8?B?YmNVMVlKUHArRERhSE1oRjBXaXQrbmFSM0FBNXJJWWRlb0l0NWNmdWplTlov?=
 =?utf-8?B?dUhvR0NPV3ovUHBPeDMvWUFLQ0pwRS9wZHJhSjhnQmRncVpza2k4YU1OQisz?=
 =?utf-8?B?VVRteWxmanNCU3NaZkFyWXJ6OTYyMWdwK0Jtb0dGQ0ZoeFA4MlVOQmV5R2VV?=
 =?utf-8?B?dVJIQ09wcTVSUUtoSDM4ZkZOd3V0RXFkYTlJUUNXODAwYkFPNXpLNWtnaWVD?=
 =?utf-8?B?bU1qSmc4ZXlZT2dSZkhjWERiWHFMRy9XTDd4SW1xUW5MWk1NM1NyNEFDQ3BK?=
 =?utf-8?B?eWc3TWlsYTI0cFdmcUhrMlh1L2RRbjAyNmxYdVVxd2FsWjY5YytyZzgzTyts?=
 =?utf-8?B?SkJZbUMwN24yNExwbm5mY2VsU1dpUUluemUzTVB0eHl5OGI0V3FuMXl0QUV6?=
 =?utf-8?B?Szh4SXFGNVlaSHBMMkl5WXhESXJZVWpZWUdXSktEdVRlZU1NdnpMU3U0a29p?=
 =?utf-8?B?T0lHSVdZVzdROEtCbnRjek9WL0trOEJ5eDNBdStTNndoYzRiMURUMUdhZ1dW?=
 =?utf-8?B?TVdMN3ErZGExL2luRGJFaUsrMWR3Nk12b0ZVT01CTnJ6WWlyWnNpS0VpKzl2?=
 =?utf-8?B?YS9OWTl0U3FET01UaWJuTHhJbmkrYWw4ZEg4YU1uUEVKaExxSXZIRGs2MnFW?=
 =?utf-8?B?dlhXN0JoaEhzUmh3Nk1uMWRyWFB5d1J0Z3FGNmZib0UreE9FQzJwK20wN2J0?=
 =?utf-8?B?T2c5UVVuL0Q5bTFEVXE5RGN0UDNGb2ZEZkFwK2VPWEJNWkVUOVYwUWJGWmxj?=
 =?utf-8?B?dVl6MEt4R2xzSjJRR0JJSHN3WloxRm5DVHZlY1ppdXVCQU5KMDRsNDd1NnJx?=
 =?utf-8?Q?XeOHr/T0Q4N4pGkRXzQdScJvAdMoGxFtt8qus=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Precedence: bulk
X-Mailing-List: linux-arch@vger.kernel.org
List-Id: <linux-arch.vger.kernel.org>
List-Subscribe: <mailto:linux-arch+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-arch+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SN6PR02MB4157.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 30ef6419-9c5d-4074-e8c9-08dea9f70ef7
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2026 16:06:10.4580
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR02MB9167

RnJvbTogTmFtYW4gSmFpbiA8bmFtamFpbkBsaW51eC5taWNyb3NvZnQuY29tPiBTZW50OiBXZWRu
ZXNkYXksIEFwcmlsIDI5LCAyMDI2IDI6NTggQU0NCj4gDQo+IE9uIDQvMjcvMjAyNiAxMToxMCBB
TSwgTWljaGFlbCBLZWxsZXkgd3JvdGU6DQo+ID4gRnJvbTogTmFtYW4gSmFpbiA8bmFtamFpbkBs
aW51eC5taWNyb3NvZnQuY29tPiBTZW50OiBUaHVyc2RheSwgQXByaWwgMjMsIDIwMjYgNTo0MiBB
TQ0KPiA+Pg0KPiA+PiBNb3ZlIGh2X3Z0bF9jb25maWd1cmVfcmVnX3BhZ2UoKSBmcm9tIGRyaXZl
cnMvaHYvbXNodl92dGxfbWFpbi5jIHRvDQo+ID4+IGFyY2gveDg2L2h5cGVydi9odl92dGwuYy4g
VGhlIHJlZ2lzdGVyIHBhZ2Ugb3ZlcmxheSBpcyBhbiB4ODYtc3BlY2lmaWMNCj4gPj4gZmVhdHVy
ZSB0aGF0IHVzZXMgSFZfWDY0X1JFR0lTVEVSX1JFR19QQUdFLCBzbyBpdHMgY29uZmlndXJhdGlv
biBiZWxvbmdzDQo+ID4+IGluIGFyY2hpdGVjdHVyZS1zcGVjaWZpYyBjb2RlLg0KPiA+Pg0KPiA+
PiBNb3ZlIHN0cnVjdCBtc2h2X3Z0bF9wZXJfY3B1IGFuZCB1bmlvbiBodl9zeW5pY19vdmVybGF5
X3BhZ2VfbXNyIHRvDQo+ID4+IGluY2x1ZGUvYXNtLWdlbmVyaWMvbXNoeXBlcnYuaCBzbyB0aGV5
IGFyZSB2aXNpYmxlIHRvIGJvdGggYXJjaCBhbmQNCj4gPj4gZHJpdmVyIGNvZGUuDQo+ID4+DQo+
ID4+IENoYW5nZSB0aGUgcmV0dXJuIHR5cGUgZnJvbSB2b2lkIHRvIGJvb2wgc28gdGhlIGNhbGxl
ciBjYW4gZGV0ZXJtaW5lDQo+ID4+IHdoZXRoZXIgdGhlIHJlZ2lzdGVyIHBhZ2Ugd2FzIHN1Y2Nl
c3NmdWxseSBjb25maWd1cmVkIGFuZCBzZXQNCj4gPj4gbXNodl9oYXNfcmVnX3BhZ2UgYWNjb3Jk
aW5nbHkuDQo+ID4+DQo+ID4+IFNpZ25lZC1vZmYtYnk6IE5hbWFuIEphaW4gPG5hbWphaW5AbGlu
dXgubWljcm9zb2Z0LmNvbT4NCj4gPj4gLS0tDQo+ID4+ICAgYXJjaC94ODYvaHlwZXJ2L2h2X3Z0
bC5jICAgICAgIHwgMzIgKysrKysrKysrKysrKysrKysrKysrKw0KPiA+PiAgIGRyaXZlcnMvaHYv
bXNodl92dGxfbWFpbi5jICAgICB8IDQ5ICsrKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0NCj4gPj4gICBpbmNsdWRlL2FzbS1nZW5lcmljL21zaHlwZXJ2LmggfCAxNyArKysrKysrKysr
KysNCj4gPj4gICAzIGZpbGVzIGNoYW5nZWQsIDUzIGluc2VydGlvbnMoKyksIDQ1IGRlbGV0aW9u
cygtKQ0KPiA+Pg0KPiANCj4gPHNuaXA+DQo+IA0KPiA+PiAgICNpZiBJU19FTkFCTEVEKENPTkZJ
R19IWVBFUlZfVlRMX01PREUpDQo+ID4+ICsvKiBTWU5JQ19PVkVSTEFZX1BBR0VfTVNSIC0gaW50
ZXJuYWwsIGlkZW50aWNhbCB0byBodl9zeW5pY19zaW1wICovDQo+ID4NCj4gPiBUaGlzIGNvbW1l
bnQgcHJlLWRhdGVzIHlvdXIgcGF0Y2gsIGJ1dCBJIGRvbid0IHVuZGVyc3RhbmQgdGhlIHBvaW50
DQo+ID4gaXQgaXMgdHJ5aW5nIHRvIG1ha2UuIFRoZSBjb21tZW50IGlzIGZhY3R1YWxseSB0cnVl
LCBidXQgSSBkb24ndCBrbm93DQo+ID4gd2h5IGNhbGxpbmcgdGhhdCBvdXQgaXMgcmVsZXZhbnQu
IFRoZSBSRUdfUEFHRSBNU1Igc2VlbXMgdG8gYmUNCj4gPiBjb25jZXB0dWFsbHkgc2VwYXJhdGUg
YW5kIGRpc3RpbmN0IGZyb20gdGhlIFNJTVAgTVNSLCBzbyB0aGUgZmFjdA0KPiA+IHRoYXQgdGhl
IGxheW91dHMgYXJlIHRoZSBzYW1lIGlzIGp1c3QgYSBjb2luY2lkZW5jZS4gT3IgaXMgdGhlcmUg
c29tZQ0KPiA+IHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSB0d28gTVNScyB0aGF0IEknbSBub3Qg
YXdhcmUgb2YsIGFuZCB0aGUNCj4gPiBjb21tZW50IGlzIHRyeWluZyAoYW5kIGZhaWxpbmc/KSB0
byBwb2ludCBvdXQ/DQo+IA0KPiBUaGlzIHdhcyBhZGRlZCBhcyBwZXIgc3VnZ2VzdGlvbiBmcm9t
IE51bm8gaW4gbXkgaW5pdGlhbCBzZXJpZXMgZm9yDQo+IE1TSFZfVlRMLiBJZiB0aGUgcmVmZXJl
bmNlIGluICJpZGVudGljYWwgdG8iIGlzIG1pc2xlYWRpbmcsIEkgc2hvdWxkDQo+IHJlbW92ZSBp
dC4NCj4gDQo+IGh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL2FsbC82ODE0M2ViMC1lNmE3LTQ1Nzkt
YmVkYi00YzJlYzVhYWVmNmJAbGludXgubWljcm9zb2Z0LmNvbS8NCj4gDQo+IFF1b3Rpbmc6DQo+
ICIiIg0KPiBpdCBpcyBhIGdlbmVyaWMgc3RydWN0dXJlIHRoYXQNCj4gYXBwZWFycyB0byBiZSB1
c2VkIGZvciBzZXZlcmFsIG92ZXJsYXkgcGFnZSBNU1JzIChTSU1QLCBTSUVGLCBldGMpLg0KPiAN
Cj4gQnV0LCB0aGUgdHlwZSBkb2Vzbid0IGFwcGVhciBpbiB0aGUgaHYqZGsgaGVhZGVycyBleHBs
aWNpdGx5OyBpdCdzIGp1c3QNCj4gdXNlZCBpbnRlcm5hbGx5IGJ5IHRoZSBoeXBlcnZpc29yLg0K
PiANCj4gSSB0aGluayBpdCBzaG91bGQgYmUgcmVuYW1lZCB3aXRoIGEgaHZfIHByZWZpeCB0byBp
bmRpY2F0ZSBpdCdzIHBhcnQgb2YNCj4gdGhlIGh5cGVydmlzb3IgQUJJLCBhbmQgYSBicmllZiBj
b21tZW50IHdpdGggdGhlIHByb3ZlbmFuY2U6DQo+IA0KPiAvKiBTWU5JQ19PVkVSTEFZX1BBR0Vf
TVNSIC0gaW50ZXJuYWwsIGlkZW50aWNhbCB0byBodl9zeW5pY19zaW1wICovDQo+IHVuaW9uIGh2
X3N5bmljX292ZXJsYXlfcGFnZV9tc3Igew0KPiAJLyogPHNuaXA+ICovDQo+IH07DQoNCk9LLCBz
byB0aGlzIHVuaW9uIGlzIG5vdCBhc3NvY2lhdGVkICpvbmx5KiB3aXRoIHRoZSBSRUdfUEFHRSBN
U1INCih0aG91Z2ggdGhhdCBNU1IgaXMgdGhlIG9ubHkgY3VycmVudCB1c2VyKS4gSW5zdGVhZCwg
aXQgaXMgaW50ZW5kZWQgdG8NCmJlIGEgbW9yZSBnZW5lcmljIGRlc2NyaXB0aW9uIG9mIE1TUnMg
dGhhdCBzZXQgdXAgb3ZlcmxheSBwYWdlcy4gSQ0KZG9uJ3QgdGhpbmsgSSBoYWQgcHJldmlvdXNs
eSBub3RpY2VkIE51bm8ncyBjb21tZW50IG9uIHRoZSB0b3BpYy4NCg0KTG9va2luZyB0aHJvdWdo
IGh2Z2RrX21pbmkuaCBhbmQgaHZoZGsuaCwgSSBzZWUgNiBkZWZpbml0aW9ucyB0aGF0DQphcmUg
ZXhhY3RseSB0aGUgc2FtZToNCg0KKiB1bmlvbiBodl9yZWZlcmVuY2VfdHNjX21zcg0KKiB1bmlv
biBodl94NjRfbXNyX2h5cGVyY2FsbF9jb250ZW50cw0KKiB1bmlvbiBodl92cF9hc3Npc3RfbXNy
X2NvbnRlbnRzDQoqIHVuaW9uIGh2X3N5bmljX3NpbXANCiogdW5pb24gaHZfc3luaWNfc2llZnAN
CiogdW5pb24gaHZfc3luaWNfc2lyYnANCg0KVGhlcmUncyBhbiBhcmd1bWVudCB0byBiZSBtYWRl
IGZvciByZW1vdmluZyB0aGVzZSA2IHVuaXF1ZSBkZWZpbml0aW9ucw0KYW5kIHVzaW5nIHVuaW9u
IGh2X3N5bmljX292ZXJsYXlfcGFnZV9tc3IgaW5zdGVhZCAodGhvdWdoICJzeW5pYyINCndvdWxk
IG5lZWQgdG8gYmUgcmVtb3ZlZCBmcm9tIHRoZSBuYW1lKS4gIEkgd291bGQgbm90IG9iamVjdCB0
byBzdWNoDQphbiBhcHByb2FjaC4gSXQncyBhIHNtYWxsIGV4dHJhIGxheWVyIG9mIGNvbmNlcHR1
YWwgaW5kaXJlY3Rpb24sIGJ1dCBzYXZlcw0Kc29tZSBsaW5lcyBvZiBjb2RlIGZvciBkdXBsaWNh
dGl2ZSBkZWZpbml0aW9ucy4gVGhlIGFsdGVybmF0aXZlIGlzIHRvIGRyb3ANCnRoZSBpZGVhIG9m
IGEgZ2VuZXJpYyBvdmVybGF5IHBhZ2UgTVNSIGxheW91dCwgYW5kIHJlcGxhY2UgdW5pb24NCmh2
X3N5bmljX292ZXJsYXlfcGFnZV9tc3Igd2l0aCBhIGRlZmluaXRpb24gdGhhdCBpcyBzcGVjaWZp
YyB0byB0aGUNClJFR19QQUdFIE1TUiwgbGlrZSB0aGUgb3RoZXIgc2l4IGFib3ZlLiANCg0KSSBj
b3VsZCBnbyBlaXRoZXIgd2F5LiBJZiB3ZSB3YW50IHRvIHVzZSBhIGdlbmVyaWMgb3ZlcmxheSBw
YWdlIGRlZmluaXRpb24sDQp0aGVuIHRoYXQgYXBwcm9hY2ggc2hvdWxkIGJlIGFwcGxpZWQgZXZl
cnl3aGVyZS4gV2l0aCB0aGUgY3VycmVudA0Kc3RhdGUgb2YgeW91ciBwYXRjaCBzZXQsIHdlJ3Jl
IGhhbGZ3YXkgaW4gYmV0d2VlbiAtLSB0aGUgZ2VuZXJpYyBkZWZpbml0aW9uDQppcyB1c2VkIG9u
ZSBwbGFjZSwgYnV0IGR1cGxpY2F0aXZlIHNwZWNpZmljIE1TUiBkZWZpbml0aW9ucyBhcmUgdXNl
ZCBvdGhlcg0KcGxhY2VzLiBUaGF0J3MgcHJvYmFibHkgdGhlIGxlYXN0IGRlc2lyYWJsZSBhcHBy
b2FjaC4NCg0KTWljaGFlbA0K

From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from BN8PR05CU002.outbound.protection.outlook.com (mail-eastus2azolkn19011025.outbound.protection.outlook.com [52.103.12.25])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3A46C8462;
	Mon,  4 May 2026 16:06:25 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.103.12.25
ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1777910786; cv=fail; b=vCpuye1mmNSagRQOs+1BwZmAnnsdo5Z8ulbqQ8c9bDJfnW4gE+dBxOh0mT6RIhOZxfimh7vDuXtMqZgLj8wSFgCS/K1/KxOYSMPpJ9h+f9OmeyVTPNURYOgxjxKd64rE6P4DCs40DmUuIEcoAiBQZMVwqjXfrR52AhusAHgWqbk=
ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1777910786; c=relaxed/simple;
	bh=XW3GD0BjWqdZHY14hpMkeiboBrR6eErhqBbX5IezatA=;
	h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:
	 Content-Type:MIME-Version; b=GiNX3NTdQUjbUejoezyJS/mbCiXCGwdMn5+yuGu5J77sXbyUuK0HJZC6znli5sM1gRi8E5HwK8/HoRR7vNR8A917Lg/k2xtRHZRRupK2hrOuFLh5iJOEJyRVPrR4+7mhmG+QZ5l0XPzsRu/+JgD+ppAmKF3JX9tjpdS4Ma2w8yA=
ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=outlook.com; spf=pass smtp.mailfrom=outlook.com; dkim=pass (2048-bit key) header.d=outlook.com header.i=@outlook.com header.b=rQyQuFLt; arc=fail smtp.client-ip=52.103.12.25
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=outlook.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=outlook.com
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=outlook.com header.i=@outlook.com header.b="rQyQuFLt"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
 b=iD3B5JTACz7ekYPqRn7WHWMMBvKI09SYbtzc900pD2VEjo/QdOaASPqdp3J5Vh3SxyOMGCi9UioNSpdY+OUqBoNDs9Qv/YgU9XZ24SBdNH+xzJ1a7h+FDLnH9bFwIUajVfDJp+MIf7jTHPMcfx6zvAz5ldztfIeQaMWVlaBreOEr0OtWe2j1+/DgJYNS8wpoTXNkALSTQaA7TIrme8P2r9lVgBPTaX87lfl4xrZQEIbEcyyumI1qT7ahg7snMXaXXCwCJgkcokD00anefkrz7W6bU56YZuUslJuhNhxNbeqsK6Gb9DobduUb8T1HpdTAC4qbt7whXDoVT23/5jceAA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector10001;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=XW3GD0BjWqdZHY14hpMkeiboBrR6eErhqBbX5IezatA=;
 b=cKevq7NyOUMbFraeOgOJ+B+ljWiAJnjyDgfl/+BMKm8PWhQHg2oYQC6ZqNV0fgT8sAOcccIy1ULvtomKcXnO4QctCUlPXy4oVfT1VVEZcXxJ0srlYAdsiRN2KDjqXCQA6YNzQQZdMjA8jp3WES/MBo2TBcpTO0MPJE6D8b+/FFxRe4i0wjyoCKpYNQTJ9MxSKhtMuHidcJ0ehh1ZfEpFaTZNCOPL9FQO9G2LOVwvBpctm41Qp3ZtuXR364Zq1JDN7A5q5mD4vC8O3J6+2rOaJJrz1/iEaKQT8t+5K5bCh1AfH6nsav1hUxHhVgE27yGOtiz7COZktNn60kUmpQNHOQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
 dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com;
 s=selector1;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=XW3GD0BjWqdZHY14hpMkeiboBrR6eErhqBbX5IezatA=;
 b=rQyQuFLtmxKzMbOcmAgiE5kQpZY7TqY7g/H+oxzE9YOCCqyE53L+1+8Cj4ipLaeEAEhNFn6kJxmS8XdfQuXsTRDqKx6wG4EIAIjT6gb4GpDXtgKKS7GcC9m4bIYFJTQHF4KFfs4Nf9e9MprkJab9EcI1zz+jkUX4aJxkOKxVYhNYOVIXWpYYi93xPvwaf0qFWqMt3Chu1YaMDjUyp17Rh/x+8KzOAAgne/6jHxkFwZmrONT5fUETl2LbfNvhG137Hg8k77c7GJHPhhwHc+I9iBhl2U8HxTrEG7FT+SbZNOOGWi5i6kZeSpsKy+7sX76wYjgsM76JzUCC0YqJ89dc5A==
Received: from SN6PR02MB4157.namprd02.prod.outlook.com (2603:10b6:805:33::23)
 by DM4PR02MB9167.namprd02.prod.outlook.com (2603:10b6:8:10c::16) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9870.25; Mon, 4 May
 2026 16:06:21 +0000
Received: from SN6PR02MB4157.namprd02.prod.outlook.com
 ([fe80::900:1ccf:2b1e:52b6]) by SN6PR02MB4157.namprd02.prod.outlook.com
 ([fe80::900:1ccf:2b1e:52b6%6]) with mapi id 15.20.9870.023; Mon, 4 May 2026
 16:06:20 +0000
From: Michael Kelley <mhklinux@outlook.com>
To: Naman Jain <namjain@linux.microsoft.com>, Michael Kelley
	<mhklinux@outlook.com>, "K . Y . Srinivasan" <kys@microsoft.com>, Haiyang
 Zhang <haiyangz@microsoft.com>, Wei Liu <wei.liu@kernel.org>, Dexuan Cui
	<decui@microsoft.com>, Long Li <longli@microsoft.com>, Catalin Marinas
	<catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Thomas Gleixner
	<tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov
	<bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>, "x86@kernel.org"
	<x86@kernel.org>, "H . Peter Anvin" <hpa@zytor.com>, Arnd Bergmann
	<arnd@arndb.de>, Paul Walmsley <pjw@kernel.org>, Palmer Dabbelt
	<palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu>, Alexandre Ghiti
	<alex@ghiti.fr>
CC: Marc Zyngier <maz@kernel.org>, Timothy Hayes <timothy.hayes@arm.com>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>, Sascha Bischoff
	<sascha.bischoff@arm.com>, mrigendrachaubey <mrigendra.chaubey@gmail.com>,
	"linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>, "linux-kernel@vger.kernel.org"
	<linux-kernel@vger.kernel.org>, "linux-arch@vger.kernel.org"
	<linux-arch@vger.kernel.org>, "linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>, "vdso@mailbox.org" <vdso@mailbox.org>,
	"ssengar@linux.microsoft.com" <ssengar@linux.microsoft.com>
Subject: RE: [PATCH v2 07/15] arm64: hyperv: Add support for
 mshv_vtl_return_call
Thread-Topic: [PATCH v2 07/15] arm64: hyperv: Add support for
 mshv_vtl_return_call
Thread-Index: AQHc0x7Gd+InXWMHLEisx/6viGrEn7Xyae9QgANsyoCACELsMA==
Date: Mon, 4 May 2026 16:06:20 +0000
Message-ID:
 <SN6PR02MB4157B99838CE7498933B2382D4312@SN6PR02MB4157.namprd02.prod.outlook.com>
References: <20260423124206.2410879-1-namjain@linux.microsoft.com>
 <20260423124206.2410879-8-namjain@linux.microsoft.com>
 <SN6PR02MB4157C147A1B915F9B45D3B74D4362@SN6PR02MB4157.namprd02.prod.outlook.com>
 <516a4e65-3a4d-4e09-b445-28cb740b5653@linux.microsoft.com>
In-Reply-To: <516a4e65-3a4d-4e09-b445-28cb740b5653@linux.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: SN6PR02MB4157:EE_|DM4PR02MB9167:EE_
x-ms-office365-filtering-correlation-id: 71c02e07-c72e-4160-1deb-08dea9f714f2
x-microsoft-antispam:
 BCL:0;ARA:14566002|15080799012|37011999003|41001999006|8060799015|19110799012|8062599012|12121999013|461199028|13091999003|51005399006|16051099003|55001999006|19101099003|31061999003|440099028|3412199025|102099032|13041999003|40105399003|1710799026;
x-microsoft-antispam-message-info:
 =?utf-8?B?MzJDRGNKYi93dXJHdUdoSk5pMUp4cGRvTHJSLzZ1WnRnVEhVOHhwOXcvMkFD?=
 =?utf-8?B?UU9ud2pxMkUyWThhK0kvWnZIUW5RWUF4SVA5eWJZNGNEYVhiQ3pWVzh4bVlP?=
 =?utf-8?B?UEljaTE0T2pqR2J0aEYvUldEenpleHZGVUY0RTBheVNFOG1uUmR1OHJmMGU5?=
 =?utf-8?B?bVQwL0ErZzJNK29lekYzbXFudDBZaFVaMER1bHd0UGFQRC9rM1Nacms4UmZa?=
 =?utf-8?B?SGQxYUJEd1hzQWM3cEwrS2x0SzVmUnVpNnBwK0RYTGgzdFNqcXZITHNGTzhQ?=
 =?utf-8?B?OGljaDlGTTlFbmJYRDYzbUtiaXBYK0FOWUdrVy9SbmIwTjZPem9HaHUxU1Fh?=
 =?utf-8?B?SFZwRlBGdXNPRlI2Z0VQK0k4U2xUSmF4ajZZMi9laXA1OGJhVW0zR3psMVY3?=
 =?utf-8?B?cmVKbzlpUUJKZ0VacTRROU82Z201RldkMFc1eEdZdFhVK0xLOEdmSXdkOGs3?=
 =?utf-8?B?WlAxUzNrU3RVT2xWMmsrT0RpL29zcXVqYkZJOVRUSEsvcnFtVkh2SzY0bWVl?=
 =?utf-8?B?Q3JlRmlKczU2bmJXZG9DbTZOREk1cWpFL0dwVTJMTnQza0oyb1N5TTVEUmE5?=
 =?utf-8?B?OU8waFBHdVljM0IvZmFYOVQ1S3g4ZS8ycGYxc052ZWl5RlY5U3hXZ3pvNUdT?=
 =?utf-8?B?UXBOeloycEZqNFU5elcwL0hjYVVxV3pZQ1FXUDlIMXJ4VzJJS0cyZDl2SzBz?=
 =?utf-8?B?SlROWmlaV2UySmczUll3c3FHVTBnY0RDYmNsa1ZUYXZUK09hekNReWN0b2Ex?=
 =?utf-8?B?K2hJMllBSXdkZk11RUxoK01PTG1JZXNob3ZZNnZ5RnJ3MWFSQTc0QjVNSER2?=
 =?utf-8?B?OHV4SGlCcWhiaUdtSlcyZmw3amlSZmJ4YXFSWTJiUk05VTMrM0xEV3ZISlpI?=
 =?utf-8?B?S0t1NGh4SEphUmx5eDlXcllSR3V3cTBTWnYxWXJncWxnRkhMY1J6RENCaTdu?=
 =?utf-8?B?Y2t6RWFubmV0Yy90aEhNOHVRcTdWQ1JPQXF3YlQvYVpaczRVd3dkcnVEWmZq?=
 =?utf-8?B?YWdqbzNxVWUwRXZ2VlpyVTRjVHdkN25aMHBrdVpDR2hnM3duUmhFQlR5K3hF?=
 =?utf-8?B?Z0EvTS9nMU1kZWZCWXZOSlVCb2lkeko4bURNZmlxcFpvQzVlU1Z2QW5QWTNm?=
 =?utf-8?B?aWtKVjV2VjQzV2I3MFd1VTNsaW5IbFZhWWlYU0lpOU1IalFoT0JyamhVam43?=
 =?utf-8?B?N2lqSXFtbFVRS09qQVRheWM4cEpLb1JhK0puSkgrOE0vc0RXVjgxWTZpK09j?=
 =?utf-8?B?eWRYZG9kdGYyMVR5OWVvOXdvditLZEVVaGhJUlpacGFybkYraXBVTVcyVERt?=
 =?utf-8?B?Q1RwVmhjMjZUTEw4WlFlNXNnVzNWK09NODFxYUtqd2owU1VWblZaU1Y0SUU0?=
 =?utf-8?B?V0t3UlVCSE5FT3pSSW1kYVpCcVo0YW9OMVZJYlJpdS80V0RMcXd2Y1dHZGdH?=
 =?utf-8?B?ZlJKazNBRitvYjBjR0FEMmlkbHdzY3RFWXZ2YlJ5bEhQbnVjV3BQQUJ2a28x?=
 =?utf-8?B?WW8yQ1VzZm5XaWppa0NKSE81OWwwUlN5ZU5iSjg1cGpEYVRYeUNNVU9qaVJy?=
 =?utf-8?Q?/sAtEPbvAFO3eTfN/7eO5avgiyj651weJmuta2/wEJiLRC?=
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-8?B?bHgxWW4xMkgwR1ZQNUVHamR5THVyNkZkYXc5amdRaWhCcU1na3NGbHA1R3hO?=
 =?utf-8?B?TkJFQ3dxQmRWRU0xYVRwRHltdWFmdWxtVUVMV1lpMWlYenNCdGtNU21PUWRZ?=
 =?utf-8?B?Qy85MEs2UFhEVHliRWt4cUtPU1V0NmZxWjlrL2ptQndraHQwY1ZuMTlIY3ZM?=
 =?utf-8?B?WmFJbWV6blpFL2pzSnluNnJqTGVFRThsZkJDZCtJMFBGTE9aTWxjMGVNZExB?=
 =?utf-8?B?dE9Wb1hiREZXckdZTmN5YVZSdG5Bc2dDUUozeENZdWRpcGlsUDlIWG0yMm4z?=
 =?utf-8?B?Z1JZdk9Sc1VEc09VTVdYOVJUNXhWakxSSXN6TzI3VEg5VkU4VDU1SkNmUEJJ?=
 =?utf-8?B?RHNiL0hIdDljQi9PQ0V2ZkREdjRLK0hOa3d1VHhhalNQSDJMMmJPdjg1alU5?=
 =?utf-8?B?dE1HclFRYTFURXBENVpMd05wSUZNRjlCNGxVaEtlZDdBczBuaHZaS2Zaell3?=
 =?utf-8?B?dWtDWHlvWUhUT0UxN2YzZEJGMnJRWjNzc0tuZkpYV3JSWFF4dC9mRUlSSUNH?=
 =?utf-8?B?UkhYN0VBU1ZzcXNTc2c5QXIxY2sybUU4VGlVK3VmNGVONmtKVEYyZkRLMTJ6?=
 =?utf-8?B?V09TS1Y2VnlhMHU4cjB4ZU44SC82NmFZVmRrYi8veUZub1hyeVcvdDhKSmlG?=
 =?utf-8?B?MlRNbnRXQjNiODBkNlFPeit6enhpNGlYa2NuWkVaMnVoK0VVcU5EUUdzUjg4?=
 =?utf-8?B?cFNuZUd3QzNLK29vUFZ1QVkwOXFnSmpMc2RDZDUvUkdEcTllcGEvaHc0WmJo?=
 =?utf-8?B?VXdlS09mTFFGZlpTZUc0R09sdm5FSWVwaXpBR1hhR3krVUVRWFVDZlZrbG1Y?=
 =?utf-8?B?YkpieTBRK1B2U2VSVVpVMzByYnlXOE8vRkh0blRyTURGRjVnYTlMcDNhdlhP?=
 =?utf-8?B?UTdOeEhnWFhGLzdXdGx0V1dXckpNLy9iMnRlVDR3cVVpd0UzZk9vTllqalRS?=
 =?utf-8?B?UDlxRlQybHdxWUQ5QXQ2b2NEWjJuY1lIb3RmVFBORDFnK3FaQ3luZG8vZlJo?=
 =?utf-8?B?aVIyMWxUb1ZwK2ZteW5PREdrbjlJS1FMRWg4RWsyMm5Vdk1lbmNoVFpoQ0Js?=
 =?utf-8?B?OGZHVEVtN09LMzJNbXg2YkZHK25pLysvTytSbEZ5Tk9vaEdYdkJvaVM5RlIy?=
 =?utf-8?B?NVg4MjVMTzJPdG01NTd1VWg4K2laTGJSZ1hicnRyaVJhanhGOCt3czdnUXZs?=
 =?utf-8?B?YnhLMCtXbEpRN09ITnlubFNwaTJNV1B3UFFDK2lNNFR3bk9KbEtjVWZXRUNh?=
 =?utf-8?B?NS9yTFFaVE5NSXpES01jTVJNU2l6VS9hMjg2SlltTlh6a1cxaGI3TzhIdmo3?=
 =?utf-8?B?bHJKM242M050VnMyaTMvUTB5RFBlS0FXc3NRemJVVmF2MERXWHFEYnVHN0tx?=
 =?utf-8?B?NEJ0UUwrWXUwSmVUa3lJOFo5YU1vVTI0RFNkWFZkcVVxVHdsZndpYTdqM3Jj?=
 =?utf-8?B?LzlIMDlSdkZKRlI4V1JGVHhMQXlwTTFDWGM3Y05RZE5tRFRhR01WRUJwaUpF?=
 =?utf-8?B?bWNSK0kxQ1cvelhkVUtHR3k0NzRuZjlHMk5xZG00d3dyRTU2ejFFOE0wbWdQ?=
 =?utf-8?B?c1I1WndsOW9IeXoyZUxTMTBvejEzamxjNndjNldzQ3FjdVo2dllhV21sMXl4?=
 =?utf-8?B?MURCVWFKTG05TnlzcHFCd042U1V0TWtqT2lWMTk4d0JRRWxRekRySWhtMzU4?=
 =?utf-8?B?LzdIU2pyS21iTFUxMGg1TERKSHBjQzFiK2tCc0doRzBDbEEvQnNxVDA2LzVZ?=
 =?utf-8?B?VW9BMzRQZVFVWXFzT084UVZXYitpNm82Zm83ejVTaWJGV25RRUc5ZEVOVllF?=
 =?utf-8?Q?OkwBgjzmTxe6pCCZdF04Fxr/E96u5Fu3D/VKU=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Precedence: bulk
X-Mailing-List: linux-arch@vger.kernel.org
List-Id: <linux-arch.vger.kernel.org>
List-Subscribe: <mailto:linux-arch+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-arch+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SN6PR02MB4157.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 71c02e07-c72e-4160-1deb-08dea9f714f2
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2026 16:06:20.6537
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR02MB9167

RnJvbTogTmFtYW4gSmFpbiA8bmFtamFpbkBsaW51eC5taWNyb3NvZnQuY29tPiBTZW50OiBXZWRu
ZXNkYXksIEFwcmlsIDI5LCAyMDI2IDI6NTcgQU0NCj4gDQo+IE9uIDQvMjcvMjAyNiAxMTowOCBB
TSwgTWljaGFlbCBLZWxsZXkgd3JvdGU6DQo+ID4gRnJvbTogTmFtYW4gSmFpbiA8bmFtamFpbkBs
aW51eC5taWNyb3NvZnQuY29tPiBTZW50OiBUaHVyc2RheSwgQXByaWwgMjMsIDIwMjYgNTo0MiBB
TQ0KPiA+Pg0KDQpbc25pcF0NCg0KPiA+PiBkaWZmIC0tZ2l0IGEvYXJjaC94ODYvaW5jbHVkZS9h
c20vbXNoeXBlcnYuaCBiL2FyY2gveDg2L2luY2x1ZGUvYXNtL21zaHlwZXJ2LmgNCj4gPj4gaW5k
ZXggMDgyNzg1NDdiODRjLi5iNGQ4MGM5YTY3M2EgMTAwNjQ0DQo+ID4+IC0tLSBhL2FyY2gveDg2
L2luY2x1ZGUvYXNtL21zaHlwZXJ2LmgNCj4gPj4gKysrIGIvYXJjaC94ODYvaW5jbHVkZS9hc20v
bXNoeXBlcnYuaA0KPiA+PiBAQCAtMjg2LDcgKzI4Niw2IEBAIHN0cnVjdCBtc2h2X3Z0bF9jcHVf
Y29udGV4dCB7DQo+ID4+ICAgI2lmZGVmIENPTkZJR19IWVBFUlZfVlRMX01PREUNCj4gPj4gICB2
b2lkIF9faW5pdCBodl92dGxfaW5pdF9wbGF0Zm9ybSh2b2lkKTsNCj4gPj4gICBpbnQgX19pbml0
IGh2X3Z0bF9lYXJseV9pbml0KHZvaWQpOw0KPiA+PiAtdm9pZCBtc2h2X3Z0bF9yZXR1cm5fY2Fs
bChzdHJ1Y3QgbXNodl92dGxfY3B1X2NvbnRleHQgKnZ0bDApOw0KPiA+PiAgIHZvaWQgbXNodl92
dGxfcmV0dXJuX2NhbGxfaW5pdCh1NjQgdnRsX3JldHVybl9vZmZzZXQpOw0KPiA+PiAgIHZvaWQg
bXNodl92dGxfcmV0dXJuX2h5cGVyY2FsbCh2b2lkKTsNCj4gPj4gICB2b2lkIF9fbXNodl92dGxf
cmV0dXJuX2NhbGwoc3RydWN0IG1zaHZfdnRsX2NwdV9jb250ZXh0ICp2dGwwKTsNCj4gPj4gQEAg
LTI5NCw3ICsyOTMsNiBAQCBpbnQgaHZfdnRsX2dldF9zZXRfcmVnKHN0cnVjdCBodl9yZWdpc3Rl
cl9hc3NvYyAqcmVncywgYm9vbCBzZXQsIGJvb2wgc2hhcmVkKTsNCj4gPj4gICAjZWxzZQ0KPiA+
PiAgIHN0YXRpYyBpbmxpbmUgdm9pZCBfX2luaXQgaHZfdnRsX2luaXRfcGxhdGZvcm0odm9pZCkg
e30NCj4gPj4gICBzdGF0aWMgaW5saW5lIGludCBfX2luaXQgaHZfdnRsX2Vhcmx5X2luaXQodm9p
ZCkgeyByZXR1cm4gMDsgfQ0KPiA+PiAtc3RhdGljIGlubGluZSB2b2lkIG1zaHZfdnRsX3JldHVy
bl9jYWxsKHN0cnVjdCBtc2h2X3Z0bF9jcHVfY29udGV4dCAqdnRsMCkge30NCj4gPj4gICBzdGF0
aWMgaW5saW5lIHZvaWQgbXNodl92dGxfcmV0dXJuX2NhbGxfaW5pdCh1NjQgdnRsX3JldHVybl9v
ZmZzZXQpIHt9DQo+ID4+ICAgc3RhdGljIGlubGluZSB2b2lkIG1zaHZfdnRsX3JldHVybl9oeXBl
cmNhbGwodm9pZCkge30NCj4gPj4gICBzdGF0aWMgaW5saW5lIHZvaWQgX19tc2h2X3Z0bF9yZXR1
cm5fY2FsbChzdHJ1Y3QgbXNodl92dGxfY3B1X2NvbnRleHQgKnZ0bDApIHt9DQo+ID4+IGRpZmYg
LS1naXQgYS9kcml2ZXJzL2h2L21zaHZfdnRsLmggYi9kcml2ZXJzL2h2L21zaHZfdnRsLmgNCj4g
Pj4gaW5kZXggYTZlZWE1MmY3YWEyLi4xMDNmMDczNzFmM2YgMTAwNjQ0DQo+ID4+IC0tLSBhL2Ry
aXZlcnMvaHYvbXNodl92dGwuaA0KPiA+PiArKysgYi9kcml2ZXJzL2h2L21zaHZfdnRsLmgNCj4g
Pj4gQEAgLTIyLDQgKzIyLDcgQEAgc3RydWN0IG1zaHZfdnRsX3J1biB7DQo+ID4+ICAgCWNoYXIg
dnRsX3JldF9hY3Rpb25zW01TSFZfTUFYX1JVTl9NU0dfU0laRV07DQo+ID4+ICAgfTsNCj4gPj4N
Cj4gPj4gK3N0YXRpY19hc3NlcnQoc2l6ZW9mKHN0cnVjdCBtc2h2X3Z0bF9jcHVfY29udGV4dCkg
PD0gMTAyNCwNCj4gPj4gKwkgICAgICAic3RydWN0IG1zaHZfdnRsX2NwdV9jb250ZXh0IGV4Y2Vl
ZHMgcmVzZXJ2ZWQgc3BhY2UgaW4gc3RydWN0IG1zaHZfdnRsX3J1biIpOw0KPiA+PiArDQo+ID4+
ICAgI2VuZGlmIC8qIF9NU0hWX1ZUTF9IICovDQo+ID4+IGRpZmYgLS1naXQgYS9pbmNsdWRlL2Fz
bS1nZW5lcmljL21zaHlwZXJ2LmggYi9pbmNsdWRlL2FzbS1nZW5lcmljL21zaHlwZXJ2LmgNCj4g
Pj4gaW5kZXggZGIxODNjOGNmYjk1Li44Y2RmMmE5ZmJkZmIgMTAwNjQ0DQo+ID4+IC0tLSBhL2lu
Y2x1ZGUvYXNtLWdlbmVyaWMvbXNoeXBlcnYuaA0KPiA+PiArKysgYi9pbmNsdWRlL2FzbS1nZW5l
cmljL21zaHlwZXJ2LmgNCj4gPj4gQEAgLTM5Niw4ICszOTYsMTAgQEAgc3RhdGljIGlubGluZSBp
bnQgaHZfZGVwb3NpdF9tZW1vcnkodTY0IHBhcnRpdGlvbl9pZCwgdTY0IHN0YXR1cykNCj4gPj4N
Cj4gPj4gICAjaWYgSVNfRU5BQkxFRChDT05GSUdfSFlQRVJWX1ZUTF9NT0RFKQ0KPiA+PiAgIHU4
IF9faW5pdCBnZXRfdnRsKHZvaWQpOw0KPiA+PiArdm9pZCBtc2h2X3Z0bF9yZXR1cm5fY2FsbChz
dHJ1Y3QgbXNodl92dGxfY3B1X2NvbnRleHQgKnZ0bDApOw0KPiA+PiAgICNlbHNlDQo+ID4+ICAg
c3RhdGljIGlubGluZSB1OCBnZXRfdnRsKHZvaWQpIHsgcmV0dXJuIDA7IH0NCj4gPj4gK3N0YXRp
YyBpbmxpbmUgdm9pZCBtc2h2X3Z0bF9yZXR1cm5fY2FsbChzdHJ1Y3QgbXNodl92dGxfY3B1X2Nv
bnRleHQgKnZ0bDApIHt9DQo+ID4NCj4gPiBJcyB0aGlzIHN0dWIgbmVlZGVkPyBNYXliZSBJIG1p
c3NlZCBzb21ldGhpbmcsIGJ1dCBpdCBsb29rcyB0byBtZSBsaWtlIG5vbmUNCj4gPiBvZiB0aGUg
Y29kZSB0aGF0IGNhbGxzIHRoaXMgZ2V0cyBidWlsdCB1bmxlc3MgQ09ORklHX0hZUEVSVl9WVExf
TU9ERSBpcyBzZXQuDQo+ID4gU2VlIGZ1cnRoZXIgY29tbWVudHMgYWJvdXQgc3R1YnMgaW4gUGF0
Y2ggOCBvZiB0aGlzIHNlcmllcy4NCj4gPg0KPiANCj4gQ29uZmlnIGRlcGVuZGVuY2llcyB3b3Vs
ZCBoYW5kbGUgc3VjaCBjYXNlcywgYW5kIHRoaXMgaXMgbm90IHJlcXVpcmVkLiBJDQo+IHNhdyBz
aW1pbGFyIHN0dWJzIGFkZGVkIGluIHRoZSBjb2RlLCBzbyBJIHRob3VnaHQgdGhpcyBpcyBhIG5v
cm0gdGhhdA0KPiBzaG91bGQgYmUgZm9sbG93ZWQsIGFuZCBub3QgcmVseSBvbiBjb25maWcgZGVw
ZW5kZW5jaWVzLg0KPiBJIGNhbiByZW1vdmUgaXQuDQo+IA0KDQpPdGhlcnMgbWlnaHQgZGlzYWdy
ZWUgd2l0aCBtZSwgYnV0IEkgZG9uJ3QgdGhpbmsgaXQncyB0aGUgbm9ybSB0byBhZGQNCnN0dWJz
IHdoZW4gdGhleSBhcmVuJ3QgdHJ1bHkgbmVlZGVkLiBBcyB5b3UgY2FuIHNlZSBmcm9tIHNvbWUg
b2YgbXkNCm90aGVyIGNvbW1lbnRzLCBJIGxvb2sgZm9yIHdheXMgdG8gZWxpbWluYXRlIHN0dWJz
LiBTdHVicyBhcmUgaW5kaWNhdGl2ZQ0Kb2YgYSBib3VuZGFyeSBiZXR3ZWVuIHNlcGFyYXRlbHkg
YnVpbHQgY29tcG9uZW50cywgYW5kIEkgZ2VuZXJhbGx5DQp0cnkgdG8gbWluaW1pemUgdGhlIHN1
cmZhY2UgYXJlYSBvZiBzdWNoIGJvdW5kYXJpZXMuIEEgbGFyZ2Ugc3VyZmFjZSBhcmVhDQpvZnRl
biBtZWFucyB0aGF0IHRoZSBvdmVyYWxsIGRlc2lnbiBjb3VsZCBiZSBpbXByb3ZlZCBieSByZS10
aGlua2luZw0Kd2hpY2ggY29kZSBnb2VzIHdpdGggd2hpY2ggY29tcG9uZW50Lg0KDQpNaWNoYWVs
DQo=

