Re: [PATCH v1 2/4] xen: arm: make VMAP only support in MMU system

[Julien Grall <julien@xxxxxxx>]

Hi Ayan,

On 05/08/2024 11:44, Ayan Kumar Halder wrote:
> On 02/08/2024 14:27, Julien Grall wrote:
> > Hi,
> Hi Julien,
> > On 02/08/2024 13:14, Ayan Kumar Halder wrote:
> > > From: Penny Zheng <penny.zheng@xxxxxxx>
> > >
> > > VMAP is widely used in ALTERNATIVE feature, CPUERRATA feature, etc 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 we make features
> > > like ALTERNATIVE, CPUERRATA, etc, now depend on VMAP.
> > While I agree that alternative should depend on VMAP (for now), I feel 
> > this is incorrect for CPUERRATA. Very likely, you will need to deal 
> > with them on the MPU.
> > Before making any suggestion, would you be able to clarify how you 
> > envision to deal with errata? Will they be selected at built time or 
> > boot time?
> TBH, I hadn't thought that through. I am thinking about selecting them 
> at built time (like it is been done for Arm64 cpus).
To clarify, on arm64, the decision to enable the bulk of mitigation is 
done at runtime. The Kconfig is just to remove it from the binary if you 
you are not targeting such HW. With that in mind...
> However given that there are lesser number of MPU cpus (only R52 and 
> R82) compared to  MMU ones, could there be a simpler approach.
... do you mean always an errata enabled in the Kconfig would be always 
mitigate (IOW no runtime selection)?
> I am open to any suggestions you have.
>
> Also, can we disable the CPUERRATA on MPU until we add support for the 
> first errata ?
So I have looked at the code and it is rather unclear why you actually 
need to disable CPU Errata. Can you clarify what would happen if 
cpuerrata is always built *and* CONFIG_ARM64_HARDEN_BRANCH_PREDICATOR is 
gated by HAS_VMAP? I am assuming we will not need the branch predictor 
hardening on Cortex-R (at least this is the implication from [1]).
Now regarding alternative, at least for arm64 this is used outside of 
the errata. Not critical right now, but at some point you will want to 
re-enable alternatives.
Cheers,

[1] 
https://developer.arm.com/Arm%20Security%20Center/Speculative%20Processor%20Vulnerability

--
Julien Grall