Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination

From: Yang Zhang
Date: Thu Jan 21 2016 - 21:03:37 EST

On 2016/1/22 0:35, rkrcmar@xxxxxxxxxx wrote:
2016-01-21 13:44+0800, Yang Zhang:
On 2016/1/21 13:41, Wu, Feng wrote:
From: Yang Zhang [mailto:yang.zhang.wz@xxxxxxxxx]
We may have different understanding on PI mode. My understanding is if
we set the IRTE to PI format, than the subsequent interrupt will be
handled in PI mode. multi-cast and broadcast interrupts cannot be
injected to guest directly but it doesn't mean cannot be handled in PI
mode. As i said, we can handle it in wake up vector or via other
approach.But it is much complexity.

KVM has to intercept the interrupt, so we'd need to trigger a deferred
work from the notification handler to send the multicast.
Reusing existing PI vectors would mean slowing them down, so we should
define a new PI notification vector just for this purpose, which would
be confusing in /proc/interrupts anyway.
On top of that, we'd need to define new PIRR array(s) and create unique
PID for every IRTE, to avoid parsing those PIRR arrays as the vector is
stored in IRTE ... it's going a bit too far, I guess.

Not so complicated. We can reuse the wake up vector and check whether the interrupt is multicast when one of destination vcpu handles it. If it is multicast, then also notifies other vcpus. It is totally handed in PI mode and we already have the wakeup vector in /proc/interrupts.

For the multicast/broastcast, we cannot set the related IRTE in PI
mode, since we cannot set only one destination in IRTE. If an interrupt
is for multiple destination, how can you use VT-d PI to injection it
to all the destinations?

You may still not get my point. Anyway, it doesn't matter. Rollback to
legacy mode still is the best choice so far.

I think we can't do much better than we do now.

best regards