From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965453AbcAUQfx (ORCPT ); Thu, 21 Jan 2016 11:35:53 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51822 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759178AbcAUQft (ORCPT ); Thu, 21 Jan 2016 11:35:49 -0500 Date: Thu, 21 Jan 2016 17:35:46 +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: <20160121163545.GA17514@potion.brq.redhat.com> References: <1453254177-103002-2-git-send-email-feng.wu@intel.com> <56A04B0A.2020505@gmail.com> <56A051C7.4030004@gmail.com> <56A065B3.4020202@gmail.com> <56A06E3A.7050804@gmail.com> <56A0703D.3060701@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56A0703D.3060701@gmail.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. >>For the multicast/broastcast, we cannot set the related IRTE in PI >>mode, since we cannot set only one destination in IRTE. If an interrupt >>is for multiple destination, how can you use VT-d PI to injection it >>to all the destinations? > > You may still not get my point. Anyway, it doesn't matter. Rollback to > legacy mode still is the best choice so far. I think we can't do much better than we do now.