On Tue, May 14, 2024 at 11:18:13AM +0100, Suzuki K Poulose wrote: > On 10/05/2024 18:35, Catalin Marinas wrote: > > On Fri, Apr 12, 2024 at 09:42:01AM +0100, Steven Price wrote: > > > +void arm64_setup_memory(void) > > > > I would give this function a better name, something to resemble the RSI > > setup. Similarly for others like set_memory_range_protected/shared(). > > Some of the functions have 'rsi' in the name like arm64_rsi_init() but > > others don't and at a first look they'd seem like some generic memory > > setup on arm64, not RSI-specific. > > Ack. arm64_rsi_setup_memory() ? I agree, we should "rsi" fy the names. This should work. We also have rsi_*() functions without any 'arm64' but those are strictly about communicating with the RMM, so that's fine. > > > @@ -293,6 +294,8 @@ void __init __no_sanitize_address setup_arch(char **cmdline_p) > > > * cpufeature code and early parameters. > > > */ > > > jump_label_init(); > > > + /* Init RSI after jump_labels are active */ > > > + arm64_rsi_init(); > > > parse_early_param(); > > > > Does it need to be this early? It's fine for now but I wonder whether we > > may have some early parameter at some point that could influence what we > > do in the arm64_rsi_init(). I'd move it after or maybe even as part of > > the arm64_setup_memory(), though I haven't read the following patches if > > they update this function. > > We must do this before we setup the "earlycon", so that the console > is accessed using shared alias and that happens via parse_early_param() :-(. Ah, ok, makes sense. -- Catalin
