From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>
Subject: Re: [PATCH v4 1/4] x86/spec-ctrl: add logic to issue IBPB on exit to guest
Date: Mon, 18 Dec 2023 16:43:08 +0100 [thread overview]
Message-ID: <ZYBojHyqUeB9FWmh@macbook> (raw)
In-Reply-To: <2f6367bd-d63d-435f-8d6e-553d5e129eb5@suse.com>
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.
Thanks, Roger.
next prev parent reply other threads:[~2023-12-18 15:43 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-14 16:09 [PATCH v4 0/4 + v1 0/1] x86/spec-ctrl: IBPB improvements Jan Beulich
2023-02-14 16:10 ` [PATCH v4 1/4] x86/spec-ctrl: add logic to issue IBPB on exit to guest Jan Beulich
2023-12-18 12:11 ` Roger Pau Monné
2023-12-18 13:46 ` Jan Beulich
2023-12-18 13:50 ` Jan Beulich
2023-12-18 15:43 ` Roger Pau Monné [this message]
2023-12-18 16:02 ` Jan Beulich
2023-12-18 13:54 ` Jan Beulich
2023-12-18 15:40 ` Roger Pau Monné
2023-12-18 16:00 ` Jan Beulich
2023-02-14 16:11 ` [PATCH v4 2/4] x86/spec-ctrl: defer context-switch IBPB until guest entry Jan Beulich
2023-12-18 12:39 ` Roger Pau Monné
2023-12-18 13:58 ` Jan Beulich
2023-12-18 17:27 ` Roger Pau Monné
2023-02-14 16:11 ` [PATCH v4 3/4] x86: limit issuing of IBPB during context switch Jan Beulich
2023-12-18 15:19 ` Roger Pau Monné
2023-12-18 16:09 ` Jan Beulich
2023-12-18 16:11 ` Jan Beulich
2023-02-14 16:12 ` [PATCH v4 4/4] x86/PV: issue branch prediction barrier when switching 64-bit guest to kernel mode Jan Beulich
2023-12-18 17:24 ` Roger Pau Monné
2023-12-19 9:56 ` Jan Beulich
2023-12-19 11:48 ` Roger Pau Monné
2023-12-19 14:06 ` Jan Beulich
2023-12-19 15:11 ` Roger Pau Monné
2023-12-19 17:07 ` Roger Pau Monné
2023-12-20 9:25 ` Jan Beulich
2023-12-20 9:59 ` Roger Pau Monné
2023-02-14 16:13 ` [PATCH] x86/Xen: make use of IBPB controlling VM assist Jan Beulich
2023-02-14 23:53 ` Boris Ostrovsky
2023-02-15 0:07 ` Boris Ostrovsky
2023-02-15 8:31 ` Jan Beulich
2023-02-15 23:22 ` Boris Ostrovsky
2023-02-16 7:33 ` Jan Beulich
2023-03-17 13:56 ` Juergen Gross
2023-03-17 14:21 ` Andrew Cooper
2023-03-17 14:28 ` Juergen Gross
2023-03-20 10:21 ` Jan Beulich
2023-03-20 10:19 ` Jan Beulich
2023-03-20 13:02 ` Juergen Gross
2023-03-20 13:17 ` Jan Beulich
2023-03-20 13:35 ` Juergen Gross
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZYBojHyqUeB9FWmh@macbook \
--to=roger.pau@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=jbeulich@suse.com \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.