diff mbox series

[v2,2/4] xen: arm: make VMAP only support in MMU system

Message ID 20240808120936.3299937-3-ayan.kumar.halder@amd.com (mailing list archive)
State Superseded
Headers show
Series xen: arm: Split MMU code in preparation for MPU work (part 2) | expand

Commit Message

Ayan Kumar Halder Aug. 8, 2024, 12:09 p.m. UTC 
From: Penny Zheng <penny.zheng@arm.com>

VMAP is widely used in ALTERNATIVE feature to remap a range of memory
with new memory attributes. Since this is highly dependent on virtual
address translation, we choose to fold VMAP in MMU system.

In this patch, we introduce a new Kconfig CONFIG_HAS_VMAP, and make it
only support in MMU system on ARM architecture. And ALTERNATIVE now
depend on VMAP.

HARDEN_BRANCH_PREDICTOR is now gated on HAS_VMAP as speculative
attacks are not possible on non MMU based systems (ie Cortex-R52, R82).
See https://developer.arm.com/Arm%20Security%20Center/Speculative%20Processor%20Vulnerability.

Split "https://patchwork.kernel.org/project/xen-devel/patch/20230626033443.2943270-16-Penny.Zheng@arm.com/"
into Arm specific

Signed-off-by: Penny Zheng <penny.zheng@arm.com>
Signed-off-by: Wei Chen <wei.chen@arm.com>
Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
---
Changes from :-

v1 - 1. HARDEN_BRANCH_PREDICTOR is now gated on HAS_VMAP.
2. cpuerrata.c is not gated on HAS_VMAP.

 xen/arch/arm/Kconfig   | 7 ++++++-
 xen/arch/arm/setup.c   | 2 ++
 xen/include/xen/vmap.h | 2 ++
 3 files changed, 10 insertions(+), 1 deletion(-)

Comments

Jan Beulich Aug. 8, 2024, 12:49 p.m. UTC | #1 
On 08.08.2024 14:09, Ayan Kumar Halder wrote:
> @@ -58,9 +58,13 @@ config PADDR_BITS
>  	default 40 if ARM_PA_BITS_40
>  	default 48 if ARM_64
>  
> +config HAS_VMAP
> +	def_bool y

With this being always enabled, ...

>  config MMU
>  	def_bool y
>  	select HAS_PMAP
> +	select HAS_VMAP

.. what use is this?

> --- a/xen/include/xen/vmap.h
> +++ b/xen/include/xen/vmap.h
> @@ -141,7 +141,9 @@ void *arch_vmap_virt_end(void);
>  /* Initialises the VMAP_DEFAULT virtual range */
>  static inline void vm_init(void)
>  {
> +#ifdef CONFIG_MMU
>      vm_init_type(VMAP_DEFAULT, (void *)VMAP_VIRT_START, arch_vmap_virt_end());
> +#endif
>  }

What about non-Arm, which all have MMUs but no corresponding Kconfig
setting? And why is this not CONFIG_HAS_VMAP anyway (with HAS_VMAP
properly moved to common/Kconfig, where e.g. HAS_PMAP also lives,
and then unconditionally selected by all other architectures)?

Jan
Ayan Kumar Halder Aug. 8, 2024, 3:50 p.m. UTC | #2 
Hi Jan,

On 08/08/2024 13:49, Jan Beulich wrote:
> On 08.08.2024 14:09, Ayan Kumar Halder wrote:
>> @@ -58,9 +58,13 @@ config PADDR_BITS
>>   	default 40 if ARM_PA_BITS_40
>>   	default 48 if ARM_64
>>   
>> +config HAS_VMAP
>> +	def_bool y
> With this being always enabled, ...

I had to define the config somewhere. It seemed this is the correct 
place to define as HAS_VMAP will be turned off when MPU is introduced.

So, it will be

config HAS_VMAP

            def_bool n

At that time, only MMU will select HAS_VMAP.

>
>>   config MMU
>>   	def_bool y
>>   	select HAS_PMAP
>> +	select HAS_VMAP
> .. what use is this?
>
>> --- a/xen/include/xen/vmap.h
>> +++ b/xen/include/xen/vmap.h
>> @@ -141,7 +141,9 @@ void *arch_vmap_virt_end(void);
>>   /* Initialises the VMAP_DEFAULT virtual range */
>>   static inline void vm_init(void)
>>   {
>> +#ifdef CONFIG_MMU
>>       vm_init_type(VMAP_DEFAULT, (void *)VMAP_VIRT_START, arch_vmap_virt_end());
>> +#endif
>>   }
> What about non-Arm, which all have MMUs but no corresponding Kconfig
> setting?

AFAICS , the only file that is of our concern xen/common/vmap.c It is 
enclosed with VMAP_VIRT_START which is defined in mmu specific file 
(xen/arch/arm/include/asm/mmu/layout.h).

So, it will not be compiled for Arm MPU arch.

> And why is this not CONFIG_HAS_VMAP anyway (with HAS_VMAP
> properly moved to common/Kconfig, where e.g. HAS_PMAP also lives,
> and then unconditionally selected by all other architectures)?

