On August 29, 2026, x86 documentation author Christian Ludloff posted a set of previously undocumented WBINVD prefixes to the Linux kernel mailing list, asking that the opcodes not be redefined because they are in active use by a corporate entity other than Intel or AMD. Ten hints, ranging from skipping the L0 and L1 instruction caches to turning the whole flush into a pure write back, describe cache behaviour that no public x86 product has. It is the third such message since October 2025, and the vendor still has no name. Here is what was disclosed, and why it matters if you maintain a disassembler.
The short answer
Christian Ludloff, who maintains the sandpile.org x86 reference, posted a set of WBINVD cache skip hints to the Linux kernel mailing list on August 29, 2026, relaying them on behalf of a corporate entity other than Intel or AMD and asking that the encodings not be redefined. The hints let the instruction skip the L0 and L1 instruction caches, the L0 and L1 data caches, or the last level cache, and one turns the flush into a write back with no invalidation. This is the third disclosure of its kind, after CPUID and MSR range allocations in October 2025 and a 16 and 32 tile AMX description in July 2026. No product, no name, no announcement.
There are two companies that ship x86 processors you can walk into a shop and buy. For the past ten months, someone has been filing paperwork for a third one, and declining to say who it is.
The instruction, and the hints bolted onto it
WBINVD is one of the least subtle instructions in the architecture. It writes every dirty cache line back to memory and then invalidates the caches, top to bottom, including the last level cache shared across the socket. Kernels reach for it when memory has to be made coherent with something outside the coherency domain, or before a power transition that will drop cache contents. It is correct, it is privileged, and it is expensive enough that hypervisors have spent years trying to avoid executing it on behalf of guests.
The August 29 posting describes hints that let the caller say which parts of that work to skip. A 0x67 prefix leaves the L0 and L1 instruction caches untouched. A 0x66 prefix does the same for the L0 and L1 data caches. 0xF2 skips the last level cache, which is the expensive part. 0xF3 skips the invalidation, so what remains is a write back that leaves the lines valid in cache, which is a genuinely different operation rather than a cheaper version of the same one.
The six segment prefixes, ES, CS, SS, DS, FS and GS, carry six further implementation specific meanings that were not detailed. Because prefixes compose, a WBINVD carrying a full set of hints can occupy twelve bytes, close to the fifteen byte ceiling on instruction length. The request attached to all of it was simple: these are in active use, do not redefine them.
What came before
This is the third message in the sequence, and the earlier two were larger.
In October 2025, Ludloff relayed opcode allocations for the same unnamed entity, including CPUID leaves in the E000_xxxx range and matching MSR ranges. Reserving a CPUID leaf range is what you do when you have architectural features to enumerate, not when you are experimenting.
Then on July 27, 2026 came the interesting one. Intel's AMX gives you eight tile registers, each holding up to sixteen rows of sixty four bytes, so one kilobyte per tile and eight kilobytes of architectural state per thread. The posting described implementations with sixteen and thirty two tiles. Sixteen fits inside the existing VEX encodings, addressing TMM0 through TMM15, and the TILECFG structure already carries fields for sixteen tiles that Intel hardware simply leaves unused. Thirty two needs EVEX encodings and grows TILECFG from sixty four bytes to one hundred and twenty eight.
Thirty two kilobytes of tile state per thread is a lot of context to save and restore. It points at a part built around matrix work rather than a general purpose core that happens to carry a matrix unit, and the posting noted that existing software assuming eight kilobytes would simply run in a degraded mode.
The attribution problem
The obvious question has no confirmed answer. Chips and Cheese assembled the most careful public attempt at one, centred on RosaicLabs, a company incorporated in Delaware in May 2026 and led by Amarjit Gill, a semiconductor executive who worked with current Intel chief executive Lip Bu Tan at Rivos. Reuters and SemiAccurate have reported that Intel handed RosaicLabs RTL code for its Atom cores, which would be a real break from a company that has guarded both its x86 licences and its core designs for decades.
The trouble is the calendar. The first mystery posting landed in October 2025, seven months before RosaicLabs existed on paper, and Chips and Cheese states plainly that no public source connects the company to the mystery implementation. Access to Atom RTL also does not hand anyone a thirty two tile matrix engine. Zhaoxin, Hygon, the hyperscalers building their own silicon, and whatever survives of the Centaur lineage are all still on the table. It is a good story with no ending yet.
Why this lands on your desk
If you maintain anything that decodes x86, this is the whole point of the exercise. Objdump, perf, Valgrind, QEMU, Bochs, coverage tools and every homegrown trace parser hold an opinion about what a prefix combination means. When two parties assign meanings to the same bytes, the fix is painful and arrives late.
For everyone else it is a signal worth filing. The x86 duopoly has been stable for so long that most capacity planning quietly assumes it, in the same way that IBM putting Arm instructions inside a mainframe core or Samsung moving MAC units into LPDDR5X cut against assumptions people had stopped examining. Someone with enough conviction to reserve opcode space intends to ship something. We just do not get to know what yet.
Sources and further reading
- Another x86 Advisory From Some Entity Other Than Intel Or AMD, Phoronix, August 29, 2026
- Ten New x86 WBINVD Prefixes Hit the Kernel List, From a Vendor That Isn't Intel or AMD, Hardware Busters
- RosaicLabs, Atom RTL, and 32-Tile AMX: Trying to Piece Together a x86 Puzzle, Chips and Cheese
- sandpile.org, the x86 architecture reference maintained by Christian Ludloff
Frequently asked questions
What does WBINVD actually do?
WBINVD writes back every dirty cache line to memory and then invalidates the caches. It is a blunt, privileged instruction used mostly when the kernel has to make memory coherent with something that does not participate in cache coherency, such as a device doing DMA outside the coherent fabric, or a processor entering a power state where cache contents will be lost. Because it walks the whole hierarchy including the last level cache, it is slow and it affects every other core sharing that cache, which is exactly why a vendor would want a way to skip the parts it does not need.
What are the new hints, concretely?
They are prefix bytes attached to the instruction. 0x67 tells the processor to leave the L0 and L1 instruction caches alone, 0x66 does the same for the L0 and L1 data caches, 0xF2 skips the last level cache, and 0xF3 skips the invalidation step so the operation becomes a pure write back with the lines left valid. On top of those, the six segment prefixes ES, CS, SS, DS, FS and GS carry implementation specific meanings that were not spelled out. Prefixes can be combined, which is how a one byte instruction ends up as much as twelve bytes long.
Is this a new processor we can buy?
No. Nothing has been announced, no product name exists, and the vendor is not identified in any of the postings. What we have is a request that the opcode space not be reused, which implies silicon or at least a design mature enough that changing the encoding would be expensive. The July 2026 posting went further and said the wider matrix implementation had been running at large scale for some time, though that phrasing could cover simulation, emulation or FPGA prototypes as easily as production parts.
Why post this to the Linux kernel list rather than publish a manual?
Because the kernel and the GNU toolchain are where x86 opcode space is effectively claimed. If binutils, the kernel decoder or an emulator assigns a meaning to a prefix combination that hardware already uses, the two definitions collide and someone has to unpick it years later. Posting to the list stakes a claim without publishing a product. It also means the information reaches the people who maintain disassemblers, which is the audience that would otherwise print bad output the first time one of these instructions appears in a trace.
Who is behind it, then?
Nobody knows publicly. Chips and Cheese has laid out a circumstantial case for RosaicLabs, a Delaware company incorporated in May 2026 and led by former Rivos executive Amarjit Gill, which Reuters reported has been given access to Intel Atom RTL code. The dates do not line up cleanly, since the first mystery posting predates that incorporation by seven months, and the same analysis lists Zhaoxin, Hygon, the hyperscalers and the old Centaur lineage as alternatives. Treat the attribution as an open question rather than a finding.