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=-0.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no 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 4FA61C2B9F4 for ; Tue, 15 Jun 2021 02:24:40 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (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 BEF3F613F5 for ; Tue, 15 Jun 2021 02:24:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BEF3F613F5 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:59452 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lsykp-0007XK-0C for qemu-devel@archiver.kernel.org; Mon, 14 Jun 2021 22:24:39 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45352) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lsyk6-0005om-WD for qemu-devel@nongnu.org; Mon, 14 Jun 2021 22:23:55 -0400 Received: from mail-qv1-xf33.google.com ([2607:f8b0:4864:20::f33]:33535) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lsyk4-0000y0-Q8 for qemu-devel@nongnu.org; Mon, 14 Jun 2021 22:23:54 -0400 Received: by mail-qv1-xf33.google.com with SMTP id l3so14543831qvl.0 for ; Mon, 14 Jun 2021 19:23:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=syI+cnapake0XX/ydILee5A0SqQbDPJtmn9YckFmLKc=; b=NtIM0xV42nM9DvFgt/ZEmtRtkpD0H/f3in9Mnlynls2DdmAzaTH5BHhsyzgz8h6vpB 8X8/u2pV/G+VsE4QoPFG1RqwxRINxW85U681pgIqz9K3UsRfwhQrUhZ4G2QnKqYKfdvR vsbj092zZvLmH3LpwRwIqfzHBUPS+q01LdwHZ3j2vUrGcG95DefIljpzX/u0ZmajDDlN a+VS3mSWDIVkb6zUB3JofGmbnrmzZNqbeHVshWavWvRbuPcpPKCQnUlavYj7bQOo4sQm MTS9mnpsicOb5D34DYmI6ZEtXeWYSRLnsoAJoaukKABGZgIXm2jFtrljg7iiDWdFThoQ LtBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=syI+cnapake0XX/ydILee5A0SqQbDPJtmn9YckFmLKc=; b=N5YG4sI9NCI4FnP4J7zqGHM2zHdA8FrSKDfX0ztRzOkY4VYkg/4/tfu2dCxzWWwgD1 +CNHa3RCDWo6Z/N0SpoE9go4sHgPJ2LkRfdykHq2Sc4Jz+qLp6sYYCsD8g3AMArRJQ81 au0dqHCfEeaRQ8jQGpNR1/sRamCB410CMFgjVwi3fJspGmja3TpXFclZhu+idiFHaLyd UptDA2zFJh8WJojS3axA2V2ETqsLMT4z88JA3Niotj/TkgdcvAWNDbIyCyfnahADPT3d YBq0d+wSyME98H+KLASJ5iWroLTmQyQomWQi4ORCvqFnVyTdLDA5mXIO6JUHJMVPvrin pw3Q== X-Gm-Message-State: AOAM531az1DSxtKDRJrV6srIIvpQ3gttVTI4YTqW9WJ2Qgy/r5UtAxvl RjIU7zVHvb2lOMDssGjGwZdFRA== X-Google-Smtp-Source: ABdhPJwV8eIKR8qYyo6syIeibLGkmqIXgZdMjT9YJ2en9YpEY9VgqMOvoHY4fA3z6rm9yDNzzDghrw== X-Received: by 2002:ad4:40cf:: with SMTP id x15mr2469700qvp.50.1623723831161; Mon, 14 Jun 2021 19:23:51 -0700 (PDT) Received: from localhost.localdomain (bras-base-stsvon1503w-grc-21-142-114-142-78.dsl.bell.ca. [142.114.142.78]) by smtp.gmail.com with ESMTPSA id g5sm10840564qth.39.2021.06.14.19.23.50 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Mon, 14 Jun 2021 19:23:50 -0700 (PDT) Date: Mon, 14 Jun 2021 22:23:50 -0400 From: Shashi Mallela To: Peter Maydell Message-ID: In-Reply-To: References: Subject: Re: [PATCH v4 6/8] hw/intc: GICv3 redistributor ITS processing X-Mailer: Mailspring MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="60c80f36_1e2025b0_14c0" Received-SPF: pass client-ip=2607:f8b0:4864:20::f33; envelope-from=shashi.mallela@linaro.org; helo=mail-qv1-xf33.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Leif Lindholm , QEMU Developers , qemu-arm , Radoslaw Biernacki Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --60c80f36_1e2025b0_14c0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Jun 11 2021, at 4:30 am, Peter Maydell wrote: > On Fri, 11 Jun 2021 at 00:39, Shashi Mallela wrote: > > > > Have addressed all comments except the ones with responses(inline) below:- > > > > On Jun 8 2021, at 9:57 am, Peter Maydell wrote: > > > > > + cs->lpivalid = false; > > > + cs->hpplpi.prio = 0xff; > > > + gicv3_redist_update_lpi(cs); > > > > You can avoid doing a full update a lot of the time: > > * if this LPI is worse than the current value in hpplpi > > (where by "worse" I mean lower-priority by the same kind of > > comparison irqbetter() does) then we haven't changed the best-available > > pending LPI, so we don't need to do an update > > * if we set the pending bit to 1 and the LPI is enabled and the priority > > of this LPI is better than the current hpplpi, then we know this LPI > > is now the best, so we can just set hpplpi.prio and .irq without > > doing a full rescan > > * if we didn't actually change the value of the pending bit, we > > don't need to do an update (you get this for free if you take the > > simplification suggestion I make above, which does an early-return > > in the "no change" case) > > > > > Accepted the code simplification,but by not calling gicv3_redist_update_lpi(cs) here ,the scenario of an activated LPI fails because > > this LPI's priority (which could be lower than current hpplpi) is never checked/updated and gicv3_redist_update_noirqset() fails to present a valid active high priority LPI(if applicable) to the cpu,since it is always checking against a stale hpplpi info. > > If the LPI is lower priority (higher number) than the current > hpplpi then it would not change the existing hpplpi info in > a full-scan. If the LPI being activated is higher priority > (lower number) than the current hpplpi then that is my point 2 above, > and we set it as the hpplpi without needing the full-scan. And for > the other cases (eg highest-priority LPI being deactivated) we > should fall through to the default "call update_lpi" case. > > So I don't really understand why this wouldn't work. > -- PMM Have got this working as per comments.Please ignore my last comment. --60c80f36_1e2025b0_14c0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

