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

From: George Dunlap <george.dunlap@citrix.com>
To: Jan Beulich <JBeulich@suse.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Feng Wu <feng.wu@intel.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Keir Fraser <keir@xen.org>, Kevin Tian <kevin.tian@intel.com>,
	xen-devel@lists.xen.org
Subject: Re: [PATCH v14 1/2] vmx: VT-d posted-interrupt core logic handling
Date: Tue, 1 Mar 2016 10:16:50 +0000	[thread overview]
Message-ID: <56D56C12.5070803@citrix.com> (raw)
In-Reply-To: <56D456C302000078000D7560@prv-mh.provo.novell.com>

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

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