From mboxrd@z Thu Jan 1 00:00:00 1970 From: "rkrcmar@redhat.com" Subject: Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination Date: Fri, 22 Jan 2016 14:31:45 +0100 Message-ID: <20160122133144.GE17514@potion.brq.redhat.com> References: <56A051C7.4030004@gmail.com> <56A065B3.4020202@gmail.com> <56A06E3A.7050804@gmail.com> <56A0703D.3060701@gmail.com> <20160121163545.GA17514@potion.brq.redhat.com> <56A18DE4.80808@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Wu, Feng" , "pbonzini@redhat.com" , "linux-kernel@vger.kernel.org" , "kvm@vger.kernel.org" To: Yang Zhang Return-path: Content-Disposition: inline In-Reply-To: <56A18DE4.80808@gmail.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org 2016-01-22 10:03+0800, Yang Zhang: > On 2016/1/22 0:35, rkrcmar@redhat.com wrote: >>2016-01-21 13:44+0800, Yang Zhang: >>>On 2016/1/21 13:41, Wu, Feng wrote: >>>>>From: Yang Zhang [mailto:yang.zhang.wz@gmail.com] >>>>>We may have different understanding on PI mode. My understanding is if >>>>>we set the IRTE to PI format, than the subsequent interrupt will be >>>>>handled in PI mode. multi-cast and broadcast interrupts cannot be >>>>>injected to guest directly but it doesn't mean cannot be handled in PI >>>>>mode. As i said, we can handle it in wake up vector or via other >>>>>approach.But it is much complexity. >> >>KVM has to intercept the interrupt, so we'd need to trigger a deferred >>work from the notification handler to send the multicast. >>Reusing existing PI vectors would mean slowing them down, so we should >>define a new PI notification vector just for this purpose, which would >>be confusing in /proc/interrupts anyway. >>On top of that, we'd need to define new PIRR array(s) and create unique >>PID for every IRTE, to avoid parsing those PIRR arrays as the vector is >>stored in IRTE ... it's going a bit too far, I guess. > > 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. - 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. 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.