>>> On 28.10.16 at 04:37, <feng...@intel.com> wrote: > PI hook vmx_pi_switch_to() is needed even when any previously > assigned device is detached from the domain. Since 'SN' bit is > also used to control the CPU side PI and we change the state of > SN bit in these two functions,
There's just one function you've mentioned up to here. > --- a/xen/arch/x86/hvm/vmx/vmx.c > +++ b/xen/arch/x86/hvm/vmx/vmx.c > @@ -221,9 +221,14 @@ void vmx_pi_hooks_deassign(struct domain *d) > ASSERT(d->arch.hvm_domain.vmx.vcpu_block); > > d->arch.hvm_domain.vmx.vcpu_block = NULL; > - d->arch.hvm_domain.vmx.pi_switch_from = NULL; > - d->arch.hvm_domain.vmx.pi_switch_to = NULL; And with the commit message as it is right now, it is completely unclear why the from hook also gets zapped. In fact, with the description pointing out a problem with just the SN=1 case, I don't see what you need the from hook for without devices assigned, as that's where SN gets set (and you want to avoid that). > d->arch.hvm_domain.vmx.pi_do_resume = NULL; > + d->arch.hvm_domain.vmx.pi_switch_from = NULL; > + > + /* > + * In fact, we can remove 'vmx_pi_switch_to' inside itself if no new > device s/can/could/ > + * is in the process of getting assigned and "from" hook is NULL. > However, > + * it is not straightforward to find a clear solution, so just leave it > here. > + */ > } > > static int vmx_domain_initialise(struct domain *d) Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel