diff mbox series

[v3,2/7] Drivers: hv: Enable VTL mode for arm64

Message ID 20240726225910.1912537-3-romank@linux.microsoft.com
State New
Headers show
Series arm64: hyperv: Support Virtual Trust Level Boot | expand

Commit Message

Roman Kisel July 26, 2024, 10:59 p.m. UTC
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@linux.microsoft.com>
---
 drivers/hv/Kconfig | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

Comments

Wei Liu Aug. 3, 2024, 1:21 a.m. UTC | #1
On Fri, Jul 26, 2024 at 03:59:05PM -0700, Roman Kisel wrote:
> 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@linux.microsoft.com>

Acked-by: Wei Liu <wei.liu@kernel.org>
Michael Kelley Aug. 5, 2024, 3:01 a.m. UTC | #2
From: Roman Kisel <romank@linux.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@linux.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.

Michael

[1] https://lore.kernel.org/all/SN6PR02MB4157E15EFE263BBA3D8DFC51D4EC2@SN6PR02MB4157.namprd02.prod.outlook.com/
Saurabh Singh Sengar Aug. 5, 2024, 4:05 a.m. UTC | #3
On Mon, Aug 05, 2024 at 03:01:58AM +0000, Michael Kelley wrote:
> From: Roman Kisel <romank@linux.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@linux.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.

- Saurabh
Roman Kisel Aug. 5, 2024, 3:24 p.m. UTC | #4
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@linux.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@linux.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
Michael Kelley Aug. 5, 2024, 7:51 p.m. UTC | #5
From: Roman Kisel <romank@linux.microsoft.com> Sent: Monday, August 5, 2024 8:24 AM
> 
> 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@linux.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@linux.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!
> 

This is what I had in mind:

--- a/drivers/hv/Kconfig
+++ b/drivers/hv/Kconfig
@@ -5,7 +5,8 @@ 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)
+       depends on (ACPI || HYPERV_VTL_MODE)
        select PARAVIRT
        select X86_HV_CALLBACK_VECTOR if X86
        select OF_EARLY_FLATTREE if OF
@@ -15,7 +16,7 @@ config HYPERV

 config HYPERV_VTL_MODE
        bool "Enable Linux to boot in VTL context"
-       depends on X86_64 && HYPERV
+       depends on X86_64
        depends on SMP
        default n
        help

HYPERV_VTL_MODE can now be selected independently of HYPERV.
The existing code should be such that even if someone is building a
random config and gets HYPERV_VTL_MODE without HYPERV, the
kernel will build and run in a non-Hyper-V environment and isn't
broken somehow.

For HYPERV to be selected, either ACPI must already be selected, or
HYPERV_VTL_MODE must already be selected. So "normal" kernels are
still enforced to require ACPI. But if building with HYPERV_VTL_MODE,
then ACPI is optional.

Saurabh's idea of adding "depends on OF" to HYPERV_VTL_MODE
should also work with these changes.

I haven't fully tested the above with all the relevant combinations
on both x86 and arm64, but I think the logic makes sense.

Michael
Roman Kisel Aug. 5, 2024, 10:15 p.m. UTC | #6
> > 
> > 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@linux.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@linux.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!
> > 
> 
> This is what I had in mind:
> 
> --- a/drivers/hv/Kconfig
> +++ b/drivers/hv/Kconfig
> @@ -5,7 +5,8 @@ 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)
> +       depends on (ACPI || HYPERV_VTL_MODE)
        > select PARAVIRT
        > select X86_HV_CALLBACK_VECTOR if X86
        > select OF_EARLY_FLATTREE if OF
> @@ -15,7 +16,7 @@ config HYPERV
> 
 > config HYPERV_VTL_MODE
        > bool "Enable Linux to boot in VTL context"
> -       depends on X86_64 && HYPERV
> +       depends on X86_64
        > depends on SMP
        > default n
        > help
> 
> HYPERV_VTL_MODE can now be selected independently of HYPERV.
> The existing code should be such that even if someone is building a
> random config and gets HYPERV_VTL_MODE without HYPERV, the
> kernel will build and run in a non-Hyper-V environment and isn't
> broken somehow.
> 
> For HYPERV to be selected, either ACPI must already be selected, or
> HYPERV_VTL_MODE must already be selected. So "normal" kernels are
> still enforced to require ACPI. But if building with HYPERV_VTL_MODE,
> then ACPI is optional.
> 
Thanks a ton! Let me try this out for the (arch; VTL) build matrix :)

> Saurabh's idea of adding "depends on OF" to HYPERV_VTL_MODE
> should also work with these changes.
> 
> I haven't fully tested the above with all the relevant combinations
> on both x86 and arm64, but I think the logic makes sense.
diff mbox series

Patch

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.