On Fri, 2018-01-19 at 08:07 -0700, Jan Beulich wrote: > > > > On 19.01.18 at 15:48, <andrew.coop...@citrix.com> 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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
