> It's possible to enable reserving the tag memory for MTE via `fastboot oem mte on`, boot a non-stock kernel ignoring arm64.nomte and use MTE.

What I'd like to know is, is it not sufficient to just check the feature bits in ID_AA64PFR1_EL1? (Isn't this the first thing you'd try when trying to determine if the hardware supports some feature?)

If they were making the determination solely based on the fact that `arm64.nomte` is being passed to the kernel (or based on what features are exposed by kernel interfaces), it may have been better to say "MTE is seemingly disabled in the current Android release" rather than claiming that it's simply not present in hardware. If you're asking the Linux kernel about hardware features, maybe it takes cmdline arguments into account when presenting that info to userspace.

The TRM[^1] mentions that some of the feature bits depend on BROADCASTMTE (presumably some CPU input pin), but maybe that signal isn't constant and is allowed to change based on what happens in firmware/the bootloader?

Also, why the claim about the lack of hardware acceleration for MTE in the caches, is there evidence for that, or is this also a misunderstanding?

I think it's reasonable to assume that the perf impact of MTE is non-negligible (on cores in older Pixel devices[^2], MTE apparently suffers from the fact that checked stores are serializing!), but it's entirely possible that this does not follow from some physical design concession when implementing the SoC. The characterization of all this as some kind of cost-cutting measure is not necessarily accurate.

[^1]: https://support.arm.com/documentation/108014/0101/?lang=en

[^2]: https://arxiv.org/pdf/2601.11786

▲

yxuehr 3 days ago | parent | next [-]

ID_AA64PFR1_EL1 was discussed five days ago

https://discuss.grapheneos.org/d/41564-pixel-11-doesnt-meet-...

	▲	eigenform 3 days ago \| parent [-]
		Fascinating, thank you. It seems strange that the C1-Pro/C1-Ultra TRM mention that ID_AA64PFR1_EL1[11:8] should still be non-zero even when BROADCASTMTE is low. edit: Oh, I guess Linux does emulate the feature registers, doh. Since that user is booting with arm64.nomte, the kernel is changing those feature bits to zero! This probably explains the confusion here about hardware support: in Linux userspace, you still trap for system register reads, and this is just abstracted away from you... https://github.com/torvalds/linux/blob/841e384b841a3d89c50b4...

▲

yaro330 4 days ago | parent | prev [-]

A "Google bad" essay gets a lot more clicks.