From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-14.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9F653C48BE5 for ; Tue, 22 Jun 2021 17:19:43 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5C4BA6100B for ; Tue, 22 Jun 2021 17:19:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5C4BA6100B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Z1XbcWKbw5k5s1LSFNQPVWcsnjGiUknjztWFN0wc7Co=; b=3kVFZlHB3UUC0H CDfoDrWYOKBNqA00CHu36mvIqxWAmQg0zJkdgJFhKj9N/FU2t24j3bPpvbMkuKLvo3rJLDs5muQFt i+ws0MrA0aDLrfzWTXyyDW5TgpjKDj3Pma+LcZL/XxmrEueVORw5OQjXj0E1csy5ZiK52ESS/BRWM ToLZT/+lWL/9C+io8ckdz+X5+bTtLqzn/fdx6vX2/+glshL+/ItyBVu/GIhPxgUr/epydX5FPPAnN 8gMwJAdUQ3G/IYmRnxx+4o7Sq6qPLGrFfkwvyDm9ZOGQYUAUIEGsvBHVcewi1JW66UePqX2G5Djj5 eWnQn/No7Y+tZjQHRjJA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lvk2D-0080q3-Vb; Tue, 22 Jun 2021 17:18:02 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lvk2A-0080pa-Os for linux-arm-kernel@lists.infradead.org; Tue, 22 Jun 2021 17:18:00 +0000 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 796AA61166; Tue, 22 Jun 2021 17:17:58 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1lvk28-009Drp-FA; Tue, 22 Jun 2021 18:17:56 +0100 Date: Tue, 22 Jun 2021 18:17:55 +0100 Message-ID: <87tulpbyyk.wl-maz@kernel.org> From: Marc Zyngier To: Boqun Feng Cc: Thomas Gleixner , linux-kernel@vger.kernel.org, Arnd Bergmann , Bjorn Helgaas , Linux ARM , Catalin Marinas , Will Deacon , Sunil Muthuswamy Subject: Re: [RFC 2/2] irqchip/gic-v3-its: Introduce virtual ITS In-Reply-To: <20210622155313.3819952-3-boqun.feng@gmail.com> References: <20210622155313.3819952-1-boqun.feng@gmail.com> <20210622155313.3819952-3-boqun.feng@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: boqun.feng@gmail.com, tglx@linutronix.de, linux-kernel@vger.kernel.org, arnd@arndb.de, bhelgaas@google.com, linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com, will@kernel.org, sunilmut@microsoft.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210622_101758_890445_1F2C9755 X-CRM114-Status: GOOD ( 39.33 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, 22 Jun 2021 16:53:13 +0100, Boqun Feng wrote: > > GICv3 allows supporting LPI without an ITS, and in order to support > such a platform, a virtual ITS is introduced. The virtual ITS has the > same software part as a real ITS: having an irq domain, maintaining > ->collections and maintaining the list of devices. The only difference > is the virtual ITS doesn't have a backed ITS therefore it cannot issue > ITS commands nor set up device tables. The virtual ITS only manages LPIs > and the LPIs are configured via DirectLPI interfaces. That's not a virtual ITS. Not at all. It isn't even the shadow of an ITS. This is... something else. > > And currently the virtual ITS is initialized only if there is no ITS in > the system and yet DirectLPI is support. > > The virtual ITS approach provides the support for LPI without an ITS and > reuses as much exisiting code as possible, and is the preparation for > virtual PCI support on ARM64 Hyper-V guests. There is no translation, no isolation. This is a yet another sorry excuse for a hack. Why can't the Hyper-V folks implement the architecture, only the architecture, and all of it? > > Co-developed-by: Sunil Muthuswamy > Signed-off-by: Boqun Feng > --- > drivers/irqchip/irq-gic-v3-its.c | 114 ++++++++++++++++++++++++++++--- > 1 file changed, 106 insertions(+), 8 deletions(-) > > diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c > index 1916ac5d6371..4f2600377039 100644 > --- a/drivers/irqchip/irq-gic-v3-its.c > +++ b/drivers/irqchip/irq-gic-v3-its.c > @@ -117,9 +117,16 @@ struct its_node { > int vlpi_redist_offset; > }; > > +/* > + * LPI can be supported without ITS, in which case, a virtual its_node is > + * initialized to allow configuring LPI with the DirectLPI approach. > + */ > +static struct its_node *virtual_its_node; > + > #define is_v4(its) (!!((its)->typer & GITS_TYPER_VLPIS)) > #define is_v4_1(its) (!!((its)->typer & GITS_TYPER_VMAPP)) > #define device_ids(its) (FIELD_GET(GITS_TYPER_DEVBITS, (its)->typer) + 1) > +#define is_virtual(its) ((its) == virtual_its_node) And you can only have one? > > #define ITS_ITT_ALIGN SZ_256 > > @@ -1096,6 +1103,10 @@ void name(struct its_node *its, \ > unsigned long flags; \ > u64 rd_idx; \ > \ > + /* Virtual ITS doesn't support ITS commands */ \ > + if (is_virtual(its)) \ > + return; \ > + \ Oh gawd... > raw_spin_lock_irqsave(&its->lock, flags); \ > \ > cmd = its_allocate_entry(its); \ > @@ -1464,7 +1475,8 @@ static void lpi_update_config(struct irq_data *d, u8 clr, u8 set) > > lpi_write_config(d, clr, set); > if (gic_rdists->has_direct_lpi && > - (is_v4_1(its_dev->its) || !irqd_is_forwarded_to_vcpu(d))) > + (is_v4_1(its_dev->its) || !irqd_is_forwarded_to_vcpu(d) || > + is_virtual(its_dev->its))) > direct_lpi_inv(d); > else if (!irqd_is_forwarded_to_vcpu(d)) > its_send_inv(its_dev, its_get_event_id(d)); > @@ -1690,6 +1702,10 @@ static void its_irq_compose_msi_msg(struct irq_data *d, struct msi_msg *msg) > u64 addr; > > its = its_dev->its; > + > + /* Virtual ITS doesn't have ->get_msi_base function, skip */ > + if (!its->get_msi_base) > + return; So how do you target a redistributor? If you are going to use DirectLPI, this should hit the GICR_SETLPIR for the relevant redistributor. Actually, how do you target another redistributor? You can't send a MOVI, and you don't change the target address. And even if you could, how do you move the pending state from one pending table to another? Which means you probably have some other, non architectural stuff somewhere else. [...] I'll stop here. I'm not taking this hack built on top of the ITS code. Not now, not ever. If you really want to implement something that is outside of the scope of the architecture, do it outside of the GICv3 code, because this is just pretending to follow the architecture. Or even better, get the Hyper-V folks to implement a *real* virtual ITS, in the hypervisor. Yes, this is hard. M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel