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

[David Woodhouse <dwmw2@xxxxxxxxxxxxx>]

On Fri, 2018-01-19 at 08:07 -0700, Jan Beulich wrote:
> > > > On 19.01.18 at 15:48, <andrew.cooper3@xxxxxxxxxx> wrote:
> > vcpu pointers are rather more susceptible to false aliasing in the case
> > that the 4k memory allocation behind struct vcpu gets reused.
> > 
> > The risks are admittedly minute, but this is a much safer option.
>
> Oh, right, I didn't consider the case of the vCPU (and domain)
> having gone away in the meantime. Mind extending the comment
> to clarify this?

I look at this and figured I didn't care about aliasing. Sure, we might
not do the IBPB if the stale pointer is aliased and we switch from a
now-dead vCPU to a new vCPU. But good luck exploiting the new vCPU from
an old domain that's now dead!

I actually thought Andrew changed from pointers just because of the
'ick' factor of keeping a known-stale pointer around and using it for
*comparison* but having to careful avoid ever *dereferencing* it (as my
debugging patch in context_switch() did... oops!)

> > David found that transitions to idle and back to the same vcpu were
> > reliably taking an unnecessary IBPB.

I'll repeat my caveat there — I observed this on our ancient Xen
4.mumble not current HEAD. But the code here looks remarkably similar;
it hasn't changed for a while.

> I understand that, but there was no explanation whatsoever as
> to why that is.

Looks like we set per_cpu(curr_vcpu)=next every time we switch, even if
we are switching to the idle domain. Which is why I added per_cpu(last)
specifically to be updated only when it *isn't* an idle vCPU.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

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