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=-8.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham 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 838F6C432C1 for ; Tue, 24 Sep 2019 10:49:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 55148214D9 for ; Tue, 24 Sep 2019 10:49:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1569322169; bh=gZYHKAGmYDXsjbhZqHWfmBjKyhguVRJpJsoIUkKKxMw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:List-ID:From; b=1EX6/UBhAIrYMhTHbL3DsUt90+WCb7hSDEBiFE3Ct5J/lxL2A85YoV+mjiRhaDMyI 43kOrDqEpJUK5eAvbbST5kD37UBJtv97PkahQV0TEeCUekDORsKYdROXuTIf08uOSX GIPOXtvs59lXpGp+W4xxBsgTjJlI71LmN63yM6jw= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2504438AbfIXKt2 (ORCPT ); Tue, 24 Sep 2019 06:49:28 -0400 Received: from foss.arm.com ([217.140.110.172]:57384 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2405537AbfIXKt2 (ORCPT ); Tue, 24 Sep 2019 06:49:28 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 76DF4142F; Tue, 24 Sep 2019 03:49:27 -0700 (PDT) Received: from [10.1.197.61] (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 056113F67D; Tue, 24 Sep 2019 03:49:25 -0700 (PDT) Subject: Re: [PATCH 04/35] irqchip/gic-v3: Detect GICv4.1 supporting RVPEID To: Andrew Murray Cc: kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org, Eric Auger , James Morse , Julien Thierry , Suzuki K Poulose , Thomas Gleixner , Jason Cooper , Lorenzo Pieralisi References: <20190923182606.32100-1-maz@kernel.org> <20190923182606.32100-5-maz@kernel.org> <20190924102413.GN9720@e119886-lin.cambridge.arm.com> From: Marc Zyngier Organization: Approximate Message-ID: Date: Tue, 24 Sep 2019 11:49:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20190924102413.GN9720@e119886-lin.cambridge.arm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 24/09/2019 11:24, Andrew Murray wrote: > On Mon, Sep 23, 2019 at 07:25:35PM +0100, Marc Zyngier wrote: >> GICv4.1 supports the RVPEID ("Residency per vPE ID"), which allows for >> a much efficient way of making virtual CPUs resident (to allow direct >> injection of interrupts). >> >> The functionnality needs to be discovered on each and every redistributor >> in the system, and disabled if the settings are inconsistent. >> >> Signed-off-by: Marc Zyngier >> --- >> drivers/irqchip/irq-gic-v3.c | 21 ++++++++++++++++++--- >> include/linux/irqchip/arm-gic-v3.h | 2 ++ >> 2 files changed, 20 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c >> index 422664ac5f53..0b545e2c3498 100644 >> --- a/drivers/irqchip/irq-gic-v3.c >> +++ b/drivers/irqchip/irq-gic-v3.c >> @@ -849,8 +849,21 @@ static int __gic_update_rdist_properties(struct redist_region *region, >> void __iomem *ptr) >> { >> u64 typer = gic_read_typer(ptr + GICR_TYPER); >> + >> gic_data.rdists.has_vlpis &= !!(typer & GICR_TYPER_VLPIS); >> - gic_data.rdists.has_direct_lpi &= !!(typer & GICR_TYPER_DirectLPIS); >> + >> + /* RVPEID implies some form of DirectLPI, no matter what the doc says... :-/ */ > > I think the doc says, RVPEID is *always* 1 for GICv4.1 (and presumably beyond) > and when RVPEID==1 then DirectLPI is *always* 0 - but that's OK because for > GICv4.1 support for direct LPIs is mandatory. Well, v4.1 support for DirectLPI is pretty patchy. It has just enough features to make it useful. > >> + gic_data.rdists.has_rvpeid &= !!(typer & GICR_TYPER_RVPEID); >> + gic_data.rdists.has_direct_lpi &= (!!(typer & GICR_TYPER_DirectLPIS) | >> + gic_data.rdists.has_rvpeid); >> + >> + /* Detect non-sensical configurations */ >> + if (WARN_ON_ONCE(gic_data.rdists.has_rvpeid && !gic_data.rdists.has_vlpis)) { > > How feasible is the following suitation? All the redistributors in the system has > vlpis=0, and only the first redistributor has rvpeid=1 (with the remaining ones > rvpeid=0).If we evaluate this WARN_ON_ONCE on each call to > __gic_update_rdist_properties we end up without direct LPI support, however if we > evaluated this after iterating through all the redistributors then we'd end up > with direct LPI support and a non-essential WARN. > > Should we do the WARN after iterating through all the redistributors once we > know what the final values of these flags will be, perhaps in > gic_update_rdist_properties? What does it gains us? The moment we've detected any inconsistency, any use of DirectLPI or VLPIs is a big nono, because the redistributors care not designed to communicate with each other, and we might as well do that early. Frankly, the HW should have stayed in someone's lab. The only reason I have that code in is to detect the FVP model being misconfigured, which is pretty easy to do. M. -- Jazz is not dead, it just smells funny...