From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
"JBeulich@suse.com" <JBeulich@suse.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH v10 09/11] x86/ctxt: Issue a speculation barrier between vcpu contexts
Date: Thu, 25 Jan 2018 09:46:27 -0500 [thread overview]
Message-ID: <20180125144627.GC25449@char.us.oracle.com> (raw)
In-Reply-To: <1516804280.13558.140.camel@infradead.org>
On Wed, Jan 24, 2018 at 02:31:20PM +0000, David Woodhouse wrote:
> On Wed, 2018-01-24 at 13:49 +0000, Andrew Cooper wrote:
> > On 24/01/18 13:34, Woodhouse, David wrote:
> > > I am loath to suggest *more* tweakables, but given the IBPB cost is
> > > there any merit in having a mode which does it only if the *domain* is
> > > different, regardless of vcpu_id?
> >
> > This would only be a win if you were regularly cross-scheduling vcpus
> > from the same domain, which case you've probably other issues to be
> > worried about.
>
> Of course. If the guest *knows* about HT siblings that kind of implies
> you've told it about the topology and thus you're pinning vCPU. I don't
> think there *is* a world in which what I said makes sense.
You can expose vNUMA and topology in the guest (and pin the vCPUS) so that
it will be not moving at all.
>
> > >
> > > If a given domain is running on HT siblings, it ought to be doing its
> > > own mitigation — setting STIBP for userspace if it wants, ensuring its
> > > own kernel is safe by having IBRS set or using retpoline, etc.
> > ~Andrew
> >
> > [1] Is this trying to be a subtle hint?
>
> Heh, no. When I get to that bit, and the *reasons* we do that, it'll be
> far from subtle. But as with so many other things, NOT THIS WEEK :)
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2018-01-25 14:46 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-24 13:12 [PATCH v10 00/11] x86: Mitigations for SP2/CVE-2017-5715/Branch Target Injection Andrew Cooper
2018-01-24 13:12 ` [PATCH v10 01/11] x86/cpuid: Handling of IBRS/IBPB, STIBP and IBRS for guests Andrew Cooper
2018-02-01 9:06 ` Jan Beulich
2018-02-01 13:53 ` Andrew Cooper
2018-01-24 13:12 ` [PATCH v10 02/11] x86/msr: Emulation of MSR_{SPEC_CTRL, PRED_CMD} " Andrew Cooper
2018-01-25 12:25 ` Jan Beulich
2018-01-24 13:12 ` [PATCH v10 03/11] x86/migrate: Move MSR_SPEC_CTRL on migrate Andrew Cooper
2018-01-24 13:12 ` [PATCH v10 04/11] x86/hvm: Permit guests direct access to MSR_{SPEC_CTRL, PRED_CMD} Andrew Cooper
2018-01-24 13:12 ` [PATCH v10 05/11] x86/entry: Organise the use of MSR_SPEC_CTRL at each entry/exit point Andrew Cooper
2018-01-25 13:08 ` Jan Beulich
2018-01-25 14:12 ` Andrew Cooper
2018-01-25 14:36 ` Jan Beulich
2018-01-25 14:46 ` Andrew Cooper
2018-01-25 15:08 ` Jan Beulich
2018-01-25 15:10 ` Andrew Cooper
2018-01-25 16:52 ` [PATCH v11 5/11] " Andrew Cooper
2018-01-24 13:12 ` [PATCH v10 06/11] x86/entry: Organise the clobbering of the RSB/RAS on entry to Xen Andrew Cooper
2018-01-25 13:19 ` Jan Beulich
2018-01-25 14:17 ` Andrew Cooper
2018-01-25 14:40 ` Jan Beulich
2018-01-25 14:44 ` Andrew Cooper
2018-01-25 14:48 ` Jan Beulich
2018-01-25 16:54 ` [PATCH v11 6/11] " Andrew Cooper
2018-01-26 12:17 ` Jan Beulich
2018-01-24 13:12 ` [PATCH v10 07/11] x86/entry: Avoid using alternatives in NMI/#MC paths Andrew Cooper
2018-01-25 13:43 ` Jan Beulich
2018-01-25 15:04 ` Andrew Cooper
2018-01-25 15:14 ` Jan Beulich
2018-01-25 15:19 ` Andrew Cooper
2018-01-25 16:17 ` Jan Beulich
2018-01-25 17:21 ` [PATCH v11 7/11] " Andrew Cooper
2018-01-26 12:23 ` Jan Beulich
2018-01-26 12:28 ` Andrew Cooper
2018-01-24 13:12 ` [PATCH v10 08/11] x86/boot: Calculate the most appropriate BTI mitigation to use Andrew Cooper
2018-01-25 13:52 ` Jan Beulich
2018-02-01 8:41 ` Jan Beulich
2018-02-01 13:58 ` Andrew Cooper
2018-01-24 13:12 ` [PATCH v10 09/11] x86/ctxt: Issue a speculation barrier between vcpu contexts Andrew Cooper
2018-01-24 13:34 ` Woodhouse, David
2018-01-24 13:49 ` Andrew Cooper
2018-01-24 14:31 ` David Woodhouse
2018-01-25 14:46 ` Konrad Rzeszutek Wilk [this message]
2018-01-25 15:57 ` Jan Beulich
2018-01-25 16:09 ` Andrew Cooper
2018-01-25 16:15 ` Andrew Cooper
2018-01-27 1:27 ` Dario Faggioli
2018-01-29 9:28 ` Jan Beulich
2018-02-05 11:37 ` George Dunlap
2018-01-25 16:31 ` Jan Beulich
2018-01-25 16:48 ` Andrew Cooper
2018-01-25 18:49 ` Dario Faggioli
2018-01-26 1:08 ` Dario Faggioli
2018-01-26 9:43 ` Jan Beulich
2018-01-26 11:13 ` Dario Faggioli
2018-01-26 11:38 ` Jan Beulich
2018-01-24 13:12 ` [PATCH v10 10/11] x86/cpuid: Offer Indirect Branch Controls to guests Andrew Cooper
2018-01-24 13:12 ` [PATCH v10 11/11] x86/idle: Clear SPEC_CTRL while idle 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=20180125144627.GC25449@char.us.oracle.com \
--to=konrad.wilk@oracle.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=dwmw2@infradead.org \
--cc=xen-devel@lists.xen.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.