On 29/02/16 13:33, Jan Beulich wrote: >>>> On 29.02.16 at 04:00, <feng...@intel.com> wrote: >> This is the core logic handling for VT-d posted-interrupts. Basically it >> deals with how and when to update posted-interrupts during the following >> scenarios: >> - vCPU is preempted >> - vCPU is slept >> - vCPU is blocked >> >> When vCPU is preempted/slept, we update the posted-interrupts during >> scheduling by introducing two new architecutral scheduler hooks: >> vmx_pi_switch_from() and vmx_pi_switch_to(). When vCPU is blocked, we >> introduce a new architectural hook: arch_vcpu_block() to update >> posted-interrupts descriptor. >> >> Besides that, before VM-entry, we will make sure the 'NV' filed is set >> to 'posted_intr_vector' and the vCPU is not in any blocking lists, which >> is needed when vCPU is running in non-root mode. The reason we do this check >> is because we change the posted-interrupts descriptor in vcpu_block(), >> however, we don't change it back in vcpu_unblock() or when vcpu_block() >> directly returns due to event delivery (in fact, we don't need to do it >> in the two places, that is why we do it before VM-Entry). >> >> When we handle the lazy context switch for the following two scenarios: >> - Preempted by a tasklet, which uses in an idle context. >> - the prev vcpu is in offline and no new available vcpus in run queue. >> We don't change the 'SN' bit in posted-interrupt descriptor, this >> may incur spurious PI notification events, but since PI notification >> event is only sent when 'ON' is clear, and once the PI notificatoin >> is sent, ON is set by hardware, hence no more notification events >> before 'ON' is clear. Besides that, spurious PI notification events are >> going to happen from time to time in Xen hypervisor, such as, when >> guests trap to Xen and PI notification event happens, there is >> nothing Xen actually needs to do about it, the interrupts will be >> delivered to guest atht the next time we do a VMENTRY. >> >> CC: Keir Fraser <k...@xen.org> >> CC: Jan Beulich <jbeul...@suse.com> >> CC: Andrew Cooper <andrew.coop...@citrix.com> >> CC: Kevin Tian <kevin.t...@intel.com> >> CC: George Dunlap <george.dun...@eu.citrix.com> >> CC: Dario Faggioli <dario.faggi...@citrix.com> >> Suggested-by: Yang Zhang <yang.z.zh...@intel.com> >> Suggested-by: Dario Faggioli <dario.faggi...@citrix.com> >> Suggested-by: George Dunlap <george.dun...@citrix.com> >> Suggested-by: Jan Beulich <jbeul...@suse.com> >> Signed-off-by: Feng Wu <feng...@intel.com> >> Reviewed-by: George Dunlap <george.dun...@citrix.com> > > With the comments George gave on v13 subsequent to this tag > I'm not sure it was correct to retain it. George? > > Reviewed-by: Jan Beulich <jbeul...@suse.com> > albeit in case another version is needed ...
It probably wasn't correct to retain the Reviewed-by given my outstanding comments about the macro. But having looked at it again: Reviewed-by: George Dunlap <george.dun...@citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
