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

["rkrcmar@redhat.com" <rkrcmar@redhat.com>]

2016-01-22 10:03+0800, Yang Zhang:
> On 2016/1/22 0:35, rkrcmar@redhat.com 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@gmail.com]
>>>>>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.

I'm not sure what you mean now ... I guess it is:
- Deliver the interrupt to a guest VCPU and relay the multicast to other
  VCPUs.  No, it's strictly worse than intercepting it in the host.

- Modify host's wakeup vector handler to send the multicast.
  It's so complicated, because all information you start with in the
  host is a vector number.  You start with no idea what the multicast
  interrupt should be.

  We could add per-multicast PID to the list of parsed PIDs in
  wakeup_handler and use PID->multicast interrupt mapping to tell which
  interrupt we should send, but that seems worse than just delivering a
  non-remapped interrupt.

  Also, if wakeup vector were used for wakeup and multicast, we'd be
  uselessly doing work, because we can't tell which reason triggered the
  interrupt before finishing one part -- using separate vectors for that
  would be a bit nicer.