>>> On 23.05.16 at 07:48, <feng...@intel.com> wrote: >> From: Tian, Kevin >> Sent: Monday, May 23, 2016 1:19 PM >> > From: Wu, Feng >> > Sent: Friday, May 20, 2016 4:54 PM >> > --- a/xen/arch/x86/hvm/vmx/vmx.c >> > +++ b/xen/arch/x86/hvm/vmx/vmx.c >> > @@ -248,6 +248,36 @@ void vmx_pi_hooks_deassign(struct domain *d) >> > d->arch.hvm_domain.vmx.pi_switch_to = NULL; >> > } >> > >> > +static void vmx_pi_blocking_list_cleanup(struct domain *d) >> >> Is it more natural to move such cleanup under vcpu destroy? > > Yes, indeed it is more natural to add this function when vcpu is destroyed, > however, the reason I add it here is I still have some concerns about the > timing. > When the VM is destroyed, here is the calling path: > > - vmx_pi_hooks_deassign() --> > ...... > - vmx_vcpu_destroy() --> > ...... > - vmx_domain_destroy() > ...... > > As I replied in the previous mail, when we remove the vcpus from the > blocking > list, there might be some _in-flight_ call to the hooks, so I put the cleanup > code in the vmx_domain_destroy(), which is a bit more far from > vmx_pi_hooks_deassign, > and hence safer. If you have any other good ideas, I am all ears!:)
Well, either there is a possible race (then moving the addition later just reduces the chances, but doesn't eliminate it), or there isn't (in which case Kevin's suggestion should probably be followed). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
