From: Thara Gopinath <tgopinath@linux.microsoft.com>
To: kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org,
decui@microsoft.com, tglx@kernel.org, mingo@redhat.com,
bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com,
ardb@kernel.org, ilias.apalodimas@linaro.org
Cc: James.Bottomley@HansenPartnership.com,
"longli@microsoft.com--cc=tzimmermann"@suse.de,
javierm@redhat.com, lszubowi@redhat.com,
francescopompo2@gmail.com, tgopinath@microsoft.com,
x86@kernel.org, linux-hyperv@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org,
Thara Gopinath <tgopinath@linux.microsoft.com>
Subject: [RFC PATCH 11/12] drivers: hv: hv_vsm_boot: Boot primary processor in VTL1
Date: Tue, 1 Sep 2026 09:55:25 -0700 [thread overview]
Message-ID: <20260901165647.3160413-12-tgopinath@linux.microsoft.com> (raw)
In-Reply-To: <20260901165647.3160413-1-tgopinath@linux.microsoft.com>
With partition-level VTL1 enabled, the secure kernel image loaded,
its initial vCPU context built, and VTL1 enabled on the boot CPU,
the final step of the primary-CPU bring-up is to actually transition
into VTL1 and start executing the secure kernel. Hyper-V restores
the CPU state from the vp_context supplied during VTL1 enablement
when the first vtlcall is issued.
Issue that first vtlcall on the primary CPU, passing the number of
possible CPUs and the location of the secure kernel reserved region
as the VTL1 boot handshake.
Signed-off-by: Thara Gopinath <tgopinath@linux.microsoft.com>
---
drivers/hv/hv_vsm_boot.c | 63 +++++++++++++++++++++++++++++++++++++++-
1 file changed, 62 insertions(+), 1 deletion(-)
diff --git a/drivers/hv/hv_vsm_boot.c b/drivers/hv/hv_vsm_boot.c
index abe82e03e1897..c4f15c42df1f6 100644
--- a/drivers/hv/hv_vsm_boot.c
+++ b/drivers/hv/hv_vsm_boot.c
@@ -35,6 +35,15 @@
static void *vsm_skm_va;
+/*
+ * By default, when a processor boots in VTL1, we assume that MBEC (Mode-Based Execution Control)
+ * support is also enabled. MBEC distinguishes between user and kernel memory execution permissions.
+ * After the processor boots in VTL1, we verify whether MBEC is actually enabled. If it is not,
+ * we set a global flag to false. This flag is shared across all processors—if any processor fails
+ * to enable MBEC, the system treats MBEC as disabled.
+ */
+static bool hv_vsm_mbec_enabled = true;
+
static int hv_vsm_get_register(u32 reg_name, u64 *result)
{
struct hv_register_assoc reg = {
@@ -300,6 +309,51 @@ static int __init hv_vsm_get_partition_status(u16 *enabled_vtl_set, u8 *max_vtl,
return 0;
}
+static int __init hv_vsm_init_code_page_offsets(void)
+{
+ union hv_register_vsm_page_offsets offsets;
+ u64 result;
+ int ret;
+
+ ret = hv_vsm_get_register(HV_REGISTER_VSM_CODE_PAGE_OFFSETS, &result);
+ if (ret) {
+ pr_err("Failed to read VSM code page offsets: %d\n", ret);
+ return ret;
+ }
+
+ offsets.as_uint64 = result;
+ hv_vsm_init_vtlcall(offsets.vtl_call_offset);
+ return 0;
+}
+
+static int __init hv_vsm_boot_vtl1(void)
+{
+ struct hv_vtlcall_param args = {0};
+ u16 vp_enabled_vtl_set = 0;
+ u8 active_mbec_enabled = 0;
+ int ret;
+ s64 sk_status;
+
+ args.a0 = num_possible_cpus();
+ args.a1 = sk_res.start;
+ args.a2 = resource_size(&sk_res);
+
+ /* Kick start vtl1 boot on the primary cpu. */
+ sk_status = hv_vsm_vtlcall(&args);
+ if (sk_status)
+ pr_warn("VTL1 boot returned status %lld\n", sk_status);
+
+ ret = hv_vsm_get_vp_status(&vp_enabled_vtl_set, &active_mbec_enabled);
+ if (ret)
+ return ret;
+
+ if (!active_mbec_enabled) {
+ pr_err("Failed to enable MBEC for VP0\n");
+ hv_vsm_mbec_enabled = false;
+ }
+ return 0;
+}
+
static int __init hv_vsm_bootstrap_vtl(void)
{
u16 partition_enabled_vtl_set = 0, partition_mbec_enabled_vtl_set = 0;
@@ -369,7 +423,14 @@ static int __init hv_vsm_bootstrap_vtl(void)
return -EINVAL;
}
}
- return 0;
+
+ /* Point the vtlcall trampoline at the correct hypercall page offset */
+ ret = hv_vsm_init_code_page_offsets();
+ if (ret)
+ return ret;
+
+ /* Boot primary virtual processor in VTL1 */
+ return hv_vsm_boot_vtl1();
}
static void __init hv_vsm_get_sk_mem(void)
--
2.34.1
next prev parent reply other threads:[~2026-09-01 16:57 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-01 16:55 [RFC PATCH 00/12] Introduce LVBS support for Hyper-V guests Thara Gopinath
2026-09-01 16:55 ` [RFC PATCH 01/12] drivers: hv: Add HYPERV_VSM kconfig option Thara Gopinath
2026-09-01 16:55 ` [RFC PATCH 02/12] drivers: hv: hv_common: Allocate Hyper-V output arg page when VSM is enabled Thara Gopinath
2026-09-01 16:55 ` [RFC PATCH 03/12] drivers: hv: Reserve memory for VSM secure kernel during early boot Thara Gopinath
2026-09-02 0:59 ` Wei Liu
2026-09-02 13:38 ` Thara Gopinath
2026-09-01 16:55 ` [RFC PATCH 04/12] firmware: efi: libstub: x86-stub: Enable VSM awareness in efi os indications variable Thara Gopinath
2026-09-02 1:09 ` Wei Liu
2026-09-02 14:23 ` Thara Gopinath
2026-09-01 16:55 ` [RFC PATCH 05/12] include: hyperv: hvgdk_mini.h: Add VTL-specific structures and bits Thara Gopinath
2026-09-01 16:55 ` [RFC PATCH 06/12] drivers: hv: Add VSM boot driver and enable VTL1 at the partition level Thara Gopinath
2026-09-02 1:16 ` Wei Liu
2026-09-02 14:28 ` Thara Gopinath
2026-09-02 4:43 ` Wei Liu
2026-09-04 13:23 ` Thara Gopinath
2026-09-01 16:55 ` [RFC PATCH 07/12] drivers: hv: hv_vsm_boot: load secure kernel image from firmware Thara Gopinath
2026-09-02 4:37 ` Wei Liu
2026-09-02 16:22 ` Thara Gopinath
2026-09-02 22:58 ` Wei Liu
2026-09-01 16:55 ` [RFC PATCH 08/12] arch: x86: hyperv: Build initial vCPU context for VTL1 secure kernel Thara Gopinath
2026-09-01 16:55 ` [RFC PATCH 09/12] drivers: hv: hv_vsm_boot: Enable VTL1 on the boot processor Thara Gopinath
2026-09-01 16:55 ` [RFC PATCH 10/12] arch: x86: hyperv: hv_vtl_vsm: Introduce vtlcall Thara Gopinath
2026-09-01 16:55 ` Thara Gopinath [this message]
2026-09-01 16:55 ` [RFC PATCH 12/12] drivers: hv: hv_vsm_boot: Boot secondary processors in VTL1 Thara Gopinath
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=20260901165647.3160413-12-tgopinath@linux.microsoft.com \
--to=tgopinath@linux.microsoft.com \
--cc="longli@microsoft.com--cc=tzimmermann"@suse.de \
--cc=James.Bottomley@HansenPartnership.com \
--cc=ardb@kernel.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=decui@microsoft.com \
--cc=francescopompo2@gmail.com \
--cc=haiyangz@microsoft.com \
--cc=hpa@zytor.com \
--cc=ilias.apalodimas@linaro.org \
--cc=javierm@redhat.com \
--cc=kys@microsoft.com \
--cc=linux-efi@vger.kernel.org \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lszubowi@redhat.com \
--cc=mingo@redhat.com \
--cc=tglx@kernel.org \
--cc=tgopinath@microsoft.com \
--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
all inboxes | Powered by JetHome®