I am not sure why CONFIG_HAS_VMAP should be moved to common/Kconfig when 
it will be selected/deselected only for Arm architecture.

- Ayan

>
> Jan
Jan Beulich Aug. 9, 2024, 9:34 a.m. UTC | #3 
On 08.08.2024 17:50, Ayan Kumar Halder wrote:
> On 08/08/2024 13:49, Jan Beulich wrote:
>> On 08.08.2024 14:09, Ayan Kumar Halder wrote:
>>> @@ -58,9 +58,13 @@ config PADDR_BITS
>>>   	default 40 if ARM_PA_BITS_40
>>>   	default 48 if ARM_64
>>>   
>>> +config HAS_VMAP
>>> +	def_bool y
>> With this being always enabled, ...
> 
> I had to define the config somewhere. It seemed this is the correct 
> place to define as HAS_VMAP will be turned off when MPU is introduced.
> 
> So, it will be
> 
> config HAS_VMAP
> 
>             def_bool n
> 
> At that time, only MMU will select HAS_VMAP.

Well, but why is it not simply

config HAS_VMAP
	bool

from the very beginning? (There should never be "def_bool n" imo, btw.)

>>> --- a/xen/include/xen/vmap.h
>>> +++ b/xen/include/xen/vmap.h
>>> @@ -141,7 +141,9 @@ void *arch_vmap_virt_end(void);
>>>   /* Initialises the VMAP_DEFAULT virtual range */
>>>   static inline void vm_init(void)
>>>   {
>>> +#ifdef CONFIG_MMU
>>>       vm_init_type(VMAP_DEFAULT, (void *)VMAP_VIRT_START, arch_vmap_virt_end());
>>> +#endif
>>>   }
>> What about non-Arm, which all have MMUs but no corresponding Kconfig
>> setting?
> 
> AFAICS , the only file that is of our concern xen/common/vmap.c It is 
> enclosed with VMAP_VIRT_START which is defined in mmu specific file 
> (xen/arch/arm/include/asm/mmu/layout.h).
> 
> So, it will not be compiled for Arm MPU arch.

Yet that wasn't my question. I asked about non-Arm, for all of which it
looks like you're changing behavior of vm_init() (by suddenly making it
do nothing).

>> And why is this not CONFIG_HAS_VMAP anyway (with HAS_VMAP
>> properly moved to common/Kconfig, where e.g. HAS_PMAP also lives,
>> and then unconditionally selected by all other architectures)?
> 
> I am not sure why CONFIG_HAS_VMAP should be moved to common/Kconfig when 
> it will be selected/deselected only for Arm architecture.

Because you will want to use that (not MMU) in vm_init().

Jan
Ayan Kumar Halder Aug. 12, 2024, 4:02 p.m. UTC | #4 
Hi Jan,

On 09/08/2024 10:34, Jan Beulich wrote:
> On 08.08.2024 17:50, Ayan Kumar Halder wrote:
>> On 08/08/2024 13:49, Jan Beulich wrote:
>>> On 08.08.2024 14:09, Ayan Kumar Halder wrote:
>>>> @@ -58,9 +58,13 @@ config PADDR_BITS
>>>>    	default 40 if ARM_PA_BITS_40
>>>>    	default 48 if ARM_64
>>>>    
>>>> +config HAS_VMAP
>>>> +	def_bool y
>>> With this being always enabled, ...
>> I had to define the config somewhere. It seemed this is the correct
>> place to define as HAS_VMAP will be turned off when MPU is introduced.
>>
>> So, it will be
>>
>> config HAS_VMAP
>>
>>              def_bool n
>>
>> At that time, only MMU will select HAS_VMAP.
> Well, but why is it not simply
>
> config HAS_VMAP
> 	bool
>
> from the very beginning? (There should never be "def_bool n" imo, btw.)
>
>>>> --- a/xen/include/xen/vmap.h
>>>> +++ b/xen/include/xen/vmap.h
>>>> @@ -141,7 +141,9 @@ void *arch_vmap_virt_end(void);
>>>>    /* Initialises the VMAP_DEFAULT virtual range */
>>>>    static inline void vm_init(void)
>>>>    {
>>>> +#ifdef CONFIG_MMU
>>>>        vm_init_type(VMAP_DEFAULT, (void *)VMAP_VIRT_START, arch_vmap_virt_end());
>>>> +#endif
>>>>    }
>>> What about non-Arm, which all have MMUs but no corresponding Kconfig
>>> setting?
>> AFAICS , the only file that is of our concern xen/common/vmap.c It is
>> enclosed with VMAP_VIRT_START which is defined in mmu specific file
>> (xen/arch/arm/include/asm/mmu/layout.h).
>>
>> So, it will not be compiled for Arm MPU arch.
> Yet that wasn't my question. I asked about non-Arm, for all of which it
> looks like you're changing behavior of vm_init() (by suddenly making it
> do nothing).

Oh now I see what you mean. There is no CONFIG_MMU is x86 , yet it is 
used to enclose a common code which is a mistake.

So, we should introduce HAS_VMAP in xen/common/Kconfig and select it 
from X86, X86_64 and Arm.

