From: Andrew Cooper <Andrew.Cooper3@citrix.com>
To: Jason Andryuk <jandryuk@gmail.com>
Cc: Xen-devel <xen-devel@lists.xenproject.org>,
Jan Beulich <JBeulich@suse.com>,
Roger Pau Monne <roger.pau@citrix.com>, Wei Liu <wl@xen.org>
Subject: Re: [PATCH 2/2] x86/spec-ctrl: Reduce HVM RSB overhead where possible
Date: Thu, 11 Aug 2022 17:05:17 +0000 [thread overview]
Message-ID: <4254c2bb-6f54-a453-7ab9-9ba5b4de66e4@citrix.com> (raw)
In-Reply-To: <CAKf6xpurnYVf-xz4VcFwq3uwbqBowyWJjgP=oLVZU3kWKtEWDg@mail.gmail.com>
On 09/08/2022 21:20, Jason Andryuk wrote:
> On Tue, Aug 9, 2022 at 1:01 PM Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
>> index 17e103188a53..8a6a5cf20525 100644
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -3934,8 +3934,24 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>> {
>> unsigned long exit_qualification, exit_reason, idtv_info, intr_info = 0;
>> unsigned int vector = 0, mode;
>> - struct vcpu *v = current;
>> - struct domain *currd = v->domain;
>> + struct vcpu *v;
>> + struct domain *currd;
>> +
>> + /*
>> + * To mitigate Post-Barrier RSB speculation, we must force one CALL
>> + * instruction to retire before letting a RET instruction execute.
> I think it would be clearer if this comment mentioned LFENCE like the
> commit message does. Looking at this change without the commit
> message the connection is not obvious to me at least. Maybe "we must
> force one CALL instruction to retire (with LFENCE) before letting a
> RET instruction execute"?
While I'm sympathetic to trying to make this easier to follow, throwing
extra LFENCE's around isn't the right way forward IMO.
LFENCE *is* the basis of a lot of software mitigations, because it has
been specified by Intel and AMD to also be a dispatch barrier.
This has been covered in multiple whitepapers from both vendors, and has
been updated in the main manuals for 4 years or now now.
~Andrew
next prev parent reply other threads:[~2022-08-11 17:05 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-09 17:00 [PATCH 0/2] x86/spec-ctrl: Reduce HVM RSB overhead Andrew Cooper
2022-08-09 17:00 ` [PATCH 1/2] x86/spec-ctrl: Enumeration for PBRSB_NO Andrew Cooper
2022-08-10 7:10 ` Jan Beulich
2022-08-09 17:00 ` [PATCH 2/2] x86/spec-ctrl: Reduce HVM RSB overhead where possible Andrew Cooper
2022-08-09 20:20 ` Jason Andryuk
2022-08-11 17:05 ` Andrew Cooper [this message]
2022-08-10 8:00 ` Jan Beulich
2022-08-11 18:06 ` Andrew Cooper
2022-08-11 10:55 ` [PATCH 0/2] x86/spec-ctrl: Reduce HVM RSB overhead Andrew Cooper
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=4254c2bb-6f54-a453-7ab9-9ba5b4de66e4@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=JBeulich@suse.com \
--cc=jandryuk@gmail.com \
--cc=roger.pau@citrix.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.