On Thu, Mar 4, 2021 at 11:34 AM tan.shaopeng@fujitsu.com
[off-list ref] wrote:

quoted

quoted

On Wed, Mar 3, 2021 at 10:38 AM tan.shaopeng
[off-list ref] wrote:

quoted

quoted

quoted

+module_param(tagaddr_ctrl_reg, ulong, 0444);
+MODULE_PARM_DESC(tagaddr_ctrl_reg, "HPC tag address override

control register");

quoted

+module_param(hwpf_ctrl_reg, ulong, 0444);
+MODULE_PARM_DESC(hwpf_ctrl_reg, "hardware prefetch assist

control

quoted

quoted

register");

quoted

+module_param(sec_ctrl_reg, ulong, 0444);
+MODULE_PARM_DESC(sec_ctrl_reg, "sector cache control register");
+module_param(sec_assign_reg, ulong, 0444);
+MODULE_PARM_DESC(sec_assign_reg, "sector cache assign

register");

quoted

quoted

quoted

+module_param(sec_set0_l2_reg, ulong, 0444);
+MODULE_PARM_DESC(sec_set0_l2_reg, "sector cache L2 way

register(sector=0,1)");

quoted

+module_param(sec_set1_l2_reg, ulong, 0444);
+MODULE_PARM_DESC(sec_set1_l2_reg, "sector cache L2 way

register(sector=2,3)");

My feeling is that the actual settings need to be on a higher level, not tied
to the specific register-level implementation of this chip. Normally,  the L2
cache is set up by the firmware according to local policy, and the settings
can either be read by the kernel from registers or passed down through the
device tree. It sounds like you want to control the policy at runtime in the
operating system rather than at boot time, so for each setting you wish to
override, there should be description of what the setting does and what
the purpose of overriding the firmware setting is.

OK, I will change module parameter from specific register-level to
a higher level. And, I will modify the description of module parameters.
To be clear, we don't suppose these parameters (EL1 registers) are
often changed at runtime.

quoted

Looking at the first one in the list, I see the specification mentions
multiple distinct features that can be enabled or disabled, so these
should probably get controlled individually.

It is not necessary to enable/disable every feature individually.
There are no plans to use these features individually.

Ok, in that case you probably want a smaller number of global
settings can describe all the combinations one may need in
practice.

Thanks for your advice. 
I will consider the optimal module parameters if we end up make a driver.

quoted

quoted

I also see that it is possible
to control this for TTBR1 and TTBR0 separately, and we probably
cannot allow user space (through module parameters or any other
interface) to control TTBR1, which is where the kernel resides.

This driver does not change the values of TTBR0 and TTBR1,
and the values of TCR_EL1.TBI0 and TCR_EL1.TBI1.
The cache functions can be used when TBI is already enabled.

quoted

The TTBR0 settings in turn would seem to interact with
CONFIG_ARM64_MTE, and should not be controlled independently
but through the same interfaces as that if we find that it does need
to be controlled at all.

MTE is not supported on A64FX.
So, this function does not conflict with MTE.

But could you guarantee that no future generation might support
both features? In either case, it sounds like the kernel would need
to know when this is enabled in the same way: as far as I understand,
both of these put extra information into the upper eight bits of a
pointer, and any code that interacts with user addresses would need
to know about this.

I think these functions and MTE cannot be enabled 
at the same time on hardware level.

Best regards,
Tan Shaopeng
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel