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

[Yang Zhang]

On 2016/1/25 21:59, rkrcmar@xxxxxxxxxx wrote:
> 2016-01-25 09:49+0800, Yang Zhang:
> > On 2016/1/22 21:31, rkrcmar@xxxxxxxxxx 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