Comment by achierius
8 hours ago
> while ARM does provide a reference implementation of the architecture, vendors are free to customize it at will, or even roll their own implementations
A nitpick, but this is only true for some vendors, depending on their license, and is very much company-by-company. Many vendors, even big names like Meta, don't have the ability to roll their own. And even for the ones who do, 'customize at will' is a bit strong, as ARM very much does want to maintain uniformity across userspace implementations. E.g. Nvidia shouldn't add new traps for architecturally-legal behavior, since then code compiled for Apple hardware wouldn't work on Grace. Or worse, not trap for architecturally-illegal behavior, since then code compiled for Grace might not work for anyone else at all!
TFA contains a reference to the Linux kernel, where there is a workaround for a quirk in the Apple CPUs, where in hypervisor mode they diverge from the official Aarch64 specification.
So by "vendors" it was indeed meant "some vendors" who can afford to not care much about compatibility with the specification.
It's an old comment.
iirc it's a documented feature now - FEAT_E2H0, https://support.arm.com/documentation/109697/2025_12/Feature...
And it was retroactively defined to be allowed starting from Armv8.0.
Apple designs pre-date the ID register bit for it being a thing so it takes a quirk there however.
This just means that Apple is a big enough player for ARM to retroactively amend the standard. Does not mean that what Apple did was not a violation of then-standard tho.
Unfortunately I can't comment much on Apple's situation since I work there :)
Regardless what I mean to convey is that ARM would prefer such deviations to be rare, and especially for them to not be visible from userspace. Deviations will always exist if only due to hardware bugs, so contracts can only do so much.