>>> On 13.03.17 at 03:36, <yi.y....@linux.intel.com> wrote: > On 17-03-10 02:09:55, Jan Beulich wrote: >> >>> On 10.03.17 at 03:54, <yi.y....@linux.intel.com> wrote: >> > On 17-03-08 09:07:10, Jan Beulich wrote: >> >> >>> On 15.02.17 at 09:49, <yi.y....@linux.intel.com> wrote: >> >> > + ref[old_cos]--; >> >> > + spin_unlock(&info->ref_lock); >> >> > + >> >> > + /* >> >> > + * Step 6: >> >> > + * Save the COS ID into current domain's psr_cos_ids[] so that we >> >> > can know >> >> > + * which COS the domain is using on the socket. One domain can >> >> > only use >> >> > + * one COS ID at same time on each socket. >> >> > + */ >> >> > + d->arch.psr_cos_ids[socket] = cos; >> >> >> >> So the domain has not been paused, i.e. some of its vCPU-s may >> >> be running on other pCPU-s (including ones on the socket in >> >> question). How come it is safe to update this value here? >> >> >> > This is a domctl operation. It is protected by domctl_lock which is locked >> > in >> > do_domctl(). >> >> But that lock doesn't keep the subject domain's vCPU-s from >> running on other pCPU-s at the same time. >> > Yes, you are right. But only 'psr_ctxt_switch_to()' can access > psr_cos_ids[socket] when psr_cos_ids[socket] is being set. > 'psr_ctxt_switch_to()' > read the cos and set it to ASSOC register. Context switch is short so that the > correct cos can be set to ASSOC register in a short time.
That's a reply you should never give: No matter how short a time window, eventually it'll be hit. A very good example of this is the VMCS race we've recently fixed (commit 2f4d2198a9), and which had been there for years until it was first observed (and after that it took another year or so until we've actually managed to figure out what's going on). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
