RE: x86 WBINVD prefix allocations

> From: Christian Ludloff <[email protected]>
> Sent: Tuesday, September 1, 2026 5:54 PM
> 
> On Tue, Sep 1, 2026 at 1:32 AM Jan Beulich <[email protected]> wrote:
> > >   0x67 = no CODE hint => skip L0i/L1i cache
> > >   0x66 = no DATA hint => skip L0d/L1d cache
> > >   0xF3 = no INVD hint => skip invalidations
> > >   0xF2 = no LLC  hint => skip LLC cache
> >
> > I view (ab)use of 0x67 as an operation modifying prefix as problematic.
> 
> In an increasingly 64-bit world the classic 0x67
> functionality is becoming... much less relevant.
> 
> > >   0x26 = ES implementation-specific hint
> > >   0x2E = CS implementation-specific hint
> > >   0x36 = SS implementation-specific hint
> > >   0x3E = DS implementation-specific hint
> > >   0x64 = FS implementation-specific hint
> > >   0x65 = GS implementation-specific hint
> >
> > ... allowing combinations of these to mean anything else than "last one
> > takes effect" is pretty much against how x86 has been working. In gas
> > I think you couldn't even encode multiple of them "normally", i.e. without
> > resorting to .byte or alike.
> 
> WBINVD is privileged – so not an app problem.

I get your meaning for privileged, which means user are using them
on purpose.

Do you mean that in your scenario, you will always use .byte to skip
assembler?

And I am still expecting when the entity will be revealed, with
documentation.

Thx,
Haochen