On Jun 11 2021, at= 4:30 am, Peter Maydell <peter.maydell=40linaro.org> wrote:
On =46ri, 11 Jun 2021 at 00:39, Shashi Mallela <sh= ashi.mallela=40linaro.org> wrote:
>
> Have a= ddressed all comments except the ones with responses(inline) below:-
>
> On Jun 8 2021, at 9:57 am, Peter Maydell <pe= ter.maydell=40linaro.org> wrote:
>
> > + = cs->lpivalid =3D false;
> > + cs->hpplpi.prio =3D 0= xff;
> > + gicv3=5Fredist=5Fupdate=5Flpi(cs);
&= gt;
> You can avoid doing a full update a lot of the time:
> * if this LPI is worse than the current value in hpplpi
> (where by =22worse=22 I mean lower-priority by the same kind = of
> comparison irqbetter() does) then we haven't changed th= e best-available
> pending LPI, so we don't need to do an up= date
> * if we set the pending bit to 1 and the LPI is enabl= ed and the priority
> of this LPI is better than the current= hpplpi, then we know this LPI
> is now the best, so we can = just set hpplpi.prio and .irq without
> doing a full rescan<= /div>
> * if we didn't actually change the value of the pending bi= t, we
> don't need to do an update (you get this for free if= you take the
> simplification suggestion I make above, whic= h does an early-return
> in the =22no change=22 case)
<= div>>
> > Accepted the code simplification,but by not = calling gicv3=5Fredist=5Fupdate=5Flpi(cs) here ,the scenario of an activa= ted LPI fails because
> this LPI's priority (which could be = lower than current hpplpi) is never checked/updated and gicv3=5Fredist=5F= update=5Fnoirqset() fails to present a valid active high priority LPI(if = applicable) to the cpu,since it is always checking against a stale hpplpi= info.

If the LPI is lower priority (higher number) than th= e current
hpplpi then it would not change the existing hpplpi i= nfo in
a full-scan. If the LPI being activated is higher priori= ty
(lower number) than the current hpplpi then that is my point= 2 above,
and we set it as the hpplpi without needing the full-= scan. And for
the other cases (eg highest-priority LPI being de= activated) we
should fall through to the default =22call update= =5Flpi=22 case.

So I don't really understand why this would= n't work.

-- PMM

Have= got this working as per comments.Please ignore my last comment.
--60c80f36_1e2025b0_14c0--