linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Roman Kisel <romank@linux.microsoft.com>
To: alok.a.tiwari@oracle.com, arnd@arndb.de, bp@alien8.de,
	corbet@lwn.net, dave.hansen@linux.intel.com, decui@microsoft.com,
	haiyangz@microsoft.com, hpa@zytor.com, kys@microsoft.com,
	mhklinux@outlook.com, mingo@redhat.com, rdunlap@infradead.org,
	tglx@linutronix.de, Tianyu.Lan@microsoft.com, wei.liu@kernel.org,
	linux-arch@vger.kernel.org, linux-coco@lists.linux.dev,
	linux-doc@vger.kernel.org, linux-hyperv@vger.kernel.org,
	linux-kernel@vger.kernel.org, x86@kernel.org
Cc: apais@microsoft.com, benhill@microsoft.com,
	bperkins@microsoft.com, sunilmut@microsoft.com
Subject: [PATCH hyperv-next v4 03/16] arch: hyperv: Get/set SynIC synth.registers via paravisor
Date: Mon, 14 Jul 2025 15:15:32 -0700	[thread overview]
Message-ID: <20250714221545.5615-4-romank@linux.microsoft.com> (raw)
In-Reply-To: <20250714221545.5615-1-romank@linux.microsoft.com>

The existing Hyper-V wrappers for getting and setting MSRs are
hv_get/set_msr(). Via hv_get/set_non_nested_msr(), they detect
when running in a CoCo VM with a paravisor, and use the TDX or
SNP guest-host communication protocol to bypass the paravisor
and go directly to the host hypervisor for SynIC MSRs. The "set"
function also implements the required special handling for the
SINT MSRs.

But in some Confidential VMBus cases, the guest wants to talk only
with the paravisor. To accomplish this, provide new functions for
accessing SynICs that always do direct accesses (i.e., not via
TDX or SNP GHCB), which will go to the paravisor. The mirroring
of the existing "set" function is also not needed. These functions
should be used only in the specific Confidential VMBus cases that
require them.

Provide functions that allow manipulating the SynIC registers
through the paravisor.

Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
Reviewed-by: Alok Tiwari <alok.a.tiwari@oracle.com>
---
 arch/x86/kernel/cpu/mshyperv.c | 39 ++++++++++++++++++
 drivers/hv/hv_common.c         | 13 ++++++
 include/asm-generic/mshyperv.h | 75 ++++++++++++++++++----------------
 3 files changed, 92 insertions(+), 35 deletions(-)

diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index c78f860419d6..07c60231d0d8 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -90,6 +90,45 @@ void hv_set_non_nested_msr(unsigned int reg, u64 value)
 }
 EXPORT_SYMBOL_GPL(hv_set_non_nested_msr);
 
+/*
+ * Attempt to get the SynIC register value from the paravisor.
+ *
+ * Not all paravisors support reading SynIC registers, so this function
+ * may fail. The register for the SynIC of the running CPU is accessed.
+ *
+ * Writes the SynIC register value into the memory pointed by val,
+ * and ~0ULL is on failure.
+ *
+ * Returns -ENODEV if the MSR is not a SynIC register, or another error
+ * code if getting the MSR fails (meaning the paravisor doesn't support
+ * relaying VMBus communucations).
+ */
+int hv_para_get_synic_register(unsigned int reg, u64 *val)
+{
+	if (!hv_is_synic_msr(reg))
+		return -ENODEV;
+	return native_read_msr_safe(reg, val);
+}
+
+/*
+ * Attempt to set the SynIC register value with the paravisor.
+ *
+ * Not all paravisors support setting SynIC registers, so this function
+ * may fail. The register for the SynIC of the running CPU is accessed.
+ *
+ * Sets the register to the value supplied.
+ *
+ * Returns: -ENODEV if the MSR is not a SynIC register, or another error
+ * code if writing to the MSR fails (meaning the paravisor doesn't support
+ * relaying VMBus communucations).
+ */
+int hv_para_set_synic_register(unsigned int reg, u64 val)
+{
+	if (!hv_is_synic_msr(reg))
+		return -ENODEV;
+	return native_write_msr_safe(reg, val);
+}
+
 u64 hv_get_msr(unsigned int reg)
 {
 	if (hv_nested)
diff --git a/drivers/hv/hv_common.c b/drivers/hv/hv_common.c
index 49898d10faff..a179ea482cb1 100644
--- a/drivers/hv/hv_common.c
+++ b/drivers/hv/hv_common.c
@@ -716,6 +716,19 @@ u64 __weak hv_tdx_hypercall(u64 control, u64 param1, u64 param2)
 }
 EXPORT_SYMBOL_GPL(hv_tdx_hypercall);
 
