From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753862AbcAVNb4 (ORCPT ); Fri, 22 Jan 2016 08:31:56 -0500 Received: from mx1.redhat.com ([209.132.183.28]:38561 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753405AbcAVNbs (ORCPT ); Fri, 22 Jan 2016 08:31:48 -0500 Date: Fri, 22 Jan 2016 14:31:45 +0100 From: "rkrcmar@redhat.com" To: Yang Zhang Cc: "Wu, Feng" , "pbonzini@redhat.com" , "linux-kernel@vger.kernel.org" , "kvm@vger.kernel.org" Subject: Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination 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 Content-Disposition: inline In-Reply-To: <56A18DE4.80808@gmail.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@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.