Fwd: master now has full ibrs and ibpb support - notes

[Matthew Dillon]

I think the debian microcode is for EPYC, not Ryzen.

The Redhat ibpb implementation is in the HVM path.  IBPB must be used in
vmexit and other transfer points because IBRS is not sufficient in those
situations.  I'm assuming that is what redhat is doing there, and that they
aren't issuing it in the user->kernel mode path.  Though their
documentation seems to imply that they are doing it in both paths.  But I'm
pretty sure IBPB doesn't help in the user->kernel path if IBRS is enabled.
Also note that the linux code is changing daily.  Even the Intel engineers
got confused on LKML.  But I will keep tabs on the conversation in case
things change.

For AMD, AMD chipsets with microcode updates can operate with IBRS=0 IBPB=2
(IBPB=2 just means IBRS is disabled and IBPB is used instead, in linux
land).   Some AMD chipsets *WITHOUT* microcode updtes can apparently
already do IBRS and IBPB, but without the microcode update both have to be
enabled and performance is lower.  In this situation, IBRS mode 2 is used
(leave IBRS turned on) and IBPB is used as the barrier.

There was a lot of confusion on how IBRS was supposed to operate in the
Linux community. IBPB is a barrier.  IBRS was a mode setting, but Intel
clarified that IBRS is *ALSO* a barrier so when it is enabled (even in mode
2), user->kernel transitions still have to issue a wrmsr to IBRS (even
though its already set to 1).  It is unclear whether this is also true for
AMD's IBSR mode but I suspect it isn't since the older AMD chips still use
the IBPB barrier with IBRS already enabled.

But remember, the linux code is changing daily.  It's a chaotic mess.  I'll
keep tabs on it.

-Matt

>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20180110/ab04b8b9/attachment-0002.html>