From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yang Zhang Subject: Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination Date: Tue, 26 Jan 2016 09:44:33 +0800 Message-ID: <56A6CF81.9070008@gmail.com> References: <56A065B3.4020202@gmail.com> <56A06E3A.7050804@gmail.com> <56A0703D.3060701@gmail.com> <20160121163545.GA17514@potion.brq.redhat.com> <56A18DE4.80808@gmail.com> <20160122133144.GE17514@potion.brq.redhat.com> <56A57F41.90108@gmail.com> <20160125135928.GA21252@potion.brq.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "Wu, Feng" , "pbonzini@redhat.com" , "linux-kernel@vger.kernel.org" , "kvm@vger.kernel.org" To: "rkrcmar@redhat.com" Return-path: In-Reply-To: <20160125135928.GA21252@potion.brq.redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org 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