qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: Shashi Mallela <shashi.mallela@linaro.org>
Cc: Leif Lindholm <leif@nuviainc.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	qemu-arm <qemu-arm@nongnu.org>,
	Radoslaw Biernacki <rad@semihalf.com>
Subject: Re: [PATCH v4 6/8] hw/intc: GICv3 redistributor ITS processing
Date: Fri, 11 Jun 2021 09:30:36 +0100	[thread overview]
Message-ID: <CAFEAcA8aPy9kwLhSOk+VjBf_44ktS_VhTAAah_N2nOH_gJuOkw@mail.gmail.com> (raw)
In-Reply-To: <551DAA51-CB17-423D-896F-AF0443A5E7AE@getmailspring.com>

On Fri, 11 Jun 2021 at 00:39, Shashi Mallela <shashi.mallela@linaro.org> wrote:
>
> Have addressed all comments except the ones with responses(inline) below:-
>
> On Jun 8 2021, at 9:57 am, Peter Maydell <peter.maydell@linaro.org> 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


  reply	other threads:[~2021-06-11  8:32 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-02 18:00 [PATCH v4 0/8] GICv3 LPI and ITS feature implementation Shashi Mallela
2021-06-02 18:00 ` [PATCH v4 1/8] hw/intc: GICv3 ITS initial framework Shashi Mallela
2021-06-08 10:02   ` Peter Maydell
2021-06-11 16:21   ` Eric Auger
2021-06-11 17:23     ` Shashi Mallela
2021-07-06  7:38     ` Eric Auger
2021-07-06 13:24       ` shashi.mallela
2021-07-06 14:04         ` Eric Auger
2021-07-06 14:18           ` shashi.mallela
2021-06-12  6:52   ` Eric Auger
2021-07-06  7:29     ` Eric Auger
2021-06-02 18:00 ` [PATCH v4 2/8] hw/intc: GICv3 ITS register definitions added Shashi Mallela
2021-06-08 10:31   ` Peter Maydell
2021-06-12  6:08   ` Eric Auger
2021-06-16 21:02     ` shashi.mallela
2021-06-21  9:51       ` Eric Auger
2021-06-28 21:51         ` shashi.mallela
2021-06-02 18:00 ` [PATCH v4 3/8] hw/intc: GICv3 ITS command queue framework Shashi Mallela
2021-06-08 10:38   ` Peter Maydell
2021-06-13 14:13   ` Eric Auger
2021-06-16 21:02     ` shashi.mallela
2021-06-21 10:03       ` Eric Auger
2021-06-28 21:58         ` shashi.mallela
2021-06-13 14:39   ` Eric Auger
2021-06-28 15:55     ` shashi.mallela
2021-06-02 18:00 ` [PATCH v4 4/8] hw/intc: GICv3 ITS Command processing Shashi Mallela
2021-06-08 10:45   ` Peter Maydell
2021-06-13 15:55   ` Eric Auger
2021-06-16 21:02     ` shashi.mallela
2021-06-21 10:13       ` Eric Auger
2021-06-28 22:04         ` shashi.mallela
2021-06-02 18:00 ` [PATCH v4 5/8] hw/intc: GICv3 ITS Feature enablement Shashi Mallela
2021-06-08 10:57   ` Peter Maydell
2021-06-02 18:00 ` [PATCH v4 6/8] hw/intc: GICv3 redistributor ITS processing Shashi Mallela
2021-06-08 13:57   ` Peter Maydell
2021-06-10 23:39     ` Shashi Mallela
2021-06-11  8:30       ` Peter Maydell [this message]
2021-06-15  2:23         ` Shashi Mallela
2021-06-13 16:26   ` Eric Auger
2021-06-16 21:02     ` shashi.mallela
2021-06-02 18:00 ` [PATCH v4 7/8] hw/arm/sbsa-ref: add ITS support in SBSA GIC Shashi Mallela
2021-06-03 11:42   ` Leif Lindholm
2021-06-03 15:31     ` shashi.mallela
2021-06-04 10:42       ` Leif Lindholm
2021-06-04 15:36         ` shashi.mallela
2021-07-08 19:40           ` Leif Lindholm
2021-07-08 20:05             ` Peter Maydell
2021-07-08 22:05               ` Leif Lindholm
2021-08-05 20:10                 ` shashi.mallela
2021-06-02 18:00 ` [PATCH v4 8/8] hw/arm/virt: add ITS support in virt GIC Shashi Mallela
2021-06-08 11:00   ` Peter Maydell
2021-06-08 10:00 ` [PATCH v4 0/8] GICv3 LPI and ITS feature implementation Peter Maydell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAFEAcA8aPy9kwLhSOk+VjBf_44ktS_VhTAAah_N2nOH_gJuOkw@mail.gmail.com \
    --to=peter.maydell@linaro.org \
    --cc=leif@nuviainc.com \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=rad@semihalf.com \
    --cc=shashi.mallela@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).