Re: [Xen-devel] [PATCH v10 09/11] x86/ctxt: Issue a speculation barrier between vcpu contexts

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxx
> https://lists.xenproject.org/mailman/listinfo/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel