> -----Original Message----- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Friday, May 27, 2016 10:00 PM > To: Wu, Feng <feng...@intel.com> > Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com; > george.dun...@eu.citrix.com; Tian, Kevin <kevin.t...@intel.com>; xen- > de...@lists.xen.org; konrad.w...@oracle.com; k...@xen.org > Subject: Re: [PATCH v2 3/4] VMX: Assign the right value to 'NDST' field in a > concern case > > >>> On 26.05.16 at 15:39, <feng...@intel.com> wrote: > > Normally, in vmx_cpu_block() 'NDST' filed should have the same > > value with 'dest' or 'MASK_INSR(dest, PI_xAPIC_NDST_MASK)' depending > > on whether x2apic is enabled. However, in the following scenario, > > 'NDST' has different value: > > > > 'vcpu_block' hook gets assigned in vmx_pi_hooks_assign(), but all > > other three PI hooks have not been assigned or not been excuted yet. > > And during this interval, we are running in vmx_vcpu_block(), then > > 'NDST' may have different value. > > How about simply assigning vcpu_block last? Or alternatively > holding pi_blocking_list_lock around all four assignments? Or > (maybe in addition to one of these) writing something sensible in > vmx_pi_hooks_assign() before doing the hook assignments?
The problem is vmx_vcpu_block() can still get called first, since the other ones might not get called yet. > Of course much depends on whether the ASSERT() you replace was > meant just as a sanity check, or instead logic elsewhere relies on > NDST having the right value already before getting into > vmx_vcpu_block(). The point is we need to make sure NDST have the right value after leaving vmx_vcpu_block(). > > Also, rather than saying twice that NDST has a different value in > that case, how about stating what exact value it has then and > why that's not what we want/need? (Same goes for the code > comment then.) Sure, will add this in the next version. > > > This patch fix this concern case. > > Here as well as in earlier patches - do you perhaps mean "corner > case"? Sorry for the typo. Thanks, Feng > > Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
