> but that's to be expected according to the manual
Confusingly, the AMD programming manual (Rev. 3.38 - July 2026) only explicitly states this ("that the result is always zero when CF=0") in the description of RDSEED, but the Intel SDM mentions this in the description of both instructions.
> 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.
That's disabled unless the firmware sets up MTE and doesn't disable it for the OS. The Pixel 11 shipped with MTE hard-wired to disabled via the firmware with no way to enable it. The initial August 2026 update and the early non-QPR1 September 2026 update didn't enable it either.
Android 16 QPR2 Beta 4 was released around 2 days after we made our initial thread and added back partial firmware support for MTE. It's now possible to enable it again via a fastboot command, but not via the OS using Android Advanced Protection Mode or developer options. It's still disabled from the OS perspective but it can be forcibly used after enabling it in the firmware using ADB.
The way it shipped was that it was entirely unavailable due to the firmware not having support for setting it up for usage. It's not present in the OS in the way it is for the Pixel 8 through Pixel 10a either.
It's now usable with the Android 16 QPR2 Beta 4 firmware but it appears there's something wrong with it, otherwise it wouldn't be disabled tghis way.
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...
What you want is a proof that microarchitectural timing differences (ie. the difference between a cache hit and cache miss) cannot possibly turn into architecturally-visible timing differences. If a program cannot reliably distinguish between two points in time, time is not a suitable channel for programs.
You could have an ISA where timing information is simply not presented to the programmer, but programmers like being able to profile their programs.
It's good to be skeptical about how we implement the idea of a "root of trust" in these machines, but matter-of-factly characterizing ME and PSP as "backdoor" is misleading and not useful.
The difference is that this is not the programmer's responsibility in modern machines: instead we bake-in some hardware that watches the online state of the machine and then actively decides on what to do.
If you're trying to create a compiler that approaches the effectiveness of this statically, you're condemned to do a ton of extra work (you're essentially writing an emulator for your CPU core, and then a compiler that uses that model to produce optimal code - even then, you might not be accounting for nondeterminism on the actual target machine, and some information is simply not accessible to you when you are not on the target machine)
Once again, Itanium isn't a normal, simple in order core that stalls on loads. It has a big table called the ALAT to allow you to start loads as soon as you know the address, and then finalize them later when you're out of other work to do.
It doesn't require determinism to work. And was designed by people that were quite aware of what the instruction stream looks like to an OoO core as it issues out of the rob.
Itanium had other sins than "magic compiler" woes, or even the inherent unpredictability of memory accesses. Mostly that it, like Cell, and Netburst was designed for a world where dennard scaling didn't end like a brick wall. As well as internal politics of Intel making it so that they were a bit loose and fast with die area.
Yes, I'm pointing out the fact that the programmer is expected to manage the ALAT, and that these machines do not automatically recover from cases where your advanced loads are incorrect. That process is expected to be part of the instruction stream, and [we have collectively learned that] that's an expensive feedback loop.
Yes, it doesn't require determinism to work, but it means that your performance is especially sensitive to nondeterminism because the compiler cannot account for loads and stores that occur online. The SDM (see vol 1, section 9.5.1) describes this idea pretty well.
You didn't generally need to manage the ALAT as a programmer.
You can, in the same way that you can manually manage reservation station port residency as a programmer in an OoO core to get maximum throughput, but neither of those are required in normal programming.
Additionally, if you look at the changelogs for old ABL, it seems like this policy decision (only supporting for PRO SKUs) has always been implemented in firmware:
Well, the FDIV bug is simpler. AFAICT this whole thing is tied up in the relationship between DVFS, silicon aging, and being able to have guarantees about clock reliability. That seems hard to reason about when you give BIOS vendors and users the ability to do over-volting/over-clocking (and of course, it's worse when you are maybe relying on all this in certain situations to try and approach parity with other hardware vendors who are taping out machines on CMOS processes that are more mature than yours).
afaict part of the messaging behind this quake is about the worry that big Sanriku earthquakes like this might make it easier for the northeast part of the trench to unlock (closer to Aomori and Hokkaido, where the Japan Trench starts turning into the Kuril Trench).
Confusingly, the AMD programming manual (Rev. 3.38 - July 2026) only explicitly states this ("that the result is always zero when CF=0") in the description of RDSEED, but the Intel SDM mentions this in the description of both instructions.
reply