x86/apicv: fix wrong IPI suppression during posted interrupt delivery
authorQuan Xu <xuquan8@huawei.com>
Fri, 3 Mar 2017 11:00:35 +0000 (12:00 +0100)
committerJan Beulich <jbeulich@suse.com>
Fri, 3 Mar 2017 11:00:35 +0000 (12:00 +0100)
commitb151125b4d89d7ec139ac34470e3c709fb4b1b4d
tree254bbd05f73ad5976573749a621597e609bcaf11
parentca82be5f5cffc3b64e4c8d6d944b8a77bfce1a0e
x86/apicv: fix wrong IPI suppression during posted interrupt delivery

__vmx_deliver_posted_interrupt() wrongly used a softirq bit to decide whether
to suppress an IPI. Its logic was: the first time an IPI was sent, we set
the softirq bit. Next time, we would check that softirq bit before sending
another IPI. If the 1st IPI arrived at the pCPU which was in
non-root mode, the hardware would consume the IPI and sync PIR to vIRR.
During the process, no one (both hardware and software) will clear the
softirq bit. As a result, the following IPI would be wrongly suppressed.

This patch discards the suppression check, always sending an IPI.
The softirq also need to be raised. But there is a little change.
This patch moves the place where we raise a softirq for
'cpu != smp_processor_id()' case to the IPI interrupt handler.
Namely, don't raise a softirq for this case and set the interrupt handler
to pi_notification_interrupt()(in which a softirq is raised) regardless of
VT-d PI enabled or not. The only difference is when an IPI arrives at the
pCPU which is happened in non-root mode, the code will not raise a useless
softirq since the IPI is consumed by hardware rather than raise a softirq
unconditionally.

Signed-off-by: Quan Xu <xuquan8@huawei.com>
Signed-off-by: Chao Gao <chao.gao@intel.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
xen/arch/x86/hvm/vmx/vmx.c