All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.