+int __weak hv_para_get_synic_register(unsigned int reg, u64 *val)
+{
+	*val = ~0ULL;
+	return -ENODEV;
+}
+EXPORT_SYMBOL_GPL(hv_para_get_synic_register);
+
+int __weak hv_para_set_synic_register(unsigned int reg, u64 val)
+{
+	return -ENODEV;
+}
+EXPORT_SYMBOL_GPL(hv_para_set_synic_register);
+
 void hv_identify_partition_type(void)
 {
 	/* Assume guest role */
diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyperv.h
index 9722934a8332..9447558f425b 100644
--- a/include/asm-generic/mshyperv.h
+++ b/include/asm-generic/mshyperv.h
@@ -162,41 +162,6 @@ static inline u64 hv_generate_guest_id(u64 kernel_version)
 	return guest_id;
 }
 
-/* Free the message slot and signal end-of-message if required */
-static inline void vmbus_signal_eom(struct hv_message *msg, u32 old_msg_type)
-{
-	/*
-	 * On crash we're reading some other CPU's message page and we need
-	 * to be careful: this other CPU may already had cleared the header
-	 * and the host may already had delivered some other message there.
-	 * In case we blindly write msg->header.message_type we're going
-	 * to lose it. We can still lose a message of the same type but
-	 * we count on the fact that there can only be one
-	 * CHANNELMSG_UNLOAD_RESPONSE and we don't care about other messages
-	 * on crash.
-	 */
-	if (cmpxchg(&msg->header.message_type, old_msg_type,
-		    HVMSG_NONE) != old_msg_type)
-		return;
-
-	/*
-	 * The cmxchg() above does an implicit memory barrier to
-	 * ensure the write to MessageType (ie set to
-	 * HVMSG_NONE) happens before we read the
-	 * MessagePending and EOMing. Otherwise, the EOMing
-	 * will not deliver any more messages since there is
-	 * no empty slot
-	 */
-	if (msg->header.message_flags.msg_pending) {
-		/*
-		 * This will cause message queue rescan to
-		 * possibly deliver another msg from the
-		 * hypervisor
-		 */
-		hv_set_msr(HV_MSR_EOM, 0);
-	}
-}
-
 int hv_get_hypervisor_version(union hv_hypervisor_version_info *info);
 
 void hv_setup_vmbus_handler(void (*handler)(void));
@@ -333,6 +298,8 @@ bool hv_is_isolation_supported(void);
 bool hv_isolation_type_snp(void);
 u64 hv_ghcb_hypercall(u64 control, void *input, void *output, u32 input_size);
 u64 hv_tdx_hypercall(u64 control, u64 param1, u64 param2);
+int hv_para_get_synic_register(unsigned int reg, u64 *val);
+int hv_para_set_synic_register(unsigned int reg, u64 val);
 void hyperv_cleanup(void);
 bool hv_query_ext_cap(u64 cap_query);
 void hv_setup_dma_ops(struct device *dev, bool coherent);
