Messages in this thread | | | Subject | Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination | From | Yang Zhang <> | Date | Tue, 26 Jan 2016 09:44:33 +0800 |
| |
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
| |