On Tue, Dec 14, 2021 at 04:19:05PM +0800, Yee Lee wrote:

On Fri, 2021-12-03 at 16:33 +0000, Catalin Marinas wrote:

quoted

On Thu, Nov 25, 2021 at 06:19:29PM +0800, Yee Lee wrote:

quoted

As pointed out earlier, the hardware has been verified that still has
transaction sending to DRAM due to mair_el1(Normal_tagged) is
setup.  That means the override in this patch would be incompleted and
cannot achieve to avoid undesired hardware confliction by disabling MTE.

Do we have other options to delay the configuration on MAIR_EL1 after
the override? Or maybe another CONFIG to bypass the init in __cpu_setup?

This register is trickier as it may be cached in the TLB (IIRC). I think
deferring the setting of SCTLR_EL1.ATA(0) should be sufficient. Can you
try the diff I sent in the previous email and confirm that the accesses
to the allocation tag storage are blocked?

Yes, the previous diff is already online. 

In our experiment, with cmdline, "arm64.nomte", cpu_enable_mte() is
bypassed and the ATA0 is not set, but the access to tag memory still
dispatches. Only as MAIR_EL1 remains MAIR_ATTR_NORMAL, instead of
MAIR_ATTR_NORMAL_TAGGED, the access will stop.

From the manual, I think ATA only affects TAG instructions like STG,
IRG, but not the tag access within normal STR/LDR.

The ARM ARM states SCTLR_EL1.ATA0 == 0 means "access to allocation tags
is prevented". The AArch64.MemSingle[] pseudocode ends up with similar
checks:

https://developer.arm.com/documentation/ddi0596/2021-09/Shared-Pseudocode/AArch64-Functions?lang=en#AArch64.MemSingle.read.5

before reading the tags from memory in AArch64.CheckTag():

https://developer.arm.com/documentation/ddi0596/2021-09/Shared-Pseudocode/AArch64-Functions?lang=en#AArch64.CheckTag.4

My suggestion is to raise this with support@arm.com (feel free to cc me)
so that we clarify the hardware behaviour. I don't think it's entirely
correct (it's more like, is there a risk of external aborts caused by
access to allocation tag storage that's not present?)

-- 
Catalin