From: Michael Kelley <mhklinux@outlook.com>
To: Roman Kisel <romank@linux.microsoft.com>,
"arnd@arndb.de" <arnd@arndb.de>,
"bhelgaas@google.com" <bhelgaas@google.com>,
"bp@alien8.de" <bp@alien8.de>,
"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"decui@microsoft.com" <decui@microsoft.com>,
"haiyangz@microsoft.com" <haiyangz@microsoft.com>,
"hpa@zytor.com" <hpa@zytor.com>, "kw@linux.com" <kw@linux.com>,
"kys@microsoft.com" <kys@microsoft.com>,
"lenb@kernel.org" <lenb@kernel.org>,
"lpieralisi@kernel.org" <lpieralisi@kernel.org>,
"mingo@redhat.com" <mingo@redhat.com>,
"rafael@kernel.org" <rafael@kernel.org>,
"robh@kernel.org" <robh@kernel.org>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"wei.liu@kernel.org" <wei.liu@kernel.org>,
"will@kernel.org" <will@kernel.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"x86@kernel.org" <x86@kernel.org>
Cc: "ssengar@microsoft.com" <ssengar@microsoft.com>,
"sunilmut@microsoft.com" <sunilmut@microsoft.com>,
"vdso@hexbites.dev" <vdso@hexbites.dev>
Subject: RE: [PATCH v2 4/6] arm64/hyperv: Boot in a Virtual Trust Level
Date: Wed, 15 May 2024 13:39:27 +0000 [thread overview]
Message-ID: <SN6PR02MB415778D73832B587A2758BD0D4EC2@SN6PR02MB4157.namprd02.prod.outlook.com> (raw)
In-Reply-To: <20240514224508.212318-5-romank@linux.microsoft.com>
From: Roman Kisel <romank@linux.microsoft.com> Sent: Tuesday, May 14, 2024 3:44 PM
>
> To run in the VTL mode, Hyper-V drivers have to know what
> VTL the system boots in, and the arm64/hyperv code does not
> update the variable that stores the value.
>
> Update the variable to enable the Hyper-V drivers to boot
> in the VTL mode and print the VTL the code runs in.
>
> Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
> ---
> arch/arm64/hyperv/Makefile | 1 +
> arch/arm64/hyperv/hv_vtl.c | 19 +++++++++++++++++++
> arch/arm64/hyperv/mshyperv.c | 6 ++++++
> arch/arm64/include/asm/mshyperv.h | 8 ++++++++
> arch/x86/hyperv/hv_vtl.c | 2 +-
> 5 files changed, 35 insertions(+), 1 deletion(-)
> 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..9b44cc49594c
> --- /dev/null
> +++ b/arch/arm64/hyperv/hv_vtl.c
> @@ -0,0 +1,19 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2023, Microsoft, Inc.
> + *
> + * Author : Roman Kisel <romank@linux.microsoft.com>
> + */
> +
> +#include <asm/mshyperv.h>
> +
> +void __init hv_vtl_init_platform(void)
> +{
> + pr_info("Linux runs in Hyper-V Virtual Trust Level %d\n", ms_hyperv.vtl);
> +}
> +
> +int __init hv_vtl_early_init(void)
> +{
> + return 0;
> +}
> +early_initcall(hv_vtl_early_init);
> diff --git a/arch/arm64/hyperv/mshyperv.c b/arch/arm64/hyperv/mshyperv.c
> index 208a3bcb9686..cbde483b167a 100644
> --- a/arch/arm64/hyperv/mshyperv.c
> +++ b/arch/arm64/hyperv/mshyperv.c
> @@ -96,6 +96,12 @@ static int __init hyperv_init(void)
> return ret;
> }
>
> + /* Find the VTL */
> + ms_hyperv.vtl = get_vtl();
> + if (ms_hyperv.vtl > 0) /* non default VTL */
> + hv_vtl_early_init();
Since hv_vtl_early_init() doesn't do anything on arm64, is the above
and the empty implementation of hv_vtl_early_init() really needed?
I thought maybe a subsequent patch in this series would populate
hv_vtl_early_init() to do something, but I didn't see such. I realize
the functions hv_vtl_init_platform() and hv_vtl_early_init() parallel
equivalent functions on x86, but I'd say drop hv_vtl_early_init() on
arm64 if it isn't needed.
Note too that the naming on the x86 side is arguably a bit messed
up. hv_vtl_init_platform() runs *before* hv_vtl_early_init(). But
typically in the Linux kernel, functions with "early init" in the name
run very early in boot, and that's not the case here. hv_vtl_init_platform()
is actually the function that runs very early in boot, but its name is
set up to parallel ms_hyperv_init_platform(), which calls it. On the
x86 side, I'd would argue for renaming hv_vtl_init_platform() to
hv_vtl_early_init(), and then hv_vtl_early_init() becomes hv_vtl_init().
But that's probably a separate patch. Here on arm64, perhaps all
you need is hv_vtl_init().
Michael
> +
> + hv_vtl_init_platform();
> ms_hyperv_late_init();
>
> hyperv_initialized = true;
> diff --git a/arch/arm64/include/asm/mshyperv.h
> b/arch/arm64/include/asm/mshyperv.h
> index a975e1a689dd..4a8ff6be389c 100644
> --- a/arch/arm64/include/asm/mshyperv.h
> +++ b/arch/arm64/include/asm/mshyperv.h
> @@ -49,6 +49,14 @@ static inline u64 hv_get_msr(unsigned int reg)
> ARM_SMCCC_OWNER_VENDOR_HYP, \
> HV_SMCCC_FUNC_NUMBER)
>
> +#ifdef CONFIG_HYPERV_VTL_MODE
> +void __init hv_vtl_init_platform(void);
> +int __init hv_vtl_early_init(void);
> +#else
> +static inline void __init hv_vtl_init_platform(void) {}
> +static inline int __init hv_vtl_early_init(void) { return 0; }
> +#endif
> +
> #include <asm-generic/mshyperv.h>
>
> #endif
> diff --git a/arch/x86/hyperv/hv_vtl.c b/arch/x86/hyperv/hv_vtl.c
> index 92bd5a55f093..ae3105375a12 100644
> --- a/arch/x86/hyperv/hv_vtl.c
> +++ b/arch/x86/hyperv/hv_vtl.c
> @@ -19,7 +19,7 @@ static struct real_mode_header hv_vtl_real_mode_header;
>
> void __init hv_vtl_init_platform(void)
> {
> - pr_info("Linux runs in Hyper-V Virtual Trust Level\n");
> + pr_info("Linux runs in Hyper-V Virtual Trust Level %d\n", ms_hyperv.vtl);
>
> x86_platform.realmode_reserve = x86_init_noop;
> x86_platform.realmode_init = x86_init_noop;
> --
> 2.45.0
>
next prev parent reply other threads:[~2024-05-15 13:39 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-14 22:43 [PATCH v2 0/6] arm64/hyperv: Support Virtual Trust Level Boot Roman Kisel
2024-05-14 22:43 ` [PATCH v2 1/6] arm64/hyperv: Support DeviceTree Roman Kisel
2024-05-15 7:45 ` Krzysztof Kozlowski
2024-05-15 17:33 ` Roman Kisel
2024-05-20 6:45 ` Krzysztof Kozlowski
2024-05-20 20:36 ` Roman Kisel
2024-05-15 22:02 ` Elliot Berman
2024-05-16 15:27 ` Roman Kisel
2024-05-14 22:43 ` [PATCH v2 2/6] drivers/hv: Enable VTL mode for arm64 Roman Kisel
2024-05-15 13:37 ` Michael Kelley
2024-05-15 18:04 ` Roman Kisel
2024-05-14 22:43 ` [PATCH v2 3/6] drivers/hv: arch-neutral implementation of get_vtl() Roman Kisel
2024-05-15 13:38 ` Michael Kelley
2024-05-15 18:11 ` Roman Kisel
2024-05-14 22:43 ` [PATCH v2 4/6] arm64/hyperv: Boot in a Virtual Trust Level Roman Kisel
2024-05-15 13:39 ` Michael Kelley [this message]
2024-05-15 18:13 ` Roman Kisel
2024-05-14 22:43 ` [PATCH v2 5/6] drivers/hv/vmbus: Get the irq number from DeviceTree Roman Kisel
2024-05-15 7:47 ` Krzysztof Kozlowski
2024-05-15 17:05 ` Roman Kisel
2024-05-15 9:42 ` Saurabh Singh Sengar
2024-05-15 16:31 ` Roman Kisel
2024-05-15 13:44 ` Michael Kelley
2024-05-15 18:21 ` Roman Kisel
2024-05-16 2:40 ` kernel test robot
2024-05-17 17:14 ` Rob Herring
2024-05-20 19:25 ` Roman Kisel
2024-05-14 22:43 ` [PATCH v2 6/6] drivers/pci/hyperv/arm64: vPCI MSI IRQ domain from DT Roman Kisel
2024-05-15 9:48 ` Saurabh Singh Sengar
2024-05-15 16:34 ` Roman Kisel
2024-05-15 18:12 ` Bjorn Helgaas
2024-05-15 18:34 ` Roman Kisel
2024-05-15 13:47 ` Michael Kelley
2024-05-15 18:31 ` Roman Kisel
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=SN6PR02MB415778D73832B587A2758BD0D4EC2@SN6PR02MB4157.namprd02.prod.outlook.com \
--to=mhklinux@outlook.com \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=dave.hansen@linux.intel.com \
--cc=decui@microsoft.com \
--cc=haiyangz@microsoft.com \
--cc=hpa@zytor.com \
--cc=kw@linux.com \
--cc=kys@microsoft.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=mingo@redhat.com \
--cc=rafael@kernel.org \
--cc=robh@kernel.org \
--cc=romank@linux.microsoft.com \
--cc=ssengar@microsoft.com \
--cc=sunilmut@microsoft.com \
--cc=tglx@linutronix.de \
--cc=vdso@hexbites.dev \
--cc=wei.liu@kernel.org \
--cc=will@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 read-only IMAP folder(s) and NNTP newsgroup(s).