Re: [Xen-devel] [PATCH v8 15/17] x86/ctxt: Issue a speculation barrier between vcpu contexts

[David Woodhouse <dwmw2@xxxxxxxxxxxxx>]

On Mon, 2018-01-15 at 22:39 +0100, David Woodhouse wrote:
> On Mon, 2018-01-15 at 14:23 +0100, David Woodhouse wrote:
> > 
> > 
> > > 
> > > > 
> > > >  
> > > > Also... if you're doing that in context_switch() does it do the right
> > > > thing with idle? If a CPU switches to the idle domain and then back
> > > > again to the same vCPU, does that do the IBPB twice?
> > >
> > > Context switches to idle will skip the IBPB because it isn't needed, but
> > > any switch to non-idle need it.  In your example, we should execute just
> > > a single IBPB.
>
> > In my example I think we should not execute IBPB at all. We come from a
> > given VMCS, sleep for a while, and go back to it. No need for any
> > flushing whatsoever.
>
> msw points out that in my example we *don't* execute IBPB at all, I
> think.
> 
> In both switching to idle, and back to the vCPU, we should hit this
> case and not the 'else' case that does the IBPB:
> 
> 1710     if ( (per_cpu(curr_vcpu, cpu) == next) ||
> 1711          (is_idle_domain(nextd) && cpu_online(cpu)) )
> 1712     {
> 1713         local_irq_enable();
> 1714     }

I tested that; it doesn't seem to be the case. We end up here with prev
being the idle thread, next being the actual vCPU, and
per_cpu(curr_vcpu, cpu) being the idle thread too. So we still do the
IBPB even when we've just switch from a given vCPU to idle and back
again.

That's not actually tested on Xen master, but the code here looks very
much the same as what I actually did test.

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

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