While some of the specifics are obviously x86 specific, I'm not sure that the underlying issues here are. From undocumented instructions, to lack of documentation about speculation barriers most of the root issues you see here are equally applicable to the cores in an M1.
> to lack of documentation about speculation barriers
Can you elaborate on this? I was having a look at the M1 instructions here [1] and it seems that they implement at least one of the barriers, CSDB, which is actually documented by ARM[2].
There's explicit speculation barriers that they document, but they don't tell you what _other_ instructions are speculation barriers simply due to microarchitectural compromises like what you're seeing in this article.
I'm not. My point is that this article was being unfairly interpreted by the parent as some black mark against x86. There's plenty to hold against it, but not really anything that's documented here. I probably should have made that clearer.
I'm kind of curious whether Apple aren't documenting M1 because they can't be bothered, can't (not organized enough yet), or because it's their toy not ours.
D) Scared that disclosing microarchitectural details will open them up to more patent fights that they have to pay off without a lot of benefit to endusers or developers.
E) Because they are doing things nobody else is allowed to (extending the ARMv8-A instruction set outside of the implementation-defined register mechanism, and blatantly breaking ARM architectural requirements like hard-coding VHE mode to on), and ARM lawyers are on the edge of their seats.
No, really, Apple are going out of their way not to document certain details about the M1, and this is almost certainly the reason. ARM are scared to death of fragmentation, Apple somehow managed to get away with doing it anyway, and ARM do not want anyone else to get any ideas.
It is at least possible (if not likely) that Apple has a special deal with ARM that lets them get away with all this.
Which may mean that ARM wants them to be quiet about. Not because Apple is breaking the rules, but because ARM doesn't want to rub into its other customers the fact that Apple has a special deal that other customers aren't being offered.
This sounds the most likely, tbh. Apple has been breaking the spec for years, but they’ve been very testy about ever mentioning their custom extensions and ARM has probably agreed to look the other way as long as they don’t draw attention to the fact.
> ARM has probably agreed to look the other way as long as they don’t draw attention to the fact
That makes it sound like it is some kind of "tacit understanding", "I won't say anything if you don't say anything". I'm suggesting that maybe Apple's license agreement explicitly states that they are allowed to do all this, but also maybe its confidentiality clauses prohibit either party from publicly acknowledging that fact without the other party's explicit permission.
A company like Apple – who has a well-funded legal department, and I've never heard any suggestion that they are anything other than competent – wouldn't set up a multi-billion dollar business on the foundation of "agreed to look the other way". They'd have it all set out in writing, crystal clear and totally secret.
Plus their funky intel-emulation related CPU features which introduce architectural EL0 state (SSE-specific FP flags, AP flags). Plus their hardcoded VHE=1 spec breakage now becomes relevant at EL2. And almost certainly more things we haven't figured out yet.
I am old enough to remember the "good old days" when there were OS/chip pairs from all the big companies. IBM, Sun, HP, SGI, DEC all had their own Unix versions that ran on their own hardware. That's part of the reason that tools like 'configure' are so ugly.
If Apple cared what ARM thought, they would have finished implementing the spec. AArch64 is as much Apple's as it is ARM's and I doubt they're scared. They have a do wtf you want license and ultimately don't really care if the rest of ARM withers and dies.
There is no such "do wtf you want" license. The ARM architectural license allows licensees (like Apple, Cavium, Samsung, and others) to implement CPUs that comply with the architecture. Some things are off-limits, like custom instructions. Apple broke those rules. They probably got away with doing that as a "special exception" under the understanding that they were doing so for "embedded" use cases, i.e. iOS devices that will only ever run iOS, but now that their designs are in an open platform (M1), things have changed, and ARM is not happy.
Apple literally designed large parts of AArch64. There's no do wtf you want license that you can go out and buy, but Apple has one none the less from the sheer fact that it's partially their's to begin with and they negotiated it with ARM before AArch64 was even a twinkle in their eyes.
ARM probably has some trademark mechanisms that they could in some world use to enforce compliance from Apple, but Apple has been super duper careful to refer to it as Apple Silicon rather than ARM.
How do you know? ARM's license agreements with Apple are confidential and just about nobody knows what's actually in them (and the few who have seen them aren't allowed to talk about it.)
The standard terms which ARM offers to its other customers may be quite different from the terms it has negotiated with Apple. Apple is a customer with unique clout and leverage, which means they can extract terms in negotiations which other customers may not be able to.
If ARM offers Apple (or any other customer) "special terms", it wants to keep that fact confidential, so that other customers who have the (less generous) standard terms don't start pressuring for special terms for them as well.
I know, because Apple went through the trouble of close-sourcing the M1 bring-up code in XNU source dumps... because it suddenly contains secret new instructions, while until now ARM XNU builds were largely public.
These instructions enable an entire new set of parallel execution modes, among other things, to run more protected kernel code. Completely nonstandard stuff.
Also, Apple somehow managed to push custom kernel support to the documentation of kmutil, but not the actual binary, until several macOS releases later. That would only happen if the latter got pulled for some extraneous reason.
I've been working on this since December; the entire situation is all showing signs pointing straight at ARM's lawyers having gotten involved to some extent.
I think there is another explanation for this than "they are breaking ARM's rules and either trying to hide it or getting in trouble"
It is: "They are following ARM's special rules for Apple only but they aren't allowed to tell anyone that those special rules for Apple only exist"
They might decide to leave certain processor extensions undocumented, even close source code which uses them, because they are worried disclosing them would implicitly reveal the existence of the "special rules for Apple", possibly violating the confidentiality clauses of the ARM-Apple contract containing those special rules.
So I still don't see how you know that "There is no such 'do wtf you want' license", when the behaviour you describe is compatible with their being one, but its existence being secret
That's what I said: that they got a special exemption (which is not part of ARM's official license offering) to allow them to do this for embedded use cases (iOS devices), which implied that they wouldn't be documenting or having other people use these instructions.
The problem is that the M1 threw a wrench in the works because now suddenly running non-Apple code that can use these instructions is allowed, and everyone else can see that they exist, so suddenly the existence of that special exemption is public.
The kmutil stuff sounds way more like they cut it at the last second for some QA issue, but the documentation tech writers are a different team and that part was missed. They wouldn't have figured out issues with lawyers this quickly.
The bring up stuff could be explained by being scared about some patent nonsense.
I have to say there is a "do wtf you want" license.
Hear me out. Say you like to speed and you have the money to pay fines and were okay with that. To a person like that what most people see as a "fine" becomes a "tax/fee."
What am I getting at?
Apples probably has a hand full of multi-layered legal strategies that ARMs legal team is somewhat aware of. Apple has the money to throw at it. Heck, they can start investing any estimated payout and if they do lose they will of still profited the interest from that investment plus the increased sales they think they are going to get.
