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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
