On 05/02/14 14:54, Jan Beulich wrote: > "Base" context reads already paused the subject vCPU when being the > current one, but that special case isn't being properly dealt with > anyway (at the very least when x86's fsgsbase feature is in use), so > just disallow it. > > "Extended" context reads so far didn't do any pausing. > > While we can't avoid the reported data being stale by the time it > arrives at the caller, this way we at least guarantee that it is > consistent. > > Signed-off-by: Jan Beulich Now I come to think about it, is this an ABI change, as we are now disallowing a control domain to issue these hypercalls on itself? ~Andrew > > --- a/xen/arch/x86/domctl.c > +++ b/xen/arch/x86/domctl.c > @@ -819,7 +819,13 @@ long arch_do_domctl( > > if ( domctl->cmd == XEN_DOMCTL_get_ext_vcpucontext ) > { > + if ( v == current ) /* no vcpu_pause() */ > + break; > + > evc->size = sizeof(*evc); > + > + vcpu_pause(v); > + > if ( is_pv_domain(d) ) > { > evc->sysenter_callback_cs = > @@ -849,6 +855,7 @@ long arch_do_domctl( > evc->vmce.mci_ctl2_bank1 = v->arch.vmce.bank[1].mci_ctl2; > > ret = 0; > + vcpu_unpause(v); > copyback = 1; > } > else > --- a/xen/common/domctl.c > +++ b/xen/common/domctl.c > @@ -675,11 +675,9 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe > struct vcpu *v; > > ret = -EINVAL; > - if ( op->u.vcpucontext.vcpu >= d->max_vcpus ) > - goto getvcpucontext_out; > - > - ret = -ESRCH; > - if ( (v = d->vcpu[op->u.vcpucontext.vcpu]) == NULL ) > + if ( op->u.vcpucontext.vcpu >= d->max_vcpus || > + (v = d->vcpu[op->u.vcpucontext.vcpu]) == NULL || > + v == current ) /* no vcpu_pause() */ > goto getvcpucontext_out; > > ret = -ENODATA; > @@ -694,14 +692,12 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe > if ( (c.nat = xmalloc(struct vcpu_guest_context)) == NULL ) > goto getvcpucontext_out; > > - if ( v != current ) > - vcpu_pause(v); > + vcpu_pause(v); > > arch_get_info_guest(v, c); > ret = 0; > > - if ( v != current ) > - vcpu_unpause(v); > + vcpu_unpause(v); > > #ifdef CONFIG_COMPAT > if ( !is_pv_32on64_vcpu(v) ) > > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel