[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ebac7069-0396-4b33-88b8-60d5e2594c88@linux.microsoft.com>
Date: Mon, 5 Aug 2024 08:24:08 -0700
From: Roman Kisel <romank@...ux.microsoft.com>
To: Saurabh Singh Sengar <ssengar@...ux.microsoft.com>,
Michael Kelley <mhklinux@...look.com>
Cc: "arnd@...db.de" <arnd@...db.de>, "bhelgaas@...gle.com"
<bhelgaas@...gle.com>, "bp@...en8.de" <bp@...en8.de>,
"catalin.marinas@....com" <catalin.marinas@....com>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
"decui@...rosoft.com" <decui@...rosoft.com>,
"haiyangz@...rosoft.com" <haiyangz@...rosoft.com>,
"hpa@...or.com" <hpa@...or.com>, "kw@...ux.com" <kw@...ux.com>,
"kys@...rosoft.com" <kys@...rosoft.com>, "lenb@...nel.org"
<lenb@...nel.org>, "lpieralisi@...nel.org" <lpieralisi@...nel.org>,
"mingo@...hat.com" <mingo@...hat.com>, "rafael@...nel.org"
<rafael@...nel.org>, "robh@...nel.org" <robh@...nel.org>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"wei.liu@...nel.org" <wei.liu@...nel.org>, "will@...nel.org"
<will@...nel.org>, "linux-acpi@...r.kernel.org"
<linux-acpi@...r.kernel.org>,
"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
"x86@...nel.org" <x86@...nel.org>, "apais@...rosoft.com"
<apais@...rosoft.com>, "benhill@...rosoft.com" <benhill@...rosoft.com>,
"ssengar@...rosoft.com" <ssengar@...rosoft.com>,
"sunilmut@...rosoft.com" <sunilmut@...rosoft.com>,
"vdso@...bites.dev" <vdso@...bites.dev>
Subject: Re: [PATCH v3 2/7] Drivers: hv: Enable VTL mode for arm64
On 8/4/2024 9:05 PM, Saurabh Singh Sengar wrote:
> On Mon, Aug 05, 2024 at 03:01:58AM +0000, Michael Kelley wrote:
>> From: Roman Kisel <romank@...ux.microsoft.com> Sent: Friday, July 26, 2024 3:59 PM
>>>
>>> Kconfig dependencies for arm64 guests on Hyper-V require that be ACPI enabled,
>>> and limit VTL mode to x86/x64. To enable VTL mode on arm64 as well, update the
>>> dependencies. Since VTL mode requires DeviceTree instead of ACPI, don't require
>>> arm64 guests on Hyper-V to have ACPI.
>>>
>>> Signed-off-by: Roman Kisel <romank@...ux.microsoft.com>
>>> ---
>>> drivers/hv/Kconfig | 6 +++---
>>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
>>> index 862c47b191af..a5cd1365e248 100644
>>> --- a/drivers/hv/Kconfig
>>> +++ b/drivers/hv/Kconfig
>>> @@ -5,7 +5,7 @@ menu "Microsoft Hyper-V guest support"
>>> config HYPERV
>>> tristate "Microsoft Hyper-V client drivers"
>>> depends on (X86 && X86_LOCAL_APIC && HYPERVISOR_GUEST) \
>>> - || (ACPI && ARM64 && !CPU_BIG_ENDIAN)
>>> + || (ARM64 && !CPU_BIG_ENDIAN)
>>> select PARAVIRT
>>> select X86_HV_CALLBACK_VECTOR if X86
>>> select OF_EARLY_FLATTREE if OF
>>> @@ -15,7 +15,7 @@ config HYPERV
>>>
>>> config HYPERV_VTL_MODE
>>> bool "Enable Linux to boot in VTL context"
>>> - depends on X86_64 && HYPERV
>>> + depends on HYPERV
>>> depends on SMP
>>> default n
>>> help
>>> @@ -31,7 +31,7 @@ config HYPERV_VTL_MODE
>>>
>>> Select this option to build a Linux kernel to run at a VTL other than
>>> the normal VTL0, which currently is only VTL2. This option
>>> - initializes the x86 platform for VTL2, and adds the ability to boot
>>> + initializes the kernel to run in VTL2, and adds the ability to boot
>>> secondary CPUs directly into 64-bit context as required for VTLs other
>>> than 0. A kernel built with this option must run at VTL2, and will
>>> not run as a normal guest.
>>> --
>>> 2.34.1
>>>
>>
>> In v2 of this patch, I suggested [1] making a couple additional minor changes
>> so that kernels built *without* HYPER_VTL_MODE would still require
>> ACPI. Did that suggestion not work out? If that's the case, I'm curious
>> about what goes wrong.
>
> Hi Michael/Roman,
> I was considering making HYPERV_VTL_MODE depend on CONFIG_OF. That should address
> above concern as well. Do you see any potential issue with it.
>
Michael,
I ran into a pretty gnarly recursive dependencies which in all fairness
might stem from not being fluent enough in the Kconfig language. Any
help of how to approach implementing your idea would be greatly appreciated!
Saurabh,
I could try out the idea you're offering if you folks are fine with
that. Or, we could let this be for the time being and grapple with that
in a separate patch series :)
> - Saurabh
--
Thank you,
Roman
Powered by blists - more mailing lists