All of lore.kernel.org
 help / color / mirror / Atom feed
From: shashi.mallela@linaro.org
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	Radoslaw Biernacki <rad@semihalf.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	qemu-arm <qemu-arm@nongnu.org>,
	Igor Mammedov <imammedo@redhat.com>,
	Leif Lindholm <leif@nuviainc.com>
Subject: Re: [PATCH v5 04/10] hw/intc: GICv3 ITS Command processing
Date: Mon, 05 Jul 2021 23:25:38 -0400	[thread overview]
Message-ID: <287eb50c0b99a3daec986ec29ede33cb2bdfd025.camel@linaro.org> (raw)
In-Reply-To: <bbb32d79ed60fb90128b3662ec925f60ca258e8a.camel@linaro.org>

On Mon, 2021-07-05 at 20:47 -0400, shashi.mallela@linaro.org wrote:
> On Mon, 2021-07-05 at 15:54 +0100, Peter Maydell wrote:
> > On Wed, 30 Jun 2021 at 16:32, Shashi Mallela <
> > shashi.mallela@linaro.org> wrote:
> > > Added ITS command queue handling for MAPTI,MAPI commands,handled
> > > ITS
> > > translation which triggers an LPI via INT command as well as
> > > write
> > > to GITS_TRANSLATER register,defined enum to differentiate between
> > > ITS
> > > command interrupt trigger and GITS_TRANSLATER based interrupt
> > > trigger.
> > > Each of these commands make use of other functionalities
> > > implemented to
> > > get device table entry,collection table entry or interrupt
> > > translation
> > > table entry required for their processing.
> > > 
> > > Signed-off-by: Shashi Mallela <shashi.mallela@linaro.org>
> > > ---
> > > +static MemTxResult process_mapti(GICv3ITSState *s, uint64_t
> > > value,
> > > +                                 uint32_t offset, bool
> > > ignore_pInt)
> > > +{
> > > +    AddressSpace *as = &s->gicv3->dma_as;
> > > +    uint32_t devid, eventid;
> > > +    uint32_t pIntid = 0;
> > > +    uint32_t max_eventid, max_Intid;
> > > +    bool dte_valid;
> > > +    MemTxResult res = MEMTX_OK;
> > > +    uint16_t icid = 0;
> > > +    uint64_t dte = 0;
> > > +    IteEntry ite;
> > > +    uint32_t int_spurious = INTID_SPURIOUS;
> > > +    uint64_t idbits;
> > > +
> > > +    devid = ((value & DEVID_MASK) >> DEVID_SHIFT);
> > > +    offset += NUM_BYTES_IN_DW;
> > > +    value = address_space_ldq_le(as, s->cq.base_addr + offset,
> > > +                                 MEMTXATTRS_UNSPECIFIED, &res);
> > > +
> > > +    if (res != MEMTX_OK) {
> > > +        return res;
> > > +    }
> > > +
> > > +    eventid = (value & EVENTID_MASK);
> > > +
> > > +    if (!ignore_pInt) {
> > > +        pIntid = ((value & pINTID_MASK) >> pINTID_SHIFT);
> > > +    }
> > > +
> > > +    offset += NUM_BYTES_IN_DW;
> > > +    value = address_space_ldq_le(as, s->cq.base_addr + offset,
> > > +                                 MEMTXATTRS_UNSPECIFIED, &res);
> > > +
> > > +    if (res != MEMTX_OK) {
> > > +        return res;
> > > +    }
> > > +
> > > +    icid = value & ICID_MASK;
> > > +
> > > +    dte = get_dte(s, devid, &res);
> > > +
> > > +    if (res != MEMTX_OK) {
> > > +        return res;
> > > +    }
> > > +    dte_valid = dte & TABLE_ENTRY_VALID_MASK;
> > > +
> > > +    max_eventid = (1UL << (((dte >> 1U) & SIZE_MASK) + 1));
> > > +
> > > +    if (!ignore_pInt) {
> > > +        idbits = MIN(FIELD_EX64(s->gicv3->cpu->gicr_propbaser,
> > > GICR_PROPBASER,
> > > +                                IDBITS), GICD_TYPER_IDBITS);
> > 
> > I missed this the first time around, but I don't think this is
> > right.
> > Different CPUs could have different GICR_PROPBASER values, so
> > checking
> > against just one of them is wrong. The pseudocode only tests
> > LPIOutOfRange()
> > which is documented as testing "larger than GICD_TYPER.IDbits or
> > not
> > in
> > the LPI range and not 1023". So I don't think we should be looking
> > at the GICR_PROPBASER field here.
> > 
> > More generally, "s->gicv3->cpu->something" is usually going to be
> > wrong, because it is implicitly looking at CPU 0; often either
> > there
> > should be something else telling is which CPU to use (as in
> > &s->gicv3->cpu[rdbase] where the CTE told us which redistributor),
> > or we might need to operate on all CPUs/redistributors. The only
> > exception is where we can guarantee that all the CPUs are the same
> > (eg when looking at GICR_TYPER.PLPIS.)
> In that case,the validation of IDBITS(in case of ITS enabled) could
> be
> done during the write of gicr_propbaser register value itself(in
> arm_gicv3_redist.c) and the its command processing code here can just
> extract the idbits for its use.
> > thanks
> > -- PMM
Hi Peter

Please ignore my last comment.

To address this scenario,i think the feasible option would be to call
get_cte() to get the rdbase corresponding to icid value passed to mapti
command.Since each icid is mapped to a rdbase(by virtue of calling MAPC
command),if the collection table has a valid mapping for this icid we
continue processing this MAPTI command using &s->gicv3->cpu[rdbase]
applicable propbaser value to validate idbits, else return without
further processing.

Thanks
Shashi  



  reply	other threads:[~2021-07-06  3:26 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-30 15:31 [PATCH v5 00/10] GICv3 LPI and ITS feature implementation Shashi Mallela
2021-06-30 15:31 ` [PATCH v5 01/10] hw/intc: GICv3 ITS initial framework Shashi Mallela
2021-07-05 14:58   ` Peter Maydell
2021-07-05 15:55     ` shashi.mallela
2021-07-05 16:25       ` Peter Maydell
2021-07-05 17:04         ` shashi.mallela
2021-07-05 18:58           ` Peter Maydell
2021-07-07  2:08             ` shashi.mallela
2021-07-06  7:44   ` Eric Auger
2021-07-07  2:06     ` shashi.mallela
2021-06-30 15:31 ` [PATCH v5 02/10] hw/intc: GICv3 ITS register definitions added Shashi Mallela
2021-07-06  9:29   ` Eric Auger
2021-07-08 17:27     ` Eric Auger
2021-08-05 21:14       ` shashi.mallela
2021-06-30 15:31 ` [PATCH v5 03/10] hw/intc: GICv3 ITS command queue framework Shashi Mallela
2021-07-06  9:31   ` Eric Auger
2021-06-30 15:31 ` [PATCH v5 04/10] hw/intc: GICv3 ITS Command processing Shashi Mallela
2021-07-05 14:07   ` Peter Maydell
2021-07-06  9:27     ` Eric Auger
2021-07-07  2:02       ` shashi.mallela
2021-07-05 14:54   ` Peter Maydell
2021-07-06  0:47     ` shashi.mallela
2021-07-06  3:25       ` shashi.mallela [this message]
2021-07-06  9:19         ` Peter Maydell
2021-07-06 12:46           ` shashi.mallela
2021-07-06 13:27             ` Peter Maydell
2021-07-07  2:08               ` shashi.mallela
2021-07-06 10:04         ` Eric Auger
2021-07-06 10:07           ` Peter Maydell
2021-07-06 10:05   ` Eric Auger
2021-06-30 15:31 ` [PATCH v5 05/10] hw/intc: GICv3 ITS Feature enablement Shashi Mallela
2021-07-05 14:20   ` Peter Maydell
2021-06-30 15:31 ` [PATCH v5 06/10] hw/intc: GICv3 redistributor ITS processing Shashi Mallela
2021-07-05 14:43   ` Peter Maydell
2021-06-30 15:31 ` [PATCH v5 07/10] hw/arm/sbsa-ref: add ITS support in SBSA GIC Shashi Mallela
2021-07-05 14:59   ` Peter Maydell
2021-06-30 15:31 ` [PATCH v5 08/10] tests/data/acpi/virt: Add IORT files for ITS Shashi Mallela
2021-06-30 15:31 ` [PATCH v5 09/10] hw/arm/virt: add ITS support in virt GIC Shashi Mallela
2021-06-30 15:31 ` [PATCH v5 10/10] tests/data/acpi/virt: Update IORT files for ITS Shashi Mallela
2021-07-05 15:02   ` Peter Maydell
2021-07-05 15:05 ` [PATCH v5 00/10] 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=287eb50c0b99a3daec986ec29ede33cb2bdfd025.camel@linaro.org \
    --to=shashi.mallela@linaro.org \
    --cc=imammedo@redhat.com \
    --cc=leif@nuviainc.com \
    --cc=mst@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=rad@semihalf.com \
    --subject='Re: [PATCH v5 04/10] hw/intc: GICv3 ITS Command processing' \
    /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

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.