On 18.12.2023 16:43, Roger Pau Monné wrote: > On Mon, Dec 18, 2023 at 02:50:27PM +0100, Jan Beulich wrote: >> On 18.12.2023 14:46, Jan Beulich wrote: >>> On 18.12.2023 13:11, Roger Pau Monné wrote: >>>> Hello, >>>> >>>> I'm not as expert as Andrew in all the speculation stuff, but I will >>>> try to provide some feedback. >>>> >>>> On Tue, Feb 14, 2023 at 05:10:42PM +0100, Jan Beulich wrote: >>>>> In order to be able to defer the context switch IBPB to the last >>>>> possible point, add logic to the exit-to-guest paths to issue the >>>>> barrier there, including the "IBPB doesn't flush the RSB/RAS" >>>>> workaround. Since alternatives, for now at least, can't nest, emit JMP >>>>> to skip past both constructs where both are needed. This may be more >>>>> efficient anyway, as the sequence of NOPs is pretty long. >>>> >>>> Could you elaborate on the reason why deferring the IBPB to the exit >>>> to guest path is helpful? So far it just seem to make the logic more >>>> complex without nay justification (at least in the changelog). >>> >>> I've added "(to leave behind as little as possible)" ahead of the 1st >>> comma - is that sufficient, do you think? >> >> Actually, the next patch supplies better context, i.e. is more / also >> about avoiding to clobber Xen's own predictions. > > Right, that I got from next patch, but given context switch is already > a quite heavy operation, does avoiding the cleaning of the branch > predictor make that much of a difference? > > IMO it needs good justification given it's a change that makes the > logic harder to follow, so if it turns out there's no difference I > would rather leave the IBPB at context switch.
As per another reply, I guess we want to discuss this with Andrew, so maybe a good thing to try to remember to put up on the next x86 meeting we're going to have. Jan
