Re: [Xen-devel] [PATCH v14 1/2] vmx: VT-d posted-interrupt core logic handling

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 29/02/16 13:33, Jan Beulich wrote:
>>>> On 29.02.16 at 04:00, <feng.wu@xxxxxxxxx> 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 <keir@xxxxxxx>
>> CC: Jan Beulich <jbeulich@xxxxxxxx>
>> CC: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>> CC: Kevin Tian <kevin.tian@xxxxxxxxx>
>> CC: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
>> CC: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
>> Suggested-by: Yang Zhang <yang.z.zhang@xxxxxxxxx>
>> Suggested-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
>> Suggested-by: George Dunlap <george.dunlap@xxxxxxxxxx>
>> Suggested-by: Jan Beulich <jbeulich@xxxxxxxx>
>> Signed-off-by: Feng Wu <feng.wu@xxxxxxxxx>
>> Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxx>
> 
> 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 <jbeulich@xxxxxxxx>
> 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.dunlap@xxxxxxxxxx>


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel