[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 3/4] xen/arm: its: refactor ITS quirk matching


  • To: Mykola Kvach <xakep.amatop@xxxxxxxxx>
  • From: Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
  • Date: Fri, 25 Sep 2026 17:40:29 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ni2hvsCsFylIizY+btKJ48F/2zoo9N9NXpu+DLBqsZA=; b=wh16Zzz9tklchGvarKPG+J09MJ0ey5+eijbvaskob3hGeLiFe2SqHUFO7rT0MsGgua8LSwugFeFVXiTjeaHEm3lE+6QR7xnOS+sC4sCiVaKcu6dMfshbVBtbNRzDu3+tiC6Vq76E922Cy0Myor8RUmbPef8rGEUjx7f4YdU+rZorjsBU9Jogy4k0QNht73XK1lBJmei7zd8e2qu4oiTVtN+JPLMeBfKo4dZ779KZwwJsFKzPyeadSWqwoeFlsdKA8KytSgzXJCSPdC7+0KdRWtB3at8sVb7QpVehpSIqCwIhBjnP14RdVEgEEkwAnE+CMR743YwRA/oGmjWIG3JdPg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=LLvUriqlmoujgWwxBDE5FxFMRs6QMve07VK4W+80LdUV0c/H+FdeRKkPDjEDnsbLQbXHK7QfLi5c/mKf51YGGsL5cQWnuuUcKnFtW8yoxbzirYXDPBZUNV3fu8A7E0GTZb6zWLmpoFu79XOCyjfYl+sd7Dzq1FGByjE6b/j8W1P8aZ7w6io5Ayex6w5LiqMCHy2PNeAlxx6ELRKmNurECZtXJTfE4W0qiAWIW9q7eeBzyYCF+AcbkBKghadTSNVxI+P+1mD49K/HdThWSbi/XU/JLpx1AgDXrcREeQucI7oUKNe5PvpHVVqKQ9tbAS/4sU6wugmM4N8IyLsnBK5hxA==
  • Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck"
  • Authentication-results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com;
  • Cc: Mykola Kvach <Mykola_Kvach@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>
  • Delivery-date: Fri, 25 Sep 2026 17:40:42 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHdSqtNwidRcqNdj0yo3wTLZbOD6Q==
  • Thread-topic: [PATCH v3 3/4] xen/arm: its: refactor ITS quirk matching

Hi Mykola,

Mykola Kvach <xakep.amatop@xxxxxxxxx> writes:

> On Wed, Sep 23, 2026 at 3:21 AM Volodymyr Babchuk
> <Volodymyr_Babchuk@xxxxxxxx> wrote:
>>
>> Hi,
>>
>> Mykola Kvach <mykola_kvach@xxxxxxxx> writes:
>>
>> > ITS quirks are matched only by IIDR and mask fields stored in each table
>> > entry. That is too coarse when the same GIC IP block appears on several
>> > platforms but a workaround is valid only for some of them.
>> >
>> > Replace the fixed IIDR fields with a generic match(hw_its, data)
>> > callback and an opaque data pointer. Add an IIDR matcher as a reusable
>> > building block and use it from the R-Car Gen4 matcher after checking the
>> > Renesas machine compatibles.
>> >
>> > This intentionally narrows the R-Car Gen4 quirk. Previously every ITS
>> > with IIDR 0x0201743b matched. Now it matches only a DT-discovered ITS on
>> > an r8a779f0 or r8a779g0 machine. ACPI-discovered ITSes and the same IIDR
>> > on other platforms no longer match.
>> >
>> > Keep first-match semantics explicit. Assert that non-sentinel entries
>> > provide a matcher and that IIDR matching receives match data. Retain
>> > runtime guards so malformed entries cannot cause a NULL function call
>> > or data dereference in non-debug builds. Place the matcher data and
>> > table in init-only read-only sections.
>> >
>> > The matched entry still supplies separate ITS and LPI flags; this patch
>> > only changes how the entry is selected.
>> >
>> > Signed-off-by: Mykola Kvach <mykola_kvach@xxxxxxxx>
>> > ---
>> > Changes in v3:
>> > - Document the intentional narrowing of the R-Car Gen4 match.
>> > - Add the non-debug NULL-data guard.
>> > - Put the matcher data and table in init-only read-only sections.
>> >
>> > Changes in v2:
>> > - Replace v1's optional platform callback plus fixed IIDR/mask fields
>> >   with a single generic match(hw_its, data) selector.
>> > - Add a reusable IIDR matcher and use it after the R-Car Gen4
>> >   machine-compatible checks.
>> > - Document that the R-Car Gen4 quirk remains DT-only.
>> > - Keep the split ITS and host LPI quirk scopes when applying the matched
>> >   entry.
>> > - Document first-match ordering in the lookup path and guard against
>> >   entries without a match callback or IIDR match data.
>> > ---
>> >  xen/arch/arm/gic-v3-its.c | 73 +++++++++++++++++++++++++++++++--------
>> >  1 file changed, 58 insertions(+), 15 deletions(-)
>> >
>> > diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
>> > index 454fd0e0ef..f52232ca40 100644
>> > --- a/xen/arch/arm/gic-v3-its.c
>> > +++ b/xen/arch/arm/gic-v3-its.c
>> > @@ -54,8 +54,8 @@ struct its_device {
>> >
>> >  struct its_quirk {
>> >      const char *desc;
>> > -    uint32_t iidr;
>> > -    uint32_t mask;
>> > +    bool (*match)(const struct host_its *hw_its, const void *data);
>> > +    const void *data;
>> >      uint32_t its_flags;
>> >      /*
>> >       * lpi_flags are ORed into the global host LPI policy and must only
>> > @@ -65,11 +65,52 @@ struct its_quirk {
>> >      uint32_t lpi_flags;
>> >  };
>> >
>> > -static const struct its_quirk its_quirks[] = {
>> > +struct its_quirk_match_iidr {
>> > +    uint32_t iidr;
>> > +    uint32_t mask;
>> > +};
>> > +
>> > +static bool __init gicv3_its_match_iidr(const struct host_its *hw_its,
>> > +                                        const void *data)
>> > +{
>> > +    const struct its_quirk_match_iidr *match;
>> > +    uint32_t iidr;
>> > +
>> > +    ASSERT(data);
>> > +
>> > +    if ( !data )
>> > +        return false;
>>
>> It looks strange to have both ASSERT and then this check.
>>
>> Maybe it is worth to remove ASSERT and print a warning in a debug build 
>> instead?
>
> The ASSERT catches a programming error in the static quirk table in
> debug builds, while the explicit NULL check prevents a dereference
> when assertions are disabled.
>
> However, returning false skips a potentially required workaround,
> which could cause a less obvious failure later. This also raises the
> question of whether continuing is appropriate in non-debug builds.
>
> Would you prefer the debug warning you suggested, keeping ASSERT
> with an additional warning in non-debug builds, or using BUG_ON(!data)
> to stop immediately in all builds?

Thinking about this... Yes, I believe that should be BUG_ON()

>
>>
>> > +
>> > +    match = data;
>> > +    iidr = readl_relaxed(hw_its->its_base + GITS_IIDR);
>> > +
>> > +    return (iidr & match->mask) == match->iidr;
>> > +}
>> > +
>> > +static bool __init gicv3_its_match_quirk_gen4(const struct host_its 
>> > *hw_its,
>> > +                                              const void *data)
>> > +{
>> > +    if ( !hw_its->dt_node )
>> > +        return false;
>> > +
>> > +    if ( !dt_machine_is_compatible("renesas,r8a779f0") &&
>> > +         !dt_machine_is_compatible("renesas,r8a779g0") )
>> > +        return false;
>> > +
>> > +    return gicv3_its_match_iidr(hw_its, data);
>>
>> Do you really need to match IIDR in this case? You already know that
>> platform requires the quirk.
>
> I would prefer to retain the IIDR check. The machine compatible does
> not identify the exact ITS variant and revision. Keeping both checks
> preserves the existing IIDR restriction while narrowing the match to
> the affected platforms.
>
> Linux also uses both checks for the R-Car Gen4 DMA32 workaround:
> the quirk entry matches IIDR 0x0201743b with mask 0xffffffff, and
> its_enable_dma32() additionally checks the machine compatible.

Okay then.

[...]

-- 
WBR, Volodymyr

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.