Is my understanding correct ?

- Ayan
Jan Beulich Aug. 13, 2024, 7:09 a.m. UTC | #5 
On 12.08.2024 18:02, Ayan Kumar Halder wrote:
> Hi Jan,
> 
> On 09/08/2024 10:34, Jan Beulich wrote:
>> On 08.08.2024 17:50, Ayan Kumar Halder wrote:
>>> On 08/08/2024 13:49, Jan Beulich wrote:
>>>> On 08.08.2024 14:09, Ayan Kumar Halder wrote:
>>>>> @@ -58,9 +58,13 @@ config PADDR_BITS
>>>>>    	default 40 if ARM_PA_BITS_40
>>>>>    	default 48 if ARM_64
>>>>>    
>>>>> +config HAS_VMAP
>>>>> +	def_bool y
>>>> With this being always enabled, ...
>>> I had to define the config somewhere. It seemed this is the correct
>>> place to define as HAS_VMAP will be turned off when MPU is introduced.
>>>
>>> So, it will be
>>>
>>> config HAS_VMAP
>>>
>>>              def_bool n
>>>
>>> At that time, only MMU will select HAS_VMAP.
>> Well, but why is it not simply
>>
>> config HAS_VMAP
>> 	bool
>>
>> from the very beginning? (There should never be "def_bool n" imo, btw.)
>>
>>>>> --- a/xen/include/xen/vmap.h
>>>>> +++ b/xen/include/xen/vmap.h
>>>>> @@ -141,7 +141,9 @@ void *arch_vmap_virt_end(void);
>>>>>    /* Initialises the VMAP_DEFAULT virtual range */
>>>>>    static inline void vm_init(void)
>>>>>    {
>>>>> +#ifdef CONFIG_MMU
>>>>>        vm_init_type(VMAP_DEFAULT, (void *)VMAP_VIRT_START, arch_vmap_virt_end());
>>>>> +#endif
>>>>>    }
>>>> What about non-Arm, which all have MMUs but no corresponding Kconfig
>>>> setting?
>>> AFAICS , the only file that is of our concern xen/common/vmap.c It is
>>> enclosed with VMAP_VIRT_START which is defined in mmu specific file
>>> (xen/arch/arm/include/asm/mmu/layout.h).
>>>
>>> So, it will not be compiled for Arm MPU arch.
>> Yet that wasn't my question. I asked about non-Arm, for all of which it
>> looks like you're changing behavior of vm_init() (by suddenly making it
>> do nothing).
> 
> Oh now I see what you mean. There is no CONFIG_MMU is x86 , yet it is 
> used to enclose a common code which is a mistake.
> 
> So, we should introduce HAS_VMAP in xen/common/Kconfig and select it 
> from X86, X86_64 and Arm.
> 
> Is my understanding correct ?

Almost. On Arm the select would be conditional, depending on (or simply
from) MMU.

Jan
diff mbox series

Patch

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 21d03d9f44..7d1dde89d7 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -12,7 +12,7 @@  config ARM_64
 config ARM
 	def_bool y
 	select FUNCTION_ALIGNMENT_4B
-	select HAS_ALTERNATIVE
+	select HAS_ALTERNATIVE if HAS_VMAP
 	select HAS_DEVICE_TREE
 	select HAS_PASSTHROUGH
 	select HAS_UBSAN
@@ -58,9 +58,13 @@  config PADDR_BITS
 	default 40 if ARM_PA_BITS_40
 	default 48 if ARM_64
 
+config HAS_VMAP
+	def_bool y
+
 config MMU
 	def_bool y
 	select HAS_PMAP
+	select HAS_VMAP
 
 source "arch/Kconfig"
 
@@ -171,6 +175,7 @@  config ARM_SSBD
 
 config HARDEN_BRANCH_PREDICTOR
 	bool "Harden the branch predictor against aliasing attacks" if EXPERT
+	depends on HAS_VMAP
 	default y
 	help
 	  Speculation attacks against some high-performance processors rely on
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index cb2c0a16b8..7f686d2cca 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -447,7 +447,9 @@  void asmlinkage __init start_xen(unsigned long boot_phys_offset,
      * It needs to be called after do_initcalls to be able to use
      * stop_machine (tasklets initialized via an initcall).
      */
+#ifdef CONFIG_HAS_ALTERNATIVE
     apply_alternatives_all();
+#endif
     enable_errata_workarounds();
     enable_cpu_features();
 
diff --git a/xen/include/xen/vmap.h b/xen/include/xen/vmap.h
index fdae37e950..4c7dfe58ba 100644
--- a/xen/include/xen/vmap.h
+++ b/xen/include/xen/vmap.h
@@ -141,7 +141,9 @@  void *arch_vmap_virt_end(void);
 /* Initialises the VMAP_DEFAULT virtual range */
 static inline void vm_init(void)
 {
+#ifdef CONFIG_MMU
     vm_init_type(VMAP_DEFAULT, (void *)VMAP_VIRT_START, arch_vmap_virt_end());
+#endif
 }
 
 #endif /* __XEN_VMAP_H__ */