lkml.org 
[lkml]   [2016]   [Jan]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination
From
Date
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

\
 
 \ /
  Last update: 2016-01-26 03:01    [W:0.559 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site