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

[Yang Zhang <yang.zhang.wz@gmail.com>]

On 2016/1/25 21:59, rkrcmar@redhat.com wrote:
> 2016-01-25 09:49+0800, Yang Zhang:
>> On 2016/1/22 21:31, rkrcmar@redhat.com wrote:
>>> 2016-01-22 10:03+0800, Yang Zhang:
>>>> 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.
>>
>> It is still handled in host context not guest context. The wakeup event
>> cannot be consumed like posted event.
>
> Ok.  ("when one of destination vcpu handles it" confused me into
> thinking that you'd like to handle it with the notification vector.)

Sorry for my poor english. :(

>
>>                                        So it relies on hypervisor to inject
>> the interrupt to guest. We can add the check at this point.
>
> Yes, but I don't think we want to do that, because of following
> drawbacks:
>
>>> - 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.
>
> (should have been "remapped, but non-posted".)
>
>>>    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.
>
> (imprecise -- we would always have to check for ON bit of all PIDs from
>   blocked VCPUs, for the original meaning of wakeup vector, and always

This is what KVM does currently.

>   either read the PIRR or check for ON bit of all PIDs that encode
>   multicast interrupts;  then we have to clear ON bits for multicasts.)

Also, most part of work is covered by current logic except checking the 
multicast.

>
>
> ---
> There might be a benefit of using posted interrupts for host interrupts
> when we run out of free interrupt vectors:  we could start using vectors
> by multiple sources through posted interrupts, if using posted

Do you mean per vcpu posted interrupts?

> interrupts is the fastest way to distinguish the interrupt source.

-- 
best regards
yang