@@ -375,6 +342,44 @@ static inline int hv_call_create_vp(int node, u64 partition_id, u32 vp_index, u3
 #endif /* CONFIG_MSHV_ROOT */
 bool vmbus_is_confidential(void);
 
+/* Free the message slot and signal end-of-message if required */
+static inline void vmbus_signal_eom(struct hv_message *msg, u32 old_msg_type)
+{
+	/*
+	 * On crash we're reading some other CPU's message page and we need
+	 * to be careful: this other CPU may already had cleared the header
+	 * and the host may already had delivered some other message there.
+	 * In case we blindly write msg->header.message_type we're going
+	 * to lose it. We can still lose a message of the same type but
+	 * we count on the fact that there can only be one
+	 * CHANNELMSG_UNLOAD_RESPONSE and we don't care about other messages
+	 * on crash.
+	 */
+	if (cmpxchg(&msg->header.message_type, old_msg_type,
+		    HVMSG_NONE) != old_msg_type)
+		return;
+
+	/*
+	 * The cmxchg() above does an implicit memory barrier to
+	 * ensure the write to MessageType (ie set to
+	 * HVMSG_NONE) happens before we read the
+	 * MessagePending and EOMing. Otherwise, the EOMing
+	 * will not deliver any more messages since there is
+	 * no empty slot
+	 */
+	if (msg->header.message_flags.msg_pending) {
+		/*
+		 * This will cause message queue rescan to
+		 * possibly deliver another msg from the
+		 * hypervisor
+		 */
+		if (vmbus_is_confidential())
+			hv_para_set_synic_register(HV_MSR_EOM, 0);
+		else
+			hv_set_msr(HV_MSR_EOM, 0);
+	}
+}
+
 #if IS_ENABLED(CONFIG_HYPERV_VTL_MODE)
 u8 __init get_vtl(void);
 #else
-- 
2.43.0


  parent reply	other threads:[~2025-07-14 22:15 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-14 22:15 [PATCH hyperv-next v4 00/16] Confidential VMBus Roman Kisel
2025-07-14 22:15 ` [PATCH hyperv-next v4 01/16] Documentation: hyperv: " Roman Kisel
2025-07-22 17:43   ` Michael Kelley
2025-07-14 22:15 ` [PATCH hyperv-next v4 02/16] drivers: hv: VMBus protocol version 6.0 Roman Kisel
2025-07-22 17:43   ` Michael Kelley
2025-07-14 22:15 ` Roman Kisel [this message]
2025-07-15 12:46   ` [PATCH hyperv-next v4 03/16] arch: hyperv: Get/set SynIC synth.registers via paravisor kernel test robot
2025-07-22 17:43   ` Michael Kelley
2025-07-14 22:15 ` [PATCH hyperv-next v4 04/16] arch/x86: mshyperv: Trap on access for some synthetic MSRs Roman Kisel
2025-07-15 17:58   ` kernel test robot
2025-07-22 17:43   ` Michael Kelley
2025-07-25  8:04   ` Tianyu Lan
2025-07-14 22:15 ` [PATCH hyperv-next v4 05/16] Drivers: hv: Rename fields for SynIC message and event pages Roman Kisel
2025-07-15 21:46   ` kernel test robot
2025-07-22 17:44   ` Michael Kelley
2025-07-25  8:18   ` Tianyu Lan
2025-07-14 22:15 ` [PATCH hyperv-next v4 06/16] Drivers: hv: Allocate the paravisor SynIC pages when required Roman Kisel
2025-07-22 17:44   ` Michael Kelley
2025-07-25  8:23   ` Tianyu Lan
2025-07-14 22:15 ` [PATCH hyperv-next v4 07/16] Drivers: hv: Post messages through the confidential VMBus if available Roman Kisel
2025-07-22 17:44   ` Michael Kelley
2025-07-25 11:07   ` Tianyu Lan
2025-07-14 22:15 ` [PATCH hyperv-next v4 08/16] Drivers: hv: remove stale comment Roman Kisel
2025-07-22 17:44   ` Michael Kelley
2025-07-25 11:08   ` Tianyu Lan
2025-07-14 22:15 ` [PATCH hyperv-next v4 09/16] Drivers: hv: Check message and event pages for non-NULL before iounmap() Roman Kisel
2025-07-22 17:44   ` Michael Kelley
2025-07-25 11:14   ` Tianyu Lan
2025-07-14 22:15 ` [PATCH hyperv-next v4 10/16] Drivers: hv: Rename the SynIC enable and disable routines Roman Kisel
2025-07-22 17:44   ` Michael Kelley
2025-07-25 11:21   ` Tianyu Lan
2025-07-14 22:15 ` [PATCH hyperv-next v4 11/16] Drivers: hv: Functions for setting up and tearing down the paravisor SynIC Roman Kisel
2025-07-22 17:44   ` Michael Kelley
2025-07-14 22:15 ` [PATCH hyperv-next v4 12/16] Drivers: hv: Allocate encrypted buffers when requested Roman Kisel
2025-07-22 17:44   ` Michael Kelley
2025-07-25 14:40   ` Tianyu Lan
2025-07-14 22:15 ` [PATCH hyperv-next v4 13/16] Drivers: hv: Free msginfo when the buffer fails to decrypt Roman Kisel
2025-07-22 17:45   ` Michael Kelley
2025-07-14 22:15 ` [PATCH hyperv-next v4 14/16] Drivers: hv: Support confidential VMBus channels Roman Kisel
2025-07-22 17:45   ` Michael Kelley
2025-07-14 22:15 ` [PATCH hyperv-next v4 15/16] Drivers: hv: Support establishing the confidential VMBus connection Roman Kisel
2025-07-22 17:45   ` Michael Kelley
2025-08-19 20:26   ` dan.j.williams
2025-08-25 22:41     ` Roman Kisel
2025-07-14 22:15 ` [PATCH hyperv-next v4 16/16] Drivers: hv: Set the default VMBus version to 6.0 Roman Kisel
2025-07-22 17:45   ` Michael Kelley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250714221545.5615-4-romank@linux.microsoft.com \
    --to=romank@linux.microsoft.com \
    --cc=Tianyu.Lan@microsoft.com \
    --cc=alok.a.tiwari@oracle.com \
    --cc=apais@microsoft.com \
    --cc=arnd@arndb.de \
    --cc=benhill@microsoft.com \
    --cc=bp@alien8.de \
    --cc=bperkins@microsoft.com \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=decui@microsoft.com \
    --cc=haiyangz@microsoft.com \
    --cc=hpa@zytor.com \
    --cc=kys@microsoft.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhklinux@outlook.com \
    --cc=mingo@redhat.com \
    --cc=rdunlap@infradead.org \
    --cc=sunilmut@microsoft.com \
    --cc=tglx@linutronix.de \
    --cc=wei.liu@kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).