[PATCH v2 0/4] xen/arm: gicv3: defer host LPI init and split ITS/LPI quirk scopes

[PATCH v2 0/4] xen/arm: gicv3: defer host LPI init and split ITS/LPI quirk scopes

[Mykola Kvach]

From: Mykola Kvach <mykola_kvach@epam.com>

Hi all,

This series fixes the ordering of host LPI state initialization relative to
ITS quirk discovery, and then cleans up how ITS-private and host
LPI/Redistributor quirk effects are represented.

Patch 1 is the release-critical fix. It moves host LPI initialization after
gicv3_its_init(), so that the host LPI allocation path observes the ITS
quirks discovered during ITS initialization. This patch is intended for
4.22.

Patches 2-4 are follow-up cleanup and DT attribute handling. They are included
to show the intended direction and to avoid carrying the old global ITS quirk
model forward, but they are not required for taking the 4.22 fix if the
release freeze makes that preferable.

The main change from v1 is that this version no longer tries to pre-initialize
ITS quirks before host LPI setup. Instead, the minimal fix is to defer the
existing host LPI initialization until after ITS initialization. The follow-up
patches then split the quirk state by scope:

  * per-ITS flags are used for memory/state accessed by a particular ITS, such
    as GITS_CBASER, GITS_BASER<n> and ITT memory;

  * host LPI flags are used for shared Redistributor/LPI state, such as
    GICR_PROPBASER and GICR_PENDBASER.

This avoids relying on an implicit global aggregation of per-ITS quirk state.
If an ITS-discovered quirk also affects the host LPI/Redistributor path, that
effect is now expressed explicitly through the quirk entry's lpi_flags.

The series also handles the DT dma-noncoherent property according to the node
where it appears. An ITS subnode property affects only the corresponding ITS.
A top-level GIC node property affects only the host LPI/Redistributor policy.
The property is not inherited implicitly between the parent GIC node and ITS
subnodes.

The Orange Pi 5 / RK3588-specific quirk patch from v1 has been dropped. The
previous version modelled the issue as a 32-bit ITS addressing restriction.
This version handles the relevant non-coherent/non-shareable GIC integration
through the standard DT dma-noncoherent property on the GIC and ITS nodes
instead.
---

Changes since v1

* Reordered the series so that the minimal host LPI initialization ordering fix
  is first. Patch 1 is intended for 4.22.

* Dropped the v1 ITS pre-initialization hook.

* Moved the existing gicv3_lpi_init_host_lpis() call after gicv3_its_init()
  instead, so host LPI state is allocated after ITS workaround discovery.

* Checked the return value from gicv3_lpi_init_host_lpis() and made failure
  fatal once the ITS/LPI path is enabled.

* Replaced the old single global ITS quirk state with separate per-ITS and
  host LPI quirk scopes.

* Removed the implicit aggregation of all per-ITS quirks into the host LPI
  policy. Host LPI effects are now expressed explicitly with lpi_flags.

* Kept per-ITS flags for ITS-private allocations:
  - GITS_CBASER;
  - GITS_BASER<n>;
  - ITT memory.

* Kept host LPI flags for Redistributor/LPI state:
  - GICR_PROPBASER;
  - GICR_PENDBASER.

* Refactored ITS quirk matching from fixed IIDR/mask fields to a generic
  match(hw_its, data) callback plus opaque data.

* Kept first-match semantics explicit. More specific entries must be listed
  before broader IIDR-only entries.

* Added a reusable IIDR matcher and used it after checking the Renesas
  machine compatibles for the R-Car Gen4 quirk.

* Split dma-noncoherent handling by DT node scope:
  - ITS subnode dma-noncoherent affects only the matching ITS;
  - top-level GIC dma-noncoherent affects only the host LPI/Redistributor
    policy.

* Dropped the Orange Pi 5 / RK3588-specific quirk patch from v1. The
  non-coherent GIC integration is now handled through DT dma-noncoherent
  properties instead of a Xen-side platform quirk.

Mykola Kvach (4):
  xen/arm: gic: defer host LPI allocation until after ITS init
  xen/arm: its: separate ITS and host LPI quirk scopes
  xen/arm: its: refactor ITS quirk matching
  xen/arm: its: handle dma-noncoherent on GIC and ITS nodes

 xen/arch/arm/gic-v3-its.c             | 171 ++++++++++++++++----------
 xen/arch/arm/gic-v3-lpi.c             |  66 ++++++++--
 xen/arch/arm/gic-v3.c                 |  14 ++-
 xen/arch/arm/include/asm/gic_v3_its.h |  19 ++-
 4 files changed, 190 insertions(+), 80 deletions(-)

-- 
2.43.0

[PATCH for-4.22 v2 1/4] xen/arm: gic: defer host LPI allocation until after ITS init

[Mykola Kvach]

From: Mykola Kvach <mykola_kvach@epam.com>

gicv3_lpi_init_host_lpis() allocates host LPI state, including the
host LPI lookup table, CPU notifier state and the boot CPU pending table.
Those allocations use gicv3_its_get_memflags().

ITS workarounds are discovered from gicv3_its_init(), so allocating host
LPI state from gicv3_dist_init() can happen before the memory restrictions
required by the ITS are known. On affected systems this can leave
Redistributor LPI state allocated and programmed with the default memory
policy.

Move host LPI initialization after gicv3_its_init(), and only run it when
a host ITS was found. The old call ignored the return value. Now that the
call is made from gicv3_init(), check it and panic on failure because
Redistributor LPI initialization relies on that state being available.

Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
---
Changes in v2:
- Replace the v1 ITS pre-initialization hook with the less invasive
  approach suggested during review: move the existing host LPI
  initialization after gicv3_its_init().
- Check gicv3_lpi_init_host_lpis() and panic on failure, matching the fatal
  nature of host LPI setup once ITS initialization succeeded.
---
 xen/arch/arm/gic-v3.c | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 17ff85ef5d..acdac22953 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -764,9 +764,6 @@ static void __init gicv3_dist_init(void)
     type = readl_relaxed(GICD + GICD_TYPER);
     nr_lines = 32 * ((type & GICD_TYPE_LINES) + 1);
 
-    if ( type & GICD_TYPE_LPIS )
-        gicv3_lpi_init_host_lpis(GICD_TYPE_ID_BITS(type));
-
     /* Only 1020 interrupts are supported */
     nr_lines = min(1020U, nr_lines);
     gicv3_info.nr_lines = nr_lines;
@@ -1990,6 +1987,17 @@ static int __init gicv3_init(void)
         res = gicv3_its_init();
         if ( res )
             panic("GICv3: ITS: initialization failed: %d\n", res);
+
+        /*
+         * Host LPI allocation uses ITS-derived memory attributes, so defer it
+         * until after gicv3_its_init() has discovered ITS workarounds.
+         */
+        if ( gicv3_its_host_has_its() )
+        {
+            res = gicv3_lpi_init_host_lpis(intid_bits);
+            if ( res )
+                panic("GICv3: LPI initialization failed: %d\n", res);
+        }
     }
 
     res = gicv3_cpu_init();
-- 
2.43.0

[PATCH v2 2/4] xen/arm: its: separate ITS and host LPI quirk scopes

[Mykola Kvach]

From: Mykola Kvach <mykola_kvach@epam.com>

ITS quirks can impose restrictions on memory accessed by the ITS itself and
on shared host LPI/Redistributor state. These scopes are not identical, so
a single global ITS quirk state makes the host LPI policy depend implicitly
on the quirks seen while initializing host ITSes.

Add per-ITS quirk_flags to struct host_its and keep a separate
host_lpi_flags state in the LPI code. The quirk table now records the
ITS-private and host LPI scopes explicitly through its_flags and lpi_flags.
The R-Car Gen4 quirk applies the same memory-related restrictions to both
scopes, preserving the existing behavior without relying on an implicit
aggregation step.

This also removes the old assumption that all host ITSes must expose the
same quirk state. Host LPI restrictions are accumulated only from quirk
entries that explicitly set lpi_flags.

Use per-ITS quirk_flags for GITS_CBASER, GITS_BASER<n> and ITT allocations.
Use host_lpi_flags directly in gic-v3-lpi.c for GICR_PROPBASER and
GICR_PENDBASER setup. Memory-related quirk bits are named GICV3_QUIRK_MEM_*
and are translated by shared gicv3_mem_get_*() helpers.

Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
---
Changes in v2:
- Replace v1's single global ITS quirk flags and same-quirk validation with
  explicit per-ITS and host LPI quirk scopes.
- Drop the v1 ITS pre-initialization approach from this patch; host LPI
  allocation ordering is fixed separately by moving it after ITS init.
- Drop DT dma-noncoherent handling from this patch; firmware-provided
  non-coherency is handled separately with explicit ITS-node and GIC-node
  scopes.
- Keep host_lpi_flags owned by gic-v3-lpi.c and update it only with quirk
  flags that explicitly apply to host LPI/Redistributor state.
- Rename the current memory-related bits to GICV3_QUIRK_MEM_* and use
  shared gicv3_mem_get_*() helpers for register attributes and allocation
  flags.
---
 xen/arch/arm/gic-v3-its.c             | 113 ++++++++++++--------------
 xen/arch/arm/gic-v3-lpi.c             |  44 ++++++++--
 xen/arch/arm/include/asm/gic_v3_its.h |  19 +++--
 3 files changed, 101 insertions(+), 75 deletions(-)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index 7560d46c6d..dc48a84789 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -51,99 +51,81 @@ struct its_device {
     struct pending_irq *pend_irqs;      /* One struct per event */
 };
 
-/*
- * It is unlikely that a platform implements ITSes with different quirks,
- * so assume they all share the same.
- */
 struct its_quirk {
     const char *desc;
-    bool (*init)(struct host_its *hw_its);
     uint32_t iidr;
     uint32_t mask;
+    uint32_t its_flags;
+    /*
+     * lpi_flags are ORed into the global host LPI policy and must only
+     * contain additive restrictions. Non-additive LPI quirks need explicit
+     * handling.
+     */
+    uint32_t lpi_flags;
 };
 
-static uint32_t __ro_after_init its_quirk_flags;
-
-static bool gicv3_its_enable_quirk_gen4(struct host_its *hw_its)
-{
-    its_quirk_flags |= HOST_ITS_WORKAROUND_NC_NS |
-        HOST_ITS_WORKAROUND_32BIT_ADDR;
-
-    return true;
-}
-
 static const struct its_quirk its_quirks[] = {
     {
         .desc	= "R-Car Gen4",
         .iidr	= 0x0201743b,
         .mask	= 0xffffffffU,
-        .init	= gicv3_its_enable_quirk_gen4,
+        .its_flags = GICV3_QUIRK_MEM_NC_NS | GICV3_QUIRK_MEM_32BIT_ADDR,
+        .lpi_flags = GICV3_QUIRK_MEM_NC_NS | GICV3_QUIRK_MEM_32BIT_ADDR,
     },
     {
         /* Sentinel. */
     }
 };
 
-static struct its_quirk* gicv3_its_find_quirk(uint32_t iidr)
+static const struct its_quirk *__init gicv3_its_find_quirk(uint32_t iidr)
 {
     const struct its_quirk *quirks = its_quirks;
 
+    /*
+     * The first matching quirk wins. More specific quirks must be listed
+     * before broader IIDR-only entries.
+     */
     for ( ; quirks->desc; quirks++ )
     {
         if ( quirks->iidr == (quirks->mask & iidr) )
-            return (struct its_quirk *)quirks;
+            return quirks;
     }
 
     return NULL;
 }
 
-static void gicv3_its_enable_quirks(struct host_its *hw_its)
+static void __init gicv3_its_collect_quirks(struct host_its *hw_its)
 {
     uint32_t iidr = readl_relaxed(hw_its->its_base + GITS_IIDR);
     const struct its_quirk *quirk = gicv3_its_find_quirk(iidr);
 
-    if ( quirk && quirk->init(hw_its) )
-        printk("GICv3: enabling workaround for ITS: %s\n", quirk->desc);
-}
-
-static void gicv3_its_validate_quirks(void)
-{
-    const struct its_quirk *quirk = NULL, *prev = NULL;
-    const struct host_its *hw_its;
-
-    if ( list_empty(&host_its_list) )
-        return;
-
-    hw_its = list_first_entry(&host_its_list, struct host_its, entry);
-    prev = gicv3_its_find_quirk(readl_relaxed(hw_its->its_base + GITS_IIDR));
-
-    list_for_each_entry(hw_its, &host_its_list, entry)
+    if ( quirk )
     {
-        quirk = gicv3_its_find_quirk(readl_relaxed(hw_its->its_base + GITS_IIDR));
-        BUG_ON(quirk != prev);
-        prev = quirk;
+        hw_its->quirk_flags |= quirk->its_flags;
+        gicv3_lpi_update_host_flags(quirk->lpi_flags);
+        printk("GICv3: enabling workaround for ITS: %s\n", quirk->desc);
     }
 }
 
-uint64_t gicv3_its_get_cacheability(void)
+uint64_t gicv3_mem_get_cacheability(uint32_t flags)
 {
-    if ( its_quirk_flags & HOST_ITS_WORKAROUND_NC_NS )
+    if ( flags & GICV3_QUIRK_MEM_NC_NS )
         return GIC_BASER_CACHE_nC;
 
     return GIC_BASER_CACHE_RaWaWb;
 }
 
-uint64_t gicv3_its_get_shareability(void)
+uint64_t gicv3_mem_get_shareability(uint32_t flags)
 {
-    if ( its_quirk_flags & HOST_ITS_WORKAROUND_NC_NS )
+    if ( flags & GICV3_QUIRK_MEM_NC_NS )
         return GIC_BASER_NonShareable;
 
     return GIC_BASER_InnerShareable;
 }
 
-unsigned int gicv3_its_get_memflags(void)
+unsigned int gicv3_mem_get_alloc_flags(uint32_t flags)
 {
-    if ( its_quirk_flags & HOST_ITS_WORKAROUND_32BIT_ADDR )
+    if ( flags & GICV3_QUIRK_MEM_32BIT_ADDR )
         return MEMF_bits(32);
 
     return 0;
@@ -390,13 +372,17 @@ static void *its_map_cbaser(struct host_its *its)
     uint64_t reg;
     unsigned int order;
     void *buffer;
+    uint64_t cacheability = gicv3_mem_get_cacheability(its->quirk_flags);
+    uint64_t shareability = gicv3_mem_get_shareability(its->quirk_flags);
+    unsigned int memflags = gicv3_mem_get_alloc_flags(its->quirk_flags);
 
-    reg  = gicv3_its_get_shareability() << GITS_BASER_SHAREABILITY_SHIFT;
-    reg |= GIC_BASER_CACHE_SameAsInner << GITS_BASER_OUTER_CACHEABILITY_SHIFT;
-    reg |= gicv3_its_get_cacheability() << GITS_BASER_INNER_CACHEABILITY_SHIFT;
+    reg  = MASK_INSR(shareability, GITS_BASER_SHAREABILITY_MASK);
+    reg |= MASK_INSR(GIC_BASER_CACHE_SameAsInner,
+                     GITS_BASER_OUTER_CACHEABILITY_MASK);
+    reg |= MASK_INSR(cacheability, GITS_BASER_INNER_CACHEABILITY_MASK);
 
     order = get_order_from_bytes(max(ITS_CMD_QUEUE_SZ, SZ_64K));
-    buffer = alloc_xenheap_pages(order, gicv3_its_get_memflags());
+    buffer = alloc_xenheap_pages(order, memflags);
     if ( !buffer )
         return NULL;
 
@@ -437,8 +423,8 @@ static void *its_map_cbaser(struct host_its *its)
 /* The ITS BASE registers work with page sizes of 4K, 16K or 64K. */
 #define BASER_PAGE_BITS(sz) ((sz) * 2 + 12)
 
-static int its_map_baser(void __iomem *basereg, uint64_t regc,
-                         unsigned int nr_items)
+static int its_map_baser(struct host_its *its, void __iomem *basereg,
+                         uint64_t regc, unsigned int nr_items)
 {
     uint64_t attr, reg;
     unsigned int entry_size = GITS_BASER_ENTRY_SIZE(regc);
@@ -446,10 +432,14 @@ static int its_map_baser(void __iomem *basereg, uint64_t regc,
     unsigned int table_size;
     unsigned int order;
     void *buffer;
+    uint64_t cacheability = gicv3_mem_get_cacheability(its->quirk_flags);
+    uint64_t shareability = gicv3_mem_get_shareability(its->quirk_flags);
+    unsigned int memflags = gicv3_mem_get_alloc_flags(its->quirk_flags);
 
-    attr  = gicv3_its_get_shareability() << GITS_BASER_SHAREABILITY_SHIFT;
-    attr |= GIC_BASER_CACHE_SameAsInner << GITS_BASER_OUTER_CACHEABILITY_SHIFT;
-    attr |= gicv3_its_get_cacheability() << GITS_BASER_INNER_CACHEABILITY_SHIFT;
+    attr  = MASK_INSR(shareability, GITS_BASER_SHAREABILITY_MASK);
+    attr |= MASK_INSR(GIC_BASER_CACHE_SameAsInner,
+                      GITS_BASER_OUTER_CACHEABILITY_MASK);
+    attr |= MASK_INSR(cacheability, GITS_BASER_INNER_CACHEABILITY_MASK);
 
     /*
      * Setup the BASE register with the attributes that we like. Then read
@@ -463,7 +453,7 @@ retry:
     table_size = min(table_size, 256U << BASER_PAGE_BITS(pagesz));
 
     order = get_order_from_bytes(max(table_size, BIT(BASER_PAGE_BITS(pagesz), U)));
-    buffer = alloc_xenheap_pages(order, gicv3_its_get_memflags());
+    buffer = alloc_xenheap_pages(order, memflags);
     if ( !buffer )
         return -ENOMEM;
 
@@ -562,7 +552,7 @@ static int gicv3_its_init_single_its(struct host_its *hw_its)
     if ( ret )
         return ret;
 
-    gicv3_its_enable_quirks(hw_its);
+    gicv3_its_collect_quirks(hw_its);
 
     reg = readq_relaxed(hw_its->its_base + GITS_TYPER);
     hw_its->devid_bits = GITS_TYPER_DEVICE_ID_BITS(reg);
@@ -584,18 +574,19 @@ static int gicv3_its_init_single_its(struct host_its *hw_its)
         case GITS_BASER_TYPE_NONE:
             continue;
         case GITS_BASER_TYPE_DEVICE:
-            ret = its_map_baser(basereg, reg, BIT(hw_its->devid_bits, UL));
+            ret = its_map_baser(hw_its, basereg, reg,
+                                BIT(hw_its->devid_bits, UL));
             if ( ret )
                 return ret;
             break;
         case GITS_BASER_TYPE_COLLECTION:
-            ret = its_map_baser(basereg, reg, num_possible_cpus());
+            ret = its_map_baser(hw_its, basereg, reg, num_possible_cpus());
             if ( ret )
                 return ret;
             break;
         /* In case this is a GICv4, provide a (dummy) vPE table as well. */
         case GITS_BASER_TYPE_VCPU:
-            ret = its_map_baser(basereg, reg, 1);
+            ret = its_map_baser(hw_its, basereg, reg, 1);
             if ( ret )
                 return ret;
             break;
@@ -730,6 +721,7 @@ int gicv3_its_map_guest_device(struct domain *d,
     struct its_device *dev = NULL;
     struct rb_node **new = &d->arch.vgic.its_devices.rb_node, *parent = NULL;
     int i, ret = -ENOENT;      /* "i" must be signed to check for >= 0 below. */
+    unsigned int memflags;
     unsigned int order;
 
     hw_its = gicv3_its_find_by_doorbell(host_doorbell);
@@ -793,8 +785,9 @@ int gicv3_its_map_guest_device(struct domain *d,
     ret = -ENOMEM;
 
     /* An Interrupt Translation Table needs to be 256-byte aligned. */
+    memflags = gicv3_mem_get_alloc_flags(hw_its->quirk_flags);
     order = get_order_from_bytes(max(nr_events * hw_its->itte_size, 256UL));
-    itt_addr = alloc_xenheap_pages(order, gicv3_its_get_memflags());
+    itt_addr = alloc_xenheap_pages(order, memflags);
     if ( !itt_addr )
         goto out_unlock;
 
@@ -1206,8 +1199,6 @@ int gicv3_its_init(void)
             return ret;
     }
 
-    gicv3_its_validate_quirks();
-
     return 0;
 }
 
diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
index 9ee338edc2..35f93e4756 100644
--- a/xen/arch/arm/gic-v3-lpi.c
+++ b/xen/arch/arm/gic-v3-lpi.c
@@ -78,9 +78,29 @@ struct lpi_redist_data {
 
 static DEFINE_PER_CPU(struct lpi_redist_data, lpi_redist);
 
+/*
+ * Host LPI flags are scoped to shared LPI/Redistributor state, not to an
+ * ITS instance. Arm IHI 0069H.b section 5.1.1 says "LPI configuration is
+ * global". Section 12.11.33 (GICR_PROPBASER) makes mismatched values
+ * UNPREDICTABLE for Redistributors that share an LPI Configuration table
+ * while GICR_CTLR.EnableLPIs == 1. Section 12.11.32 (GICR_PENDBASER)
+ * similarly makes mismatched OuterCache, Shareability or InnerCache values
+ * across Redistributors UNPREDICTABLE while GICR_CTLR.EnableLPIs == 1.
+ *
+ * Keep this policy in the LPI code and accumulate only explicit LPI/RD
+ * restrictions into it. Per-ITS restrictions stay in host_its::quirk_flags
+ * for GITS_CBASER, GITS_BASER<n> and ITT memory.
+ */
+static uint32_t __ro_after_init host_lpi_flags;
+
 #define MAX_NR_HOST_LPIS   (lpi_data.max_host_lpi_ids - LPI_OFFSET)
 #define HOST_LPIS_PER_PAGE      (PAGE_SIZE / sizeof(union host_lpi))
 
+void __init gicv3_lpi_update_host_flags(uint32_t flags)
+{
+    host_lpi_flags |= flags;
+}
+
 static union host_lpi *gic_get_host_lpi(uint32_t plpi)
 {
     union host_lpi *block;
@@ -228,6 +248,7 @@ static int gicv3_lpi_allocate_pendtable(unsigned int cpu)
 {
     void *pendtable;
     unsigned int order;
+    unsigned int memflags = gicv3_mem_get_alloc_flags(host_lpi_flags);
 
     if ( per_cpu(lpi_redist, cpu).pending_table )
         return -EBUSY;
@@ -239,7 +260,7 @@ static int gicv3_lpi_allocate_pendtable(unsigned int cpu)
      * physically contiguous memory.
      */
     order = get_order_from_bytes(max(lpi_data.max_host_lpi_ids / 8, (unsigned long)SZ_64K));
-    pendtable = alloc_xenheap_pages(order, gicv3_its_get_memflags());
+    pendtable = alloc_xenheap_pages(order, memflags);
     if ( !pendtable )
         return -ENOMEM;
 
@@ -262,6 +283,8 @@ static int gicv3_lpi_set_pendtable(void __iomem *rdist_base)
 {
     const void *pendtable = this_cpu(lpi_redist).pending_table;
     uint64_t val;
+    uint64_t cacheability = gicv3_mem_get_cacheability(host_lpi_flags);
+    uint64_t shareability = gicv3_mem_get_shareability(host_lpi_flags);
 
     /*
      * The memory should have been allocated while preparing the CPU (or
@@ -275,9 +298,10 @@ static int gicv3_lpi_set_pendtable(void __iomem *rdist_base)
 
     ASSERT(!(virt_to_maddr(pendtable) & ~GENMASK(51, 16)));
 
-    val  = gicv3_its_get_cacheability() << GICR_PENDBASER_INNER_CACHEABILITY_SHIFT;
-    val |= GIC_BASER_CACHE_SameAsInner << GICR_PENDBASER_OUTER_CACHEABILITY_SHIFT;
-    val |= gicv3_its_get_shareability() << GICR_PENDBASER_SHAREABILITY_SHIFT;
+    val  = MASK_INSR(cacheability, GICR_PENDBASER_INNER_CACHEABILITY_MASK);
+    val |= MASK_INSR(GIC_BASER_CACHE_SameAsInner,
+                     GICR_PENDBASER_OUTER_CACHEABILITY_MASK);
+    val |= MASK_INSR(shareability, GICR_PENDBASER_SHAREABILITY_MASK);
     val |= GICR_PENDBASER_PTZ;
     val |= virt_to_maddr(pendtable);
 
@@ -304,10 +328,13 @@ static int gicv3_lpi_set_proptable(void __iomem * rdist_base)
 {
     uint64_t reg;
     unsigned int order;
+    uint64_t cacheability = gicv3_mem_get_cacheability(host_lpi_flags);
+    uint64_t shareability = gicv3_mem_get_shareability(host_lpi_flags);
 
-    reg  = gicv3_its_get_cacheability() << GICR_PROPBASER_INNER_CACHEABILITY_SHIFT;
-    reg |= GIC_BASER_CACHE_SameAsInner << GICR_PROPBASER_OUTER_CACHEABILITY_SHIFT;
-    reg |= gicv3_its_get_shareability() << GICR_PROPBASER_SHAREABILITY_SHIFT;
+    reg  = MASK_INSR(cacheability, GICR_PROPBASER_INNER_CACHEABILITY_MASK);
+    reg |= MASK_INSR(GIC_BASER_CACHE_SameAsInner,
+                     GICR_PROPBASER_OUTER_CACHEABILITY_MASK);
+    reg |= MASK_INSR(shareability, GICR_PROPBASER_SHAREABILITY_MASK);
 
     /*
      * The property table is shared across all redistributors, so allocate
@@ -317,9 +344,10 @@ static int gicv3_lpi_set_proptable(void __iomem * rdist_base)
     {
         /* The property table holds one byte per LPI. */
         void *table;
+        unsigned int memflags = gicv3_mem_get_alloc_flags(host_lpi_flags);
 
         order = get_order_from_bytes(max(lpi_data.max_host_lpi_ids, (unsigned long)SZ_4K));
-        table = alloc_xenheap_pages(order, gicv3_its_get_memflags());
+        table = alloc_xenheap_pages(order, memflags);
 
         if ( !table )
             return -ENOMEM;
diff --git a/xen/arch/arm/include/asm/gic_v3_its.h b/xen/arch/arm/include/asm/gic_v3_its.h
index fc5a84892c..3e8dcc4ae9 100644
--- a/xen/arch/arm/include/asm/gic_v3_its.h
+++ b/xen/arch/arm/include/asm/gic_v3_its.h
@@ -105,13 +105,15 @@
 #define GICV3_ITS_SIZE                  SZ_128K
 
 #include <xen/device_tree.h>
+#include <xen/init.h>
 #include <xen/rbtree.h>
 
 #define HOST_ITS_FLUSH_CMD_QUEUE        (1U << 0)
 #define HOST_ITS_USES_PTA               (1U << 1)
 
-#define HOST_ITS_WORKAROUND_NC_NS       (1U << 0)
-#define HOST_ITS_WORKAROUND_32BIT_ADDR  (1U << 1)
+/* GICv3 memory-related quirk flags. */
+#define GICV3_QUIRK_MEM_NC_NS           (1U << 0)
+#define GICV3_QUIRK_MEM_32BIT_ADDR      (1U << 1)
 
 /* We allocate LPIs on the hosts in chunks of 32 to reduce handling overhead. */
 #define LPI_BLOCK                       32U
@@ -128,6 +130,11 @@ struct host_its {
     unsigned int itte_size;
     spinlock_t cmd_lock;
     void *cmd_buf;
+    /*
+     * Workaround flags scoped to this ITS instance, including memory
+     * accessed through GITS_CBASER, GITS_BASER<n> and ITT memory.
+     */
+    uint32_t quirk_flags;
     unsigned int flags;
 };
 
@@ -157,6 +164,7 @@ int gicv3_lpi_init_rdist(void __iomem * rdist_base);
 /* Initialize the host structures for LPIs and the host ITSes. */
 int gicv3_lpi_init_host_lpis(unsigned int host_lpi_bits);
 int gicv3_its_init(void);
+void __init gicv3_lpi_update_host_flags(uint32_t flags);
 
 /* Store the physical address and ID for each redistributor as read from DT. */
 void gicv3_set_redist_address(paddr_t address, unsigned int redist_id);
@@ -199,10 +207,9 @@ struct pending_irq *gicv3_assign_guest_event(struct domain *d,
 void gicv3_lpi_update_host_entry(uint32_t host_lpi, int domain_id,
                                  uint32_t virt_lpi);
 
-/* ITS quirks handling. */
-uint64_t gicv3_its_get_cacheability(void);
-uint64_t gicv3_its_get_shareability(void);
-unsigned int gicv3_its_get_memflags(void);
+uint64_t gicv3_mem_get_cacheability(uint32_t flags);
+uint64_t gicv3_mem_get_shareability(uint32_t flags);
+unsigned int gicv3_mem_get_alloc_flags(uint32_t flags);
 
 #else
 
-- 
2.43.0

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

[Mykola Kvach]

From: Mykola Kvach <mykola_kvach@epam.com>

ITS quirks are currently matched only by IIDR and mask fields stored in
each table entry. That is too coarse for integrations where the same GIC
IP block can appear in several platforms but the workaround is only valid
for a subset of boards.

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. The R-Car Gen4 platform refinement is DT-only;
ACPI-discovered ITSes do not match it.

Keep first-match semantics explicit. Assert that non-sentinel entries
provide a matcher and that IIDR matching receives match data, but keep
runtime guards so a malformed table entry does not become a NULL function
call or NULL data dereference in non-debug builds. 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@epam.com>
---
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 | 67 +++++++++++++++++++++++++++++++--------
 1 file changed, 53 insertions(+), 14 deletions(-)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index dc48a84789..e055914763 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -53,8 +53,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
@@ -64,11 +64,48 @@ struct its_quirk {
     uint32_t lpi_flags;
 };
 
+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);
+
+    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);
+}
+
+static const struct its_quirk_match_iidr rcar_gen4_iidr = {
+    .iidr = 0x0201743b,
+    .mask = 0xffffffffU,
+};
+
 static const struct its_quirk its_quirks[] = {
     {
-        .desc	= "R-Car Gen4",
-        .iidr	= 0x0201743b,
-        .mask	= 0xffffffffU,
+        .desc = "R-Car Gen4",
+        .match = gicv3_its_match_quirk_gen4,
+        .data = &rcar_gen4_iidr,
         .its_flags = GICV3_QUIRK_MEM_NC_NS | GICV3_QUIRK_MEM_32BIT_ADDR,
         .lpi_flags = GICV3_QUIRK_MEM_NC_NS | GICV3_QUIRK_MEM_32BIT_ADDR,
     },
@@ -77,18 +114,21 @@ static const struct its_quirk its_quirks[] = {
     }
 };
 
-static const struct its_quirk *__init gicv3_its_find_quirk(uint32_t iidr)
+static const struct its_quirk *__init gicv3_its_find_quirk(
+    const struct host_its *hw_its)
 {
-    const struct its_quirk *quirks = its_quirks;
+    const struct its_quirk *quirk;
 
     /*
-     * The first matching quirk wins. More specific quirks must be listed
-     * before broader IIDR-only entries.
+     * The first matching quirk wins. Entries that match a specific platform
+     * must be listed before broader IIDR-only entries.
      */
-    for ( ; quirks->desc; quirks++ )
+    for ( quirk = its_quirks; quirk->desc; quirk++ )
     {
-        if ( quirks->iidr == (quirks->mask & iidr) )
-            return quirks;
+        ASSERT(quirk->match);
+
+        if ( quirk->match && quirk->match(hw_its, quirk->data) )
+            return quirk;
     }
 
     return NULL;
@@ -96,8 +136,7 @@ static const struct its_quirk *__init gicv3_its_find_quirk(uint32_t iidr)
 
 static void __init gicv3_its_collect_quirks(struct host_its *hw_its)
 {
-    uint32_t iidr = readl_relaxed(hw_its->its_base + GITS_IIDR);
-    const struct its_quirk *quirk = gicv3_its_find_quirk(iidr);
+    const struct its_quirk *quirk = gicv3_its_find_quirk(hw_its);
 
     if ( quirk )
     {
-- 
2.43.0

[PATCH v2 4/4] xen/arm: its: handle dma-noncoherent on GIC and ITS nodes

[Mykola Kvach]

From: Mykola Kvach <mykola_kvach@epam.com>

The DT dma-noncoherent property describes the bus coherency of the device
represented by the node. On an ITS subnode, that is memory accessed by that
ITS, so add GICV3_QUIRK_MEM_NC_NS to the corresponding host_its before
programming GITS tables and allocating ITTs.

When the property is present on the top-level GIC node, it describes the
Redistributor side of the LPI path. Collect it in
gicv3_lpi_init_host_lpis() and apply it only to the host LPI policy used
for GICR_PROPBASER and GICR_PENDBASER setup.

Do not inherit the property between parent and child nodes: ITS-node
non-coherency does not change the global host LPI policy, and GIC-node
non-coherency does not change per-ITS quirk_flags.

ACPI is left unchanged; this patch only consumes the DT dma-noncoherent
property.

Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
---
Changes in v2:
- Split v1's dma-noncoherent handling into explicit ITS-node and GIC-node
  scopes.
- Apply an ITS subnode property only to the matching host_its quirk_flags.
- Collect the top-level GIC property from gic-v3-lpi.c before host LPI
  allocations use host_lpi_flags.
---
 xen/arch/arm/gic-v3-its.c | 21 +++++++++++++++++++--
 xen/arch/arm/gic-v3-lpi.c | 22 +++++++++++++++++++++-
 2 files changed, 40 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index e055914763..606b127487 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -134,6 +134,21 @@ static const struct its_quirk *__init gicv3_its_find_quirk(
     return NULL;
 }
 
+static void __init gicv3_its_collect_fw_attrs(struct host_its *hw_its)
+{
+    /*
+     * An ITS subnode property describes memory transactions made by that ITS.
+     * Do not inherit it into the global host LPI/Redistributor policy.
+     */
+    if ( !hw_its->dt_node ||
+         !dt_property_read_bool(hw_its->dt_node, "dma-noncoherent") )
+        return;
+
+    hw_its->quirk_flags |= GICV3_QUIRK_MEM_NC_NS;
+    printk("GICv3: ITS @%#"PRIpaddr" marked dma-noncoherent\n",
+           hw_its->addr);
+}
+
 static void __init gicv3_its_collect_quirks(struct host_its *hw_its)
 {
     const struct its_quirk *quirk = gicv3_its_find_quirk(hw_its);
@@ -144,6 +159,8 @@ static void __init gicv3_its_collect_quirks(struct host_its *hw_its)
         gicv3_lpi_update_host_flags(quirk->lpi_flags);
         printk("GICv3: enabling workaround for ITS: %s\n", quirk->desc);
     }
+
+    gicv3_its_collect_fw_attrs(hw_its);
 }
 
 uint64_t gicv3_mem_get_cacheability(uint32_t flags)
@@ -578,7 +595,7 @@ static int gicv3_disable_its(struct host_its *hw_its)
     return -ETIMEDOUT;
 }
 
-static int gicv3_its_init_single_its(struct host_its *hw_its)
+static int __init gicv3_its_init_single_its(struct host_its *hw_its)
 {
     uint64_t reg;
     int i, ret;
@@ -1221,7 +1238,7 @@ static void gicv3_its_acpi_init(void)
 
 #endif
 
-int gicv3_its_init(void)
+int __init gicv3_its_init(void)
 {
     struct host_its *hw_its;
     int ret;
diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
index 35f93e4756..c6f17b9b2d 100644
--- a/xen/arch/arm/gic-v3-lpi.c
+++ b/xen/arch/arm/gic-v3-lpi.c
@@ -7,7 +7,9 @@
  * Copyright (C) 2016,2017 - ARM Ltd
  */
 
+#include <xen/acpi.h>
 #include <xen/cpu.h>
+#include <xen/device_tree.h>
 #include <xen/lib.h>
 #include <xen/mm.h>
 #include <xen/param.h>
@@ -101,6 +103,20 @@ void __init gicv3_lpi_update_host_flags(uint32_t flags)
     host_lpi_flags |= flags;
 }
 
+static void __init gicv3_lpi_collect_fw_attrs(void)
+{
+    /*
+     * A top-level GIC node property describes the Redistributor side of the
+     * LPI path. Do not inherit it into per-ITS policy.
+     */
+    if ( !acpi_disabled ||
+         !dt_property_read_bool(dt_interrupt_controller, "dma-noncoherent") )
+        return;
+
+    gicv3_lpi_update_host_flags(GICV3_QUIRK_MEM_NC_NS);
+    printk("GICv3: GIC node marked dma-noncoherent for host LPI tables\n");
+}
+
 static union host_lpi *gic_get_host_lpi(uint32_t plpi)
 {
     union host_lpi *block;
@@ -442,7 +458,7 @@ integer_param("max_lpi_bits", max_lpi_bits);
  * to the page with the actual "union host_lpi" entries. Our LPI limit
  * avoids excessive memory usage.
  */
-int gicv3_lpi_init_host_lpis(unsigned int host_lpi_bits)
+int __init gicv3_lpi_init_host_lpis(unsigned int host_lpi_bits)
 {
     unsigned int nr_lpi_ptrs;
     int rc;
@@ -450,6 +466,10 @@ int gicv3_lpi_init_host_lpis(unsigned int host_lpi_bits)
     /* We rely on the data structure being atomically accessible. */
     BUILD_BUG_ON(sizeof(union host_lpi) > sizeof(unsigned long));
 
+    gicv3_lpi_collect_fw_attrs();
+    if ( host_lpi_flags )
+        printk("GICv3: host LPI workaround flags: %#x\n", host_lpi_flags);
+
     /*
      * An implementation needs to support at least 14 bits of LPI IDs.
      * Tell the user about it, the actual number is reported below.
-- 
2.43.0

Re: [PATCH v2 0/4] xen/arm: gicv3: defer host LPI init and split ITS/LPI quirk scopes

[Mykola Kvach]

Hi all,

I forgot to include the v1 link in the cover letter.
For reference, v1 of this series is available here:
    https://patchew.org/Xen/cover.1774431310.git.mykola._5Fkvach@epam.com/

This v2 is the next revision of that series. Since the patch order and
subjects changed, some tooling may not associate the two automatically.

Thanks,
Mykola


On Thu, May 28, 2026 at 3:28 AM Mykola Kvach <xakep.amatop@gmail.com> wrote:
>
> From: Mykola Kvach <mykola_kvach@epam.com>
>
> Hi all,
>
> This series fixes the ordering of host LPI state initialization relative to
> ITS quirk discovery, and then cleans up how ITS-private and host
> LPI/Redistributor quirk effects are represented.
>
> Patch 1 is the release-critical fix. It moves host LPI initialization after
> gicv3_its_init(), so that the host LPI allocation path observes the ITS
> quirks discovered during ITS initialization. This patch is intended for
> 4.22.
>
> Patches 2-4 are follow-up cleanup and DT attribute handling. They are included
> to show the intended direction and to avoid carrying the old global ITS quirk
> model forward, but they are not required for taking the 4.22 fix if the
> release freeze makes that preferable.
>
> The main change from v1 is that this version no longer tries to pre-initialize
> ITS quirks before host LPI setup. Instead, the minimal fix is to defer the
> existing host LPI initialization until after ITS initialization. The follow-up
> patches then split the quirk state by scope:
>
>   * per-ITS flags are used for memory/state accessed by a particular ITS, such
>     as GITS_CBASER, GITS_BASER<n> and ITT memory;
>
>   * host LPI flags are used for shared Redistributor/LPI state, such as
>     GICR_PROPBASER and GICR_PENDBASER.
>
> This avoids relying on an implicit global aggregation of per-ITS quirk state.
> If an ITS-discovered quirk also affects the host LPI/Redistributor path, that
> effect is now expressed explicitly through the quirk entry's lpi_flags.
>
> The series also handles the DT dma-noncoherent property according to the node
> where it appears. An ITS subnode property affects only the corresponding ITS.
> A top-level GIC node property affects only the host LPI/Redistributor policy.
> The property is not inherited implicitly between the parent GIC node and ITS
> subnodes.
>
> The Orange Pi 5 / RK3588-specific quirk patch from v1 has been dropped. The
> previous version modelled the issue as a 32-bit ITS addressing restriction.
> This version handles the relevant non-coherent/non-shareable GIC integration
> through the standard DT dma-noncoherent property on the GIC and ITS nodes
> instead.
> ---
>
> Changes since v1
>
> * Reordered the series so that the minimal host LPI initialization ordering fix
>   is first. Patch 1 is intended for 4.22.
>
> * Dropped the v1 ITS pre-initialization hook.
>
> * Moved the existing gicv3_lpi_init_host_lpis() call after gicv3_its_init()
>   instead, so host LPI state is allocated after ITS workaround discovery.
>
> * Checked the return value from gicv3_lpi_init_host_lpis() and made failure
>   fatal once the ITS/LPI path is enabled.
>
> * Replaced the old single global ITS quirk state with separate per-ITS and
>   host LPI quirk scopes.
>
> * Removed the implicit aggregation of all per-ITS quirks into the host LPI
>   policy. Host LPI effects are now expressed explicitly with lpi_flags.
>
> * Kept per-ITS flags for ITS-private allocations:
>   - GITS_CBASER;
>   - GITS_BASER<n>;
>   - ITT memory.
>
> * Kept host LPI flags for Redistributor/LPI state:
>   - GICR_PROPBASER;
>   - GICR_PENDBASER.
>
> * Refactored ITS quirk matching from fixed IIDR/mask fields to a generic
>   match(hw_its, data) callback plus opaque data.
>
> * Kept first-match semantics explicit. More specific entries must be listed
>   before broader IIDR-only entries.
>
> * Added a reusable IIDR matcher and used it after checking the Renesas
>   machine compatibles for the R-Car Gen4 quirk.
>
> * Split dma-noncoherent handling by DT node scope:
>   - ITS subnode dma-noncoherent affects only the matching ITS;
>   - top-level GIC dma-noncoherent affects only the host LPI/Redistributor
>     policy.
>
> * Dropped the Orange Pi 5 / RK3588-specific quirk patch from v1. The
>   non-coherent GIC integration is now handled through DT dma-noncoherent
>   properties instead of a Xen-side platform quirk.
>
> Mykola Kvach (4):
>   xen/arm: gic: defer host LPI allocation until after ITS init
>   xen/arm: its: separate ITS and host LPI quirk scopes
>   xen/arm: its: refactor ITS quirk matching
>   xen/arm: its: handle dma-noncoherent on GIC and ITS nodes
>
>  xen/arch/arm/gic-v3-its.c             | 171 ++++++++++++++++----------
>  xen/arch/arm/gic-v3-lpi.c             |  66 ++++++++--
>  xen/arch/arm/gic-v3.c                 |  14 ++-
>  xen/arch/arm/include/asm/gic_v3_its.h |  19 ++-
>  4 files changed, 190 insertions(+), 80 deletions(-)
>
> --
> 2.43.0
>

Re: [PATCH for-4.22 v2 1/4] xen/arm: gic: defer host LPI allocation until after ITS init

[Oleksandr Tyshchenko]

On 5/28/26 03:25, Mykola Kvach wrote:

Hello Mykola

> From: Mykola Kvach <mykola_kvach@epam.com>
> 
> gicv3_lpi_init_host_lpis() allocates host LPI state, including the
> host LPI lookup table, CPU notifier state and the boot CPU pending table.
> Those allocations use gicv3_its_get_memflags().
> 
> ITS workarounds are discovered from gicv3_its_init(), so allocating host
> LPI state from gicv3_dist_init() can happen before the memory restrictions
> required by the ITS are known. On affected systems this can leave
> Redistributor LPI state allocated and programmed with the default memory
> policy.
> 
> Move host LPI initialization after gicv3_its_init(), and only run it when
> a host ITS was found. The old call ignored the return value. Now that the
> call is made from gicv3_init(), check it and panic on failure because
> Redistributor LPI initialization relies on that state being available.
> 
> Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
> ---
> Changes in v2:
> - Replace the v1 ITS pre-initialization hook with the less invasive
>    approach suggested during review: move the existing host LPI
>    initialization after gicv3_its_init().


Just for the context: The original review suggestion [1] was to consider 
splitting gicv3_lpi_init_host_lpis() and defer only the portions that 
depend on ITS quirks being known, specifically the allocation of the 
per-CPU pending table for the boot CPU (gicv3_lpi_allocate_pendtable), 
which is the actual consumer of gicv3_its_get_memflags(). But here, the 
whole gicv3_lpi_init_host_lpis() is moved, so the scope of the deferral 
is broader.

[1] 
https://patchew.org/Xen/cover.1774431310.git.mykola._5Fkvach@epam.com/a7732487959e777ff1de318cb28c588db69fbaa1.1774431311.git.mykola._5Fkvach@epam.com/

> - Check gicv3_lpi_init_host_lpis() and panic on failure, matching the fatal
>    nature of host LPI setup once ITS initialization succeeded.

So, this patch appears to fix two distinct issues:

- ordering issue (LPI init occurring before ITS quirks are known)
- unchecked return value from gicv3_lpi_init_host_lpis()

Should these warrant Fixes: tag(s)?


> ---
>   xen/arch/arm/gic-v3.c | 14 +++++++++++---
>   1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index 17ff85ef5d..acdac22953 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -764,9 +764,6 @@ static void __init gicv3_dist_init(void)
>       type = readl_relaxed(GICD + GICD_TYPER);
>       nr_lines = 32 * ((type & GICD_TYPE_LINES) + 1);
>   
> -    if ( type & GICD_TYPE_LPIS )
> -        gicv3_lpi_init_host_lpis(GICD_TYPE_ID_BITS(type));
> -
>       /* Only 1020 interrupts are supported */
>       nr_lines = min(1020U, nr_lines);
>       gicv3_info.nr_lines = nr_lines;
> @@ -1990,6 +1987,17 @@ static int __init gicv3_init(void)
>           res = gicv3_its_init();
>           if ( res )
>               panic("GICv3: ITS: initialization failed: %d\n", res);
> +
> +        /*
> +         * Host LPI allocation uses ITS-derived memory attributes, so defer it
> +         * until after gicv3_its_init() has discovered ITS workarounds.
> +         */
> +        if ( gicv3_its_host_has_its() )

This looks like a behaviour change. The condition is narrowed from "GICD 
advertises LPI support" to "host ITS is present". As a result, on a 
system where GICD_TYPE_LPIS is set but no ITS is present, LPI-specific 
variables and data structures will no longer be initialized or 
allocated. If I am not mistaken, software-generated LPIs without ITS 
involvement are currently unsupported, so this change might be safe. 
However, I think the commit message should explicitly document this 
behaviour change and explain why it is safe.


> +        {
> +            res = gicv3_lpi_init_host_lpis(intid_bits);
> +            if ( res )
> +                panic("GICv3: LPI initialization failed: %d\n", res);
> +        }
>       }
>   
>       res = gicv3_cpu_init();

Re: [PATCH for-4.22 v2 1/4] xen/arm: gic: defer host LPI allocation until after ITS init

[Mykola Kvach]

Hi Oleksandr,

Thanks for the review.

On Wed, Jun 3, 2026 at 2:19 PM Oleksandr Tyshchenko <olekstysh@gmail.com> wrote:
>
>
>
> On 5/28/26 03:25, Mykola Kvach wrote:
>
> Hello Mykola
>
> > From: Mykola Kvach <mykola_kvach@epam.com>
> >
> > gicv3_lpi_init_host_lpis() allocates host LPI state, including the
> > host LPI lookup table, CPU notifier state and the boot CPU pending table.
> > Those allocations use gicv3_its_get_memflags().
> >
> > ITS workarounds are discovered from gicv3_its_init(), so allocating host
> > LPI state from gicv3_dist_init() can happen before the memory restrictions
> > required by the ITS are known. On affected systems this can leave
> > Redistributor LPI state allocated and programmed with the default memory
> > policy.
> >
> > Move host LPI initialization after gicv3_its_init(), and only run it when
> > a host ITS was found. The old call ignored the return value. Now that the
> > call is made from gicv3_init(), check it and panic on failure because
> > Redistributor LPI initialization relies on that state being available.
> >
> > Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
> > ---
> > Changes in v2:
> > - Replace the v1 ITS pre-initialization hook with the less invasive
> >    approach suggested during review: move the existing host LPI
> >    initialization after gicv3_its_init().
>
>
> Just for the context: The original review suggestion [1] was to consider
> splitting gicv3_lpi_init_host_lpis() and defer only the portions that
> depend on ITS quirks being known, specifically the allocation of the
> per-CPU pending table for the boot CPU (gicv3_lpi_allocate_pendtable),
> which is the actual consumer of gicv3_its_get_memflags(). But here, the
> whole gicv3_lpi_init_host_lpis() is moved, so the scope of the deferral
> is broader.
>
> [1]
> https://patchew.org/Xen/cover.1774431310.git.mykola._5Fkvach@epam.com/a7732487959e777ff1de318cb28c588db69fbaa1.1774431311.git.mykola._5Fkvach@epam.com/
>
> > - Check gicv3_lpi_init_host_lpis() and panic on failure, matching the fatal
> >    nature of host LPI setup once ITS initialization succeeded.
>
> So, this patch appears to fix two distinct issues:
>
> - ordering issue (LPI init occurring before ITS quirks are known)
> - unchecked return value from gicv3_lpi_init_host_lpis()
>
> Should these warrant Fixes: tag(s)?

Yes, I agree that the patch should carry Fixes tags.

For the ordering issue, I think the relevant tag is:

Fixes: 751ec850ec1d ("ARM: ITS: implement quirks and add support for
Renesas Gen4 ITS")

For the ignored return value, I think the first commit where this became
observable is:

Fixes: dcb6cb263689 ("ARM: GICv3 ITS: introduce host LPI array")

The original call site already ignored the return value, but at that
point gicv3_lpi_init_host_lpis() could not fail in practice.
dcb6cb263689 introduced the host LPI array allocation and made the
function return -ENOMEM, so the ignored return value became meaningful
there. Later, 69589c374a92 added another meaningful failure path through
the boot CPU pending-table allocation, but dcb6cb263689 seems to be the
earliest commit where the return value became relevant.

>
>
> > ---
> >   xen/arch/arm/gic-v3.c | 14 +++++++++++---
> >   1 file changed, 11 insertions(+), 3 deletions(-)
> >
> > diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> > index 17ff85ef5d..acdac22953 100644
> > --- a/xen/arch/arm/gic-v3.c
> > +++ b/xen/arch/arm/gic-v3.c
> > @@ -764,9 +764,6 @@ static void __init gicv3_dist_init(void)
> >       type = readl_relaxed(GICD + GICD_TYPER);
> >       nr_lines = 32 * ((type & GICD_TYPE_LINES) + 1);
> >
> > -    if ( type & GICD_TYPE_LPIS )
> > -        gicv3_lpi_init_host_lpis(GICD_TYPE_ID_BITS(type));
> > -
> >       /* Only 1020 interrupts are supported */
> >       nr_lines = min(1020U, nr_lines);
> >       gicv3_info.nr_lines = nr_lines;
> > @@ -1990,6 +1987,17 @@ static int __init gicv3_init(void)
> >           res = gicv3_its_init();
> >           if ( res )
> >               panic("GICv3: ITS: initialization failed: %d\n", res);
> > +
> > +        /*
> > +         * Host LPI allocation uses ITS-derived memory attributes, so defer it
> > +         * until after gicv3_its_init() has discovered ITS workarounds.
> > +         */
> > +        if ( gicv3_its_host_has_its() )
>
> This looks like a behaviour change. The condition is narrowed from "GICD
> advertises LPI support" to "host ITS is present". As a result, on a
> system where GICD_TYPE_LPIS is set but no ITS is present, LPI-specific
> variables and data structures will no longer be initialized or
> allocated. If I am not mistaken, software-generated LPIs without ITS
> involvement are currently unsupported, so this change might be safe.
> However, I think the commit message should explicitly document this
> behaviour change and explain why it is safe.

Regarding the behaviour change: yes, it is intentional, and I agree that
it should be documented in the commit message.

The patch narrows the condition from "GICD advertises LPIs" to "a host
ITS was discovered". Xen currently has no supported LPI path without a
host ITS: gicv3_lpi_init_rdist() already rejects that case with
-ENODEV. Therefore, on systems where GICD_TYPE_LPIS is set but no host
ITS is present, deferring and gating gicv3_lpi_init_host_lpis() only
avoids allocating host LPI state which cannot be used by a supported Xen
LPI path.

The CPU notifier is registered from gicv3_lpi_init_host_lpis() itself, so
when host LPI initialization is skipped for the no-host-ITS case, the
secondary-CPU pending-table allocation path is not enabled either.

I kept the whole gicv3_lpi_init_host_lpis() deferral in one piece to
keep the 4.22 release fix small. Splitting out only the boot CPU
pending-table allocation would be possible, but it would make the fix
more invasive.

If the patch is otherwise acceptable, could the Fixes tags and the
clarification below be folded into the commit message when applying it?
Otherwise I can send a v3 of patch 1 only with just commit-message and
trailer updates.

Suggested commit-message fold-in:

This also narrows the condition for host LPI initialization from
"GICD advertises LPIs" to "a host ITS was discovered". This is
intentional: Xen currently has no supported LPI path without a host ITS,
and gicv3_lpi_init_rdist() already rejects that case with -ENODEV.
Therefore, on systems where GICD_TYPE_LPIS is set but no host ITS is
present, skipping gicv3_lpi_init_host_lpis() only avoids allocating host
LPI state that cannot be used by a supported Xen LPI path.

Best regards,
Mykola

Re: [PATCH for-4.22 v2 1/4] xen/arm: gic: defer host LPI allocation until after ITS init

[Oleksandr Tyshchenko]

On 6/5/26 09:28, Mykola Kvach wrote:
> Hi Oleksandr,

Hello Mykola

> 
> Thanks for the review.
> 
> On Wed, Jun 3, 2026 at 2:19 PM Oleksandr Tyshchenko <olekstysh@gmail.com> wrote:
>>
>>
>>
>> On 5/28/26 03:25, Mykola Kvach wrote:
>>
>> Hello Mykola
>>
>>> From: Mykola Kvach <mykola_kvach@epam.com>
>>>
>>> gicv3_lpi_init_host_lpis() allocates host LPI state, including the
>>> host LPI lookup table, CPU notifier state and the boot CPU pending table.
>>> Those allocations use gicv3_its_get_memflags().
>>>
>>> ITS workarounds are discovered from gicv3_its_init(), so allocating host
>>> LPI state from gicv3_dist_init() can happen before the memory restrictions
>>> required by the ITS are known. On affected systems this can leave
>>> Redistributor LPI state allocated and programmed with the default memory
>>> policy.
>>>
>>> Move host LPI initialization after gicv3_its_init(), and only run it when
>>> a host ITS was found. The old call ignored the return value. Now that the
>>> call is made from gicv3_init(), check it and panic on failure because
>>> Redistributor LPI initialization relies on that state being available.
>>>
>>> Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
>>> ---
>>> Changes in v2:
>>> - Replace the v1 ITS pre-initialization hook with the less invasive
>>>     approach suggested during review: move the existing host LPI
>>>     initialization after gicv3_its_init().
>>
>>
>> Just for the context: The original review suggestion [1] was to consider
>> splitting gicv3_lpi_init_host_lpis() and defer only the portions that
>> depend on ITS quirks being known, specifically the allocation of the
>> per-CPU pending table for the boot CPU (gicv3_lpi_allocate_pendtable),
>> which is the actual consumer of gicv3_its_get_memflags(). But here, the
>> whole gicv3_lpi_init_host_lpis() is moved, so the scope of the deferral
>> is broader.
>>
>> [1]
>> https://patchew.org/Xen/cover.1774431310.git.mykola._5Fkvach@epam.com/a7732487959e777ff1de318cb28c588db69fbaa1.1774431311.git.mykola._5Fkvach@epam.com/
>>
>>> - Check gicv3_lpi_init_host_lpis() and panic on failure, matching the fatal
>>>     nature of host LPI setup once ITS initialization succeeded.
>>
>> So, this patch appears to fix two distinct issues:
>>
>> - ordering issue (LPI init occurring before ITS quirks are known)
>> - unchecked return value from gicv3_lpi_init_host_lpis()
>>
>> Should these warrant Fixes: tag(s)?
> 
> Yes, I agree that the patch should carry Fixes tags.
> 
> For the ordering issue, I think the relevant tag is:
> 
> Fixes: 751ec850ec1d ("ARM: ITS: implement quirks and add support for
> Renesas Gen4 ITS")
> 
> For the ignored return value, I think the first commit where this became
> observable is:
> 
> Fixes: dcb6cb263689 ("ARM: GICv3 ITS: introduce host LPI array")
> 
> The original call site already ignored the return value, but at that
> point gicv3_lpi_init_host_lpis() could not fail in practice.
> dcb6cb263689 introduced the host LPI array allocation and made the
> function return -ENOMEM, so the ignored return value became meaningful
> there. Later, 69589c374a92 added another meaningful failure path through
> the boot CPU pending-table allocation, but dcb6cb263689 seems to be the
> earliest commit where the return value became relevant.
> 
>>
>>
>>> ---
>>>    xen/arch/arm/gic-v3.c | 14 +++++++++++---
>>>    1 file changed, 11 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
>>> index 17ff85ef5d..acdac22953 100644
>>> --- a/xen/arch/arm/gic-v3.c
>>> +++ b/xen/arch/arm/gic-v3.c
>>> @@ -764,9 +764,6 @@ static void __init gicv3_dist_init(void)
>>>        type = readl_relaxed(GICD + GICD_TYPER);
>>>        nr_lines = 32 * ((type & GICD_TYPE_LINES) + 1);
>>>
>>> -    if ( type & GICD_TYPE_LPIS )
>>> -        gicv3_lpi_init_host_lpis(GICD_TYPE_ID_BITS(type));
>>> -
>>>        /* Only 1020 interrupts are supported */
>>>        nr_lines = min(1020U, nr_lines);
>>>        gicv3_info.nr_lines = nr_lines;
>>> @@ -1990,6 +1987,17 @@ static int __init gicv3_init(void)
>>>            res = gicv3_its_init();
>>>            if ( res )
>>>                panic("GICv3: ITS: initialization failed: %d\n", res);
>>> +
>>> +        /*
>>> +         * Host LPI allocation uses ITS-derived memory attributes, so defer it
>>> +         * until after gicv3_its_init() has discovered ITS workarounds.
>>> +         */
>>> +        if ( gicv3_its_host_has_its() )
>>
>> This looks like a behaviour change. The condition is narrowed from "GICD
>> advertises LPI support" to "host ITS is present". As a result, on a
>> system where GICD_TYPE_LPIS is set but no ITS is present, LPI-specific
>> variables and data structures will no longer be initialized or
>> allocated. If I am not mistaken, software-generated LPIs without ITS
>> involvement are currently unsupported, so this change might be safe.
>> However, I think the commit message should explicitly document this
>> behaviour change and explain why it is safe.
> 
> Regarding the behaviour change: yes, it is intentional, and I agree that
> it should be documented in the commit message.
> 
> The patch narrows the condition from "GICD advertises LPIs" to "a host
> ITS was discovered". Xen currently has no supported LPI path without a
> host ITS: gicv3_lpi_init_rdist() already rejects that case with
> -ENODEV. Therefore, on systems where GICD_TYPE_LPIS is set but no host
> ITS is present, deferring and gating gicv3_lpi_init_host_lpis() only
> avoids allocating host LPI state which cannot be used by a supported Xen
> LPI path.
> 
> The CPU notifier is registered from gicv3_lpi_init_host_lpis() itself, so
> when host LPI initialization is skipped for the no-host-ITS case, the
> secondary-CPU pending-table allocation path is not enabled either.
> 
> I kept the whole gicv3_lpi_init_host_lpis() deferral in one piece to
> keep the 4.22 release fix small. Splitting out only the boot CPU
> pending-table allocation would be possible, but it would make the fix
> more invasive.
> 
> If the patch is otherwise acceptable, could the Fixes tags and the
> clarification below be folded into the commit message when applying it?
> Otherwise I can send a v3 of patch 1 only with just commit-message and
> trailer updates.
> 
> Suggested commit-message fold-in:
> 
> This also narrows the condition for host LPI initialization from
> "GICD advertises LPIs" to "a host ITS was discovered". This is
> intentional: Xen currently has no supported LPI path without a host ITS,
> and gicv3_lpi_init_rdist() already rejects that case with -ENODEV.
> Therefore, on systems where GICD_TYPE_LPIS is set but no host ITS is
> present, skipping gicv3_lpi_init_host_lpis() only avoids allocating host
> LPI state that cannot be used by a supported Xen LPI path.

Thanks, the justification is reasonable to me.

With the Fixes tags added and the suggested commit-message paragraph 
folded in:
Reviewed-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>

Regarding fold-in vs v3:
That is a maintainer preference question. Since only the commit message 
and trailers need updating, a fold-in at apply time might be efficient. 
However, I think that you still need the Arm maintainer's approval on 
the patch itself.

> 
> Best regards,
> Mykola

[PATCH for-4.22 v2.5] xen/arm: gic: defer host LPI allocation until after ITS init

[Mykola Kvach]

gicv3_lpi_init_host_lpis() allocates host LPI state, including the
host LPI lookup table, CPU notifier state and the boot CPU pending table.
Those allocations use gicv3_its_get_memflags().

ITS quirks are discovered by gicv3_its_init(), so allocating host LPI
state from gicv3_dist_init() can happen before the memory restrictions
required by the ITS are known. On affected systems this can leave
Redistributor LPI state allocated and programmed with the default memory
policy.

Move host LPI initialization after gicv3_its_init(), and only run it when
a host ITS was found. The old call ignored the return value. Now that the
call is made from gicv3_init(), check it and panic on failure because
Redistributor LPI initialization relies on that state being available.

This also narrows the condition for host LPI initialization from
"GICD advertises LPIs" to "a host ITS was discovered". This is
intentional: Xen currently has no supported LPI path without a host ITS,
and gicv3_lpi_init_rdist() already rejects that case with -ENODEV.
Therefore, on systems where GICD_TYPE_LPIS is set but no host ITS is
present, skipping gicv3_lpi_init_host_lpis() only avoids allocating host
LPI state that cannot be used by a supported Xen LPI path.

Fixes: dcb6cb263689 ("ARM: GICv3 ITS: introduce host LPI array")
Fixes: 751ec850ec1d ("ARM: ITS: implement quirks and add support for Renesas Gen4 ITS")
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
---
Changes in v2.5:
- Rework the commit message to explain why host LPI initialization is now
  tied to the presence of a host ITS.
- Document the intentional behavior change from checking GICD_TYPE_LPIS to
  checking whether a host ITS was discovered.
- Add Fixes tags for the host LPI allocation and ITS quirks ordering issues.
- No code changes.

Changes in v2:
- Replace the v1 ITS pre-initialization hook with the less invasive
  approach suggested during review: move the existing host LPI
  initialization after gicv3_its_init().
- Check gicv3_lpi_init_host_lpis() and panic on failure, matching the fatal
  nature of host LPI setup once ITS initialization succeeded.
---
 xen/arch/arm/gic-v3.c | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 17ff85ef5d..acdac22953 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -764,9 +764,6 @@ static void __init gicv3_dist_init(void)
     type = readl_relaxed(GICD + GICD_TYPER);
     nr_lines = 32 * ((type & GICD_TYPE_LINES) + 1);
 
-    if ( type & GICD_TYPE_LPIS )
-        gicv3_lpi_init_host_lpis(GICD_TYPE_ID_BITS(type));
-
     /* Only 1020 interrupts are supported */
     nr_lines = min(1020U, nr_lines);
     gicv3_info.nr_lines = nr_lines;
@@ -1990,6 +1987,17 @@ static int __init gicv3_init(void)
         res = gicv3_its_init();
         if ( res )
             panic("GICv3: ITS: initialization failed: %d\n", res);
+
+        /*
+         * Host LPI allocation uses ITS-derived memory attributes, so defer it
+         * until after gicv3_its_init() has discovered ITS workarounds.
+         */
+        if ( gicv3_its_host_has_its() )
+        {
+            res = gicv3_lpi_init_host_lpis(intid_bits);
+            if ( res )
+                panic("GICv3: LPI initialization failed: %d\n", res);
+        }
     }
 
     res = gicv3_cpu_init();
-- 
2.43.0

Re: [PATCH for-4.22 v2.5] xen/arm: gic: defer host LPI allocation until after ITS init

[Orzel, Michal]

On 19-Jun-26 07:45, Mykola Kvach wrote:
> gicv3_lpi_init_host_lpis() allocates host LPI state, including the
> host LPI lookup table, CPU notifier state and the boot CPU pending table.
> Those allocations use gicv3_its_get_memflags().
> 
> ITS quirks are discovered by gicv3_its_init(), so allocating host LPI
> state from gicv3_dist_init() can happen before the memory restrictions
> required by the ITS are known. On affected systems this can leave
> Redistributor LPI state allocated and programmed with the default memory
> policy.
> 
> Move host LPI initialization after gicv3_its_init(), and only run it when
> a host ITS was found. The old call ignored the return value. Now that the
> call is made from gicv3_init(), check it and panic on failure because
> Redistributor LPI initialization relies on that state being available.
> 
> This also narrows the condition for host LPI initialization from
> "GICD advertises LPIs" to "a host ITS was discovered". This is
> intentional: Xen currently has no supported LPI path without a host ITS,
> and gicv3_lpi_init_rdist() already rejects that case with -ENODEV.
> Therefore, on systems where GICD_TYPE_LPIS is set but no host ITS is
> present, skipping gicv3_lpi_init_host_lpis() only avoids allocating host
> LPI state that cannot be used by a supported Xen LPI path.
> 
> Fixes: dcb6cb263689 ("ARM: GICv3 ITS: introduce host LPI array")
> Fixes: 751ec850ec1d ("ARM: ITS: implement quirks and add support for Renesas Gen4 ITS")
> Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
> Reviewed-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>

~Michal

Re: [PATCH for-4.22 v2.5] xen/arm: gic: defer host LPI allocation until after ITS init

[Orzel, Michal]

@Oleksii, can we ask for a release ack here?

~Michal

On 19-Jun-26 08:09, Orzel, Michal wrote:
> 
> 
> On 19-Jun-26 07:45, Mykola Kvach wrote:
>> gicv3_lpi_init_host_lpis() allocates host LPI state, including the
>> host LPI lookup table, CPU notifier state and the boot CPU pending table.
>> Those allocations use gicv3_its_get_memflags().
>>
>> ITS quirks are discovered by gicv3_its_init(), so allocating host LPI
>> state from gicv3_dist_init() can happen before the memory restrictions
>> required by the ITS are known. On affected systems this can leave
>> Redistributor LPI state allocated and programmed with the default memory
>> policy.
>>
>> Move host LPI initialization after gicv3_its_init(), and only run it when
>> a host ITS was found. The old call ignored the return value. Now that the
>> call is made from gicv3_init(), check it and panic on failure because
>> Redistributor LPI initialization relies on that state being available.
>>
>> This also narrows the condition for host LPI initialization from
>> "GICD advertises LPIs" to "a host ITS was discovered". This is
>> intentional: Xen currently has no supported LPI path without a host ITS,
>> and gicv3_lpi_init_rdist() already rejects that case with -ENODEV.
>> Therefore, on systems where GICD_TYPE_LPIS is set but no host ITS is
>> present, skipping gicv3_lpi_init_host_lpis() only avoids allocating host
>> LPI state that cannot be used by a supported Xen LPI path.
>>
>> Fixes: dcb6cb263689 ("ARM: GICv3 ITS: introduce host LPI array")
>> Fixes: 751ec850ec1d ("ARM: ITS: implement quirks and add support for Renesas Gen4 ITS")
>> Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
>> Reviewed-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
> Reviewed-by: Michal Orzel <michal.orzel@amd.com>
> 
> ~Michal
> 
> 

Re: [PATCH for-4.22 v2.5] xen/arm: gic: defer host LPI allocation until after ITS init

[Julien Grall]

Hi Michal,

On 19/06/2026 10:48, Orzel, Michal wrote:
> @Oleksii, can we ask for a release ack here?

Can you explain the pros/cons of introducing this patch quite late?

One of the risk here is that we are now initializing the LPIs *after* 
the ITSes. I understand this is because we want to know the workaround. 
However, I vaguely recall that there was a dependency in the 
configuration. So are we confident the new ordering will not bring other 
issues? Ideally this should have been explained in the commit message.

Cheers,

-- 
Julien Grall

Re: [PATCH for-4.22 v2.5] xen/arm: gic: defer host LPI allocation until after ITS init

[Orzel, Michal]

On 19-Jun-26 13:23, Julien Grall wrote:
> Hi Michal,
> 
> On 19/06/2026 10:48, Orzel, Michal wrote:
>> @Oleksii, can we ask for a release ack here?
> 
> Can you explain the pros/cons of introducing this patch quite late?
The advantage is that it fixes the broken LPIs on affected hardware.
The disadvantage is the reordering risk but I don't think there is any issue.

> 
> One of the risk here is that we are now initializing the LPIs *after* 
> the ITSes. I understand this is because we want to know the workaround. 
> However, I vaguely recall that there was a dependency in the 
> configuration. So are we confident the new ordering will not bring other 
> issues? Ideally this should have been explained in the commit message.
gic-v3-its.c never references host LPI state, so ITS init has no dependency on LPIs.

~Michal

Re: [PATCH for-4.22 v2.5] xen/arm: gic: defer host LPI allocation until after ITS init

[Julien Grall]

On 19/06/2026 12:34, Orzel, Michal wrote:
> 
> 
> On 19-Jun-26 13:23, Julien Grall wrote:
>> Hi Michal,
>>
>> On 19/06/2026 10:48, Orzel, Michal wrote:
>>> @Oleksii, can we ask for a release ack here?
>>
>> Can you explain the pros/cons of introducing this patch quite late?
> The advantage is that it fixes the broken LPIs on affected hardware.

 > The disadvantage is the reordering risk but I don't think there is 
any issue.

See more below.
>>
>> One of the risk here is that we are now initializing the LPIs *after*
>> the ITSes. I understand this is because we want to know the workaround.
>> However, I vaguely recall that there was a dependency in the
>> configuration. So are we confident the new ordering will not bring other
>> issues? Ideally this should have been explained in the commit message.
> gic-v3-its.c never references host LPI state, so ITS init has no dependency on LPIs.

My concern is at the HW level. The ITS is using LPIs. But we will 
configure the ITS first and then the LPIs.

What probaly saves us is the fact gicv3_lpi_init_host_lpis() only seem 
to allocate memory. This is a bit fragile though.

Cheers,

-- 
Julien Grall

Re: [PATCH for-4.22 v2.5] xen/arm: gic: defer host LPI allocation until after ITS init

[Oleksii Kurochko]

On 6/19/26 1:52 PM, Julien Grall wrote:
> 
> 
> On 19/06/2026 12:34, Orzel, Michal wrote:
>>
>>
>> On 19-Jun-26 13:23, Julien Grall wrote:
>>> Hi Michal,
>>>
>>> On 19/06/2026 10:48, Orzel, Michal wrote:
>>>> @Oleksii, can we ask for a release ack here?
>>>
>>> Can you explain the pros/cons of introducing this patch quite late?
>> The advantage is that it fixes the broken LPIs on affected hardware.
> 
>  > The disadvantage is the reordering risk but I don't think there is 
> any issue.
> 
> See more below.
>>>
>>> One of the risk here is that we are now initializing the LPIs *after*
>>> the ITSes. I understand this is because we want to know the workaround.
>>> However, I vaguely recall that there was a dependency in the
>>> configuration. So are we confident the new ordering will not bring other
>>> issues? Ideally this should have been explained in the commit message.
>> gic-v3-its.c never references host LPI state, so ITS init has no 
>> dependency on LPIs.
> 
> My concern is at the HW level. The ITS is using LPIs. But we will 
> configure the ITS first and then the LPIs.
> 
> What probaly saves us is the fact gicv3_lpi_init_host_lpis() only seem 
> to allocate memory. This is a bit fragile though.

Julien, do you think that a fix should be done differently and this one 
isn't really acceptable?

~ Oleksii

Re: [PATCH for-4.22 v2.5] xen/arm: gic: defer host LPI allocation until after ITS init

[Julien Grall]

On 19/06/2026 14:17, Oleksii Kurochko wrote:
> 
> 
> On 6/19/26 1:52 PM, Julien Grall wrote:
>>
>>
>> On 19/06/2026 12:34, Orzel, Michal wrote:
>>>
>>>
>>> On 19-Jun-26 13:23, Julien Grall wrote:
>>>> Hi Michal,
>>>>
>>>> On 19/06/2026 10:48, Orzel, Michal wrote:
>>>>> @Oleksii, can we ask for a release ack here?
>>>>
>>>> Can you explain the pros/cons of introducing this patch quite late?
>>> The advantage is that it fixes the broken LPIs on affected hardware.
>>
>>  > The disadvantage is the reordering risk but I don't think there is 
>> any issue.
>>
>> See more below.
>>>>
>>>> One of the risk here is that we are now initializing the LPIs *after*
>>>> the ITSes. I understand this is because we want to know the workaround.
>>>> However, I vaguely recall that there was a dependency in the
>>>> configuration. So are we confident the new ordering will not bring 
>>>> other
>>>> issues? Ideally this should have been explained in the commit message.
>>> gic-v3-its.c never references host LPI state, so ITS init has no 
>>> dependency on LPIs.
>>
>> My concern is at the HW level. The ITS is using LPIs. But we will 
>> configure the ITS first and then the LPIs.
>>
>> What probaly saves us is the fact gicv3_lpi_init_host_lpis() only seem 
>> to allocate memory. This is a bit fragile though.
> 
> Julien, do you think that a fix should be done differently and this one 
> isn't really acceptable?

The code is alright for 4.22 so long the ordering impact is clarified in 
the commit message.

But for the next release, I think it would be good to move the LPI init 
call in the ITS initialization so we can have the following steps:
  1. Query the workaround
  2. Initialize LPIs
  2. Initialize the ITSes

Cheers,

-- 
Julien Grall

Re: [PATCH for-4.22 v2.5] xen/arm: gic: defer host LPI allocation until after ITS init

[Mykola Kvach]

Hi Julien, Oleksii,

On Fri, Jun 19, 2026 at 2:52 PM Julien Grall <julien@xen.org> wrote:
>
>
>
> On 19/06/2026 12:34, Orzel, Michal wrote:
> >
> >
> > On 19-Jun-26 13:23, Julien Grall wrote:
> >> Hi Michal,
> >>
> >> On 19/06/2026 10:48, Orzel, Michal wrote:
> >>> @Oleksii, can we ask for a release ack here?
> >>
> >> Can you explain the pros/cons of introducing this patch quite late?
> > The advantage is that it fixes the broken LPIs on affected hardware.
>
>  > The disadvantage is the reordering risk but I don't think there is
> any issue.
>
> See more below.
> >>
> >> One of the risk here is that we are now initializing the LPIs *after*
> >> the ITSes. I understand this is because we want to know the workaround.
> >> However, I vaguely recall that there was a dependency in the
> >> configuration. So are we confident the new ordering will not bring other
> >> issues? Ideally this should have been explained in the commit message.
> > gic-v3-its.c never references host LPI state, so ITS init has no dependency on LPIs.
>
> My concern is at the HW level. The ITS is using LPIs. But we will
> configure the ITS first and then the LPIs.
>
> What probaly saves us is the fact gicv3_lpi_init_host_lpis() only seem
> to allocate memory. This is a bit fragile though.

Regarding the ordering concern, the only operation moved by this patch
is gicv3_lpi_init_host_lpis(). It does not program either the
Redistributor or the ITS. It initializes Xen-side host LPI bookkeeping,
registers the CPU notifier, and allocates the boot CPU pending table.

gicv3_its_init() programs the ITS tables and command queue and enables
the ITS, but Xen does not enqueue any ITS command there. The first
MAPC/SYNC commands are issued by gicv3_its_setup_collection().

The relevant hardware-visible sequence in gicv3_cpu_init() therefore
remains:

    gicv3_lpi_init_rdist()       /* program PENDBASER/PROPBASER */
    gicv3_enable_lpis()          /* set EnableLPIs, followed by wmb() */
    gicv3_its_setup_collection() /* issue MAPC/SYNC */

So the ordering introduced by 95604873cc is preserved: no MAPC command
is submitted before GICR_PENDBASER/GICR_PROPBASER have been programmed
and the write setting GICR_CTLR.EnableLPIs has been made visible.

This matches the relevant architectural requirement: while
GICR_CTLR.EnableLPIs is 0, ITS translation requests or commands
involving LPIs in that Redistributor are ignored. This patch changes
when the backing memory is allocated, not when the Redistributor is
programmed or when the first ITS command is submitted.

The benefit of taking this for 4.22 is that it fixes broken LPIs on
systems where an ITS workaround changes the required memory attributes.
The ordering-specific fragility is that this reasoning relies on
gicv3_lpi_init_host_lpis() remaining allocation/bookkeeping-only. I
agree that this implicit dependency should be documented explicitly.

I will respin the commit message to describe this ordering and explain
why the hardware-visible sequence is unchanged.

Does this address your concern about taking the fix for 4.22?

Best regards,
Mykola

Re: [PATCH for-4.22 v2.5] xen/arm: gic: defer host LPI allocation until after ITS init

[Julien Grall]

Hi,

On 19/06/2026 15:55, Mykola Kvach wrote:
> Hi Julien, Oleksii,
> 
> On Fri, Jun 19, 2026 at 2:52 PM Julien Grall <julien@xen.org> wrote:
>>
>>
>>
>> On 19/06/2026 12:34, Orzel, Michal wrote:
>>>
>>>
>>> On 19-Jun-26 13:23, Julien Grall wrote:
>>>> Hi Michal,
>>>>
>>>> On 19/06/2026 10:48, Orzel, Michal wrote:
>>>>> @Oleksii, can we ask for a release ack here?
>>>>
>>>> Can you explain the pros/cons of introducing this patch quite late?
>>> The advantage is that it fixes the broken LPIs on affected hardware.
>>
>>   > The disadvantage is the reordering risk but I don't think there is
>> any issue.
>>
>> See more below.
>>>>
>>>> One of the risk here is that we are now initializing the LPIs *after*
>>>> the ITSes. I understand this is because we want to know the workaround.
>>>> However, I vaguely recall that there was a dependency in the
>>>> configuration. So are we confident the new ordering will not bring other
>>>> issues? Ideally this should have been explained in the commit message.
>>> gic-v3-its.c never references host LPI state, so ITS init has no dependency on LPIs.
>>
>> My concern is at the HW level. The ITS is using LPIs. But we will
>> configure the ITS first and then the LPIs.
>>
>> What probaly saves us is the fact gicv3_lpi_init_host_lpis() only seem
>> to allocate memory. This is a bit fragile though.
> 
> Regarding the ordering concern, the only operation moved by this patch
> is gicv3_lpi_init_host_lpis(). It does not program either the
> Redistributor or the ITS. It initializes Xen-side host LPI bookkeeping,
> registers the CPU notifier, and allocates the boot CPU pending table.
> 
> gicv3_its_init() programs the ITS tables and command queue and enables
> the ITS, but Xen does not enqueue any ITS command there. The first
> MAPC/SYNC commands are issued by gicv3_its_setup_collection().
> 
> The relevant hardware-visible sequence in gicv3_cpu_init() therefore
> remains:
> 
>      gicv3_lpi_init_rdist()       /* program PENDBASER/PROPBASER */
>      gicv3_enable_lpis()          /* set EnableLPIs, followed by wmb() */
>      gicv3_its_setup_collection() /* issue MAPC/SYNC */
> 
> So the ordering introduced by 95604873cc is preserved: no MAPC command
> is submitted before GICR_PENDBASER/GICR_PROPBASER have been programmed
> and the write setting GICR_CTLR.EnableLPIs has been made visible.
> 
> This matches the relevant architectural requirement: while
> GICR_CTLR.EnableLPIs is 0, ITS translation requests or commands
> involving LPIs in that Redistributor are ignored. This patch changes
> when the backing memory is allocated, not when the Redistributor is
> programmed or when the first ITS command is submitted.
> 
> The benefit of taking this for 4.22 is that it fixes broken LPIs on
> systems where an ITS workaround changes the required memory attributes.
> The ordering-specific fragility is that this reasoning relies on
> gicv3_lpi_init_host_lpis() remaining allocation/bookkeeping-only. I
> agree that this implicit dependency should be documented explicitly.
> 
> I will respin the commit message to describe this ordering and explain
> why the hardware-visible sequence is unchanged.
> 
> Does this address your concern about taking the fix for 4.22?

Thanks for the detailed explanation. As I wrote back to Oleksii, I think 
the code could be re-architecture post-4.22.

For 4.22, no need to send a new patch. You could propose a new commit 
message here and we update on merge.

Cheers,

-- 
Julien Grall

Re: [PATCH for-4.22 v2.5] xen/arm: gic: defer host LPI allocation until after ITS init

[Mykola Kvach]

Hi Julien,

Thanks.

On Fri, Jun 19, 2026 at 8:23 PM Julien Grall <julien@xen.org> wrote:
>
> Hi,
>
> On 19/06/2026 15:55, Mykola Kvach wrote:
> > Hi Julien, Oleksii,
> >
> > On Fri, Jun 19, 2026 at 2:52 PM Julien Grall <julien@xen.org> wrote:
> >>
> >>
> >>
> >> On 19/06/2026 12:34, Orzel, Michal wrote:
> >>>
> >>>
> >>> On 19-Jun-26 13:23, Julien Grall wrote:
> >>>> Hi Michal,
> >>>>
> >>>> On 19/06/2026 10:48, Orzel, Michal wrote:
> >>>>> @Oleksii, can we ask for a release ack here?
> >>>>
> >>>> Can you explain the pros/cons of introducing this patch quite late?
> >>> The advantage is that it fixes the broken LPIs on affected hardware.
> >>
> >>   > The disadvantage is the reordering risk but I don't think there is
> >> any issue.
> >>
> >> See more below.
> >>>>
> >>>> One of the risk here is that we are now initializing the LPIs *after*
> >>>> the ITSes. I understand this is because we want to know the workaround.
> >>>> However, I vaguely recall that there was a dependency in the
> >>>> configuration. So are we confident the new ordering will not bring other
> >>>> issues? Ideally this should have been explained in the commit message.
> >>> gic-v3-its.c never references host LPI state, so ITS init has no dependency on LPIs.
> >>
> >> My concern is at the HW level. The ITS is using LPIs. But we will
> >> configure the ITS first and then the LPIs.
> >>
> >> What probaly saves us is the fact gicv3_lpi_init_host_lpis() only seem
> >> to allocate memory. This is a bit fragile though.
> >
> > Regarding the ordering concern, the only operation moved by this patch
> > is gicv3_lpi_init_host_lpis(). It does not program either the
> > Redistributor or the ITS. It initializes Xen-side host LPI bookkeeping,
> > registers the CPU notifier, and allocates the boot CPU pending table.
> >
> > gicv3_its_init() programs the ITS tables and command queue and enables
> > the ITS, but Xen does not enqueue any ITS command there. The first
> > MAPC/SYNC commands are issued by gicv3_its_setup_collection().
> >
> > The relevant hardware-visible sequence in gicv3_cpu_init() therefore
> > remains:
> >
> >      gicv3_lpi_init_rdist()       /* program PENDBASER/PROPBASER */
> >      gicv3_enable_lpis()          /* set EnableLPIs, followed by wmb() */
> >      gicv3_its_setup_collection() /* issue MAPC/SYNC */
> >
> > So the ordering introduced by 95604873cc is preserved: no MAPC command
> > is submitted before GICR_PENDBASER/GICR_PROPBASER have been programmed
> > and the write setting GICR_CTLR.EnableLPIs has been made visible.
> >
> > This matches the relevant architectural requirement: while
> > GICR_CTLR.EnableLPIs is 0, ITS translation requests or commands
> > involving LPIs in that Redistributor are ignored. This patch changes
> > when the backing memory is allocated, not when the Redistributor is
> > programmed or when the first ITS command is submitted.
> >
> > The benefit of taking this for 4.22 is that it fixes broken LPIs on
> > systems where an ITS workaround changes the required memory attributes.
> > The ordering-specific fragility is that this reasoning relies on
> > gicv3_lpi_init_host_lpis() remaining allocation/bookkeeping-only. I
> > agree that this implicit dependency should be documented explicitly.
> >
> > I will respin the commit message to describe this ordering and explain
> > why the hardware-visible sequence is unchanged.
> >
> > Does this address your concern about taking the fix for 4.22?
>
> Thanks for the detailed explanation. As I wrote back to Oleksii, I think
> the code could be re-architecture post-4.22.

For post-4.22, I agree with the proposed restructuring. I will take it
into account when updating the follow-up quirk series, so that all ITS
workarounds are queried before host LPI initialization and ITS
activation.

>
> For 4.22, no need to send a new patch. You could propose a new commit
> message here and we update on merge.

For 4.22, I propose the following commit message:

xen/arm: gic: defer host LPI allocation until after ITS init

gicv3_lpi_init_host_lpis() initializes Xen-side host LPI bookkeeping,
registers the CPU notifier, and allocates the boot CPU pending table.
The pending table allocation uses gicv3_its_get_memflags().

ITS quirks are discovered by gicv3_its_init(), so allocating the boot
CPU pending table from gicv3_dist_init() can happen before the memory
restrictions required by the ITS are known. On affected systems this
can leave the pending table allocated using the default memory policy.

Move host LPI initialization after gicv3_its_init(), and only run it
when a host ITS was found. The old call ignored the return value. Now
that the call is made from gicv3_init(), check it and panic on failure
because Redistributor LPI initialization relies on that state being
available.

Although this reorders host LPI bookkeeping with respect to ITS
initialization, it does not change the hardware-visible LPI setup
sequence. gicv3_lpi_init_host_lpis() does not program the
Redistributor or submit any ITS commands. gicv3_cpu_init() still
programs GICR_PENDBASER/GICR_PROPBASER via
gicv3_lpi_init_rdist(), sets GICR_CTLR.EnableLPIs, and only then calls
gicv3_its_setup_collection(), which submits the first MAPC/SYNC
commands. Therefore, the ordering introduced by 95604873cc remains
unchanged.

This also narrows the condition for host LPI initialization from
"GICD advertises LPIs" to "a host ITS was discovered". This is
intentional: Xen currently has no supported LPI path without a host
ITS, and gicv3_lpi_init_rdist() already rejects that case with
-ENODEV. Therefore, on systems where GICD_TYPE_LPIS is set but no host
ITS is present, skipping gicv3_lpi_init_host_lpis() only avoids
allocating host LPI state that cannot be used by a supported Xen LPI
path.

Fixes: dcb6cb263689 ("ARM: GICv3 ITS: introduce host LPI array")
Fixes: 751ec850ec1d ("ARM: ITS: implement quirks and add support for
Renesas Gen4 ITS")
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>

Cheers,
Mykola

Re: [PATCH for-4.22 v2.5] xen/arm: gic: defer host LPI allocation until after ITS init

[Oleksii Kurochko]

Hello Mykola and Julien,


On 6/21/26 5:49 PM, Mykola Kvach wrote:
> Hi Julien,
> 
> Thanks.
> 
> On Fri, Jun 19, 2026 at 8:23 PM Julien Grall <julien@xen.org> wrote:
>>
>> Hi,
>>
>> On 19/06/2026 15:55, Mykola Kvach wrote:
>>> Hi Julien, Oleksii,
>>>
>>> On Fri, Jun 19, 2026 at 2:52 PM Julien Grall <julien@xen.org> wrote:
>>>>
>>>>
>>>>
>>>> On 19/06/2026 12:34, Orzel, Michal wrote:
>>>>>
>>>>>
>>>>> On 19-Jun-26 13:23, Julien Grall wrote:
>>>>>> Hi Michal,
>>>>>>
>>>>>> On 19/06/2026 10:48, Orzel, Michal wrote:
>>>>>>> @Oleksii, can we ask for a release ack here?
>>>>>>
>>>>>> Can you explain the pros/cons of introducing this patch quite late?
>>>>> The advantage is that it fixes the broken LPIs on affected hardware.
>>>>
>>>>    > The disadvantage is the reordering risk but I don't think there is
>>>> any issue.
>>>>
>>>> See more below.
>>>>>>
>>>>>> One of the risk here is that we are now initializing the LPIs *after*
>>>>>> the ITSes. I understand this is because we want to know the workaround.
>>>>>> However, I vaguely recall that there was a dependency in the
>>>>>> configuration. So are we confident the new ordering will not bring other
>>>>>> issues? Ideally this should have been explained in the commit message.
>>>>> gic-v3-its.c never references host LPI state, so ITS init has no dependency on LPIs.
>>>>
>>>> My concern is at the HW level. The ITS is using LPIs. But we will
>>>> configure the ITS first and then the LPIs.
>>>>
>>>> What probaly saves us is the fact gicv3_lpi_init_host_lpis() only seem
>>>> to allocate memory. This is a bit fragile though.
>>>
>>> Regarding the ordering concern, the only operation moved by this patch
>>> is gicv3_lpi_init_host_lpis(). It does not program either the
>>> Redistributor or the ITS. It initializes Xen-side host LPI bookkeeping,
>>> registers the CPU notifier, and allocates the boot CPU pending table.
>>>
>>> gicv3_its_init() programs the ITS tables and command queue and enables
>>> the ITS, but Xen does not enqueue any ITS command there. The first
>>> MAPC/SYNC commands are issued by gicv3_its_setup_collection().
>>>
>>> The relevant hardware-visible sequence in gicv3_cpu_init() therefore
>>> remains:
>>>
>>>       gicv3_lpi_init_rdist()       /* program PENDBASER/PROPBASER */
>>>       gicv3_enable_lpis()          /* set EnableLPIs, followed by wmb() */
>>>       gicv3_its_setup_collection() /* issue MAPC/SYNC */
>>>
>>> So the ordering introduced by 95604873cc is preserved: no MAPC command
>>> is submitted before GICR_PENDBASER/GICR_PROPBASER have been programmed
>>> and the write setting GICR_CTLR.EnableLPIs has been made visible.
>>>
>>> This matches the relevant architectural requirement: while
>>> GICR_CTLR.EnableLPIs is 0, ITS translation requests or commands
>>> involving LPIs in that Redistributor are ignored. This patch changes
>>> when the backing memory is allocated, not when the Redistributor is
>>> programmed or when the first ITS command is submitted.
>>>
>>> The benefit of taking this for 4.22 is that it fixes broken LPIs on
>>> systems where an ITS workaround changes the required memory attributes.
>>> The ordering-specific fragility is that this reasoning relies on
>>> gicv3_lpi_init_host_lpis() remaining allocation/bookkeeping-only. I
>>> agree that this implicit dependency should be documented explicitly.
>>>
>>> I will respin the commit message to describe this ordering and explain
>>> why the hardware-visible sequence is unchanged.
>>>
>>> Does this address your concern about taking the fix for 4.22?
>>
>> Thanks for the detailed explanation. As I wrote back to Oleksii, I think
>> the code could be re-architecture post-4.22.
> 
> For post-4.22, I agree with the proposed restructuring. I will take it
> into account when updating the follow-up quirk series, so that all ITS
> workarounds are queried before host LPI initialization and ITS
> activation.
> 
>>
>> For 4.22, no need to send a new patch. You could propose a new commit
>> message here and we update on merge.
> 
> For 4.22, I propose the following commit message:
> 
> xen/arm: gic: defer host LPI allocation until after ITS init
> 
> gicv3_lpi_init_host_lpis() initializes Xen-side host LPI bookkeeping,
> registers the CPU notifier, and allocates the boot CPU pending table.
> The pending table allocation uses gicv3_its_get_memflags().
> 
> ITS quirks are discovered by gicv3_its_init(), so allocating the boot
> CPU pending table from gicv3_dist_init() can happen before the memory
> restrictions required by the ITS are known. On affected systems this
> can leave the pending table allocated using the default memory policy.
> 
> Move host LPI initialization after gicv3_its_init(), and only run it
> when a host ITS was found. The old call ignored the return value. Now
> that the call is made from gicv3_init(), check it and panic on failure
> because Redistributor LPI initialization relies on that state being
> available.
> 
> Although this reorders host LPI bookkeeping with respect to ITS
> initialization, it does not change the hardware-visible LPI setup
> sequence. gicv3_lpi_init_host_lpis() does not program the
> Redistributor or submit any ITS commands. gicv3_cpu_init() still
> programs GICR_PENDBASER/GICR_PROPBASER via
> gicv3_lpi_init_rdist(), sets GICR_CTLR.EnableLPIs, and only then calls
> gicv3_its_setup_collection(), which submits the first MAPC/SYNC
> commands. Therefore, the ordering introduced by 95604873cc remains
> unchanged.
> 
> This also narrows the condition for host LPI initialization from
> "GICD advertises LPIs" to "a host ITS was discovered". This is
> intentional: Xen currently has no supported LPI path without a host
> ITS, and gicv3_lpi_init_rdist() already rejects that case with
> -ENODEV. Therefore, on systems where GICD_TYPE_LPIS is set but no host
> ITS is present, skipping gicv3_lpi_init_host_lpis() only avoids
> allocating host LPI state that cannot be used by a supported Xen LPI
> path.
> 
> Fixes: dcb6cb263689 ("ARM: GICv3 ITS: introduce host LPI array")
> Fixes: 751ec850ec1d ("ARM: ITS: implement quirks and add support for
> Renesas Gen4 ITS")
> Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
> Reviewed-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
> Reviewed-by: Michal Orzel <michal.orzel@amd.com>
> 
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

Thanks.

~ Oleksii

Re: [PATCH v2 2/4] xen/arm: its: separate ITS and host LPI quirk scopes

[Orzel, Michal]

On 28-May-26 02:25, Mykola Kvach wrote:
> From: Mykola Kvach <mykola_kvach@epam.com>
> 
> ITS quirks can impose restrictions on memory accessed by the ITS itself and
> on shared host LPI/Redistributor state. These scopes are not identical, so
> a single global ITS quirk state makes the host LPI policy depend implicitly
> on the quirks seen while initializing host ITSes.
> 
> Add per-ITS quirk_flags to struct host_its and keep a separate
> host_lpi_flags state in the LPI code. The quirk table now records the
> ITS-private and host LPI scopes explicitly through its_flags and lpi_flags.
> The R-Car Gen4 quirk applies the same memory-related restrictions to both
> scopes, preserving the existing behavior without relying on an implicit
> aggregation step.
> 
> This also removes the old assumption that all host ITSes must expose the
> same quirk state. Host LPI restrictions are accumulated only from quirk
> entries that explicitly set lpi_flags.
> 
> Use per-ITS quirk_flags for GITS_CBASER, GITS_BASER<n> and ITT allocations.
> Use host_lpi_flags directly in gic-v3-lpi.c for GICR_PROPBASER and
> GICR_PENDBASER setup. Memory-related quirk bits are named GICV3_QUIRK_MEM_*
> and are translated by shared gicv3_mem_get_*() helpers.
> 
> Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>

~Michal

Re: [PATCH v2 2/4] xen/arm: its: separate ITS and host LPI quirk scopes

[Orzel, Michal]

On 28-May-26 02:25, Mykola Kvach wrote:
> From: Mykola Kvach <mykola_kvach@epam.com>
> 
> ITS quirks can impose restrictions on memory accessed by the ITS itself and
> on shared host LPI/Redistributor state. These scopes are not identical, so
> a single global ITS quirk state makes the host LPI policy depend implicitly
> on the quirks seen while initializing host ITSes.
> 
> Add per-ITS quirk_flags to struct host_its and keep a separate
> host_lpi_flags state in the LPI code. The quirk table now records the
> ITS-private and host LPI scopes explicitly through its_flags and lpi_flags.
> The R-Car Gen4 quirk applies the same memory-related restrictions to both
> scopes, preserving the existing behavior without relying on an implicit
> aggregation step.
> 
> This also removes the old assumption that all host ITSes must expose the
> same quirk state. Host LPI restrictions are accumulated only from quirk
> entries that explicitly set lpi_flags.
> 
> Use per-ITS quirk_flags for GITS_CBASER, GITS_BASER<n> and ITT allocations.
> Use host_lpi_flags directly in gic-v3-lpi.c for GICR_PROPBASER and
> GICR_PENDBASER setup. Memory-related quirk bits are named GICV3_QUIRK_MEM_*
> and are translated by shared gicv3_mem_get_*() helpers.
> 
> Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
I already gave R-b for this patch but noticed two issues:

[...]

>  
> -static void gicv3_its_enable_quirks(struct host_its *hw_its)
> +static void __init gicv3_its_collect_quirks(struct host_its *hw_its)
The only caller of gicv3_its_collect_quirks() is
gicv3_its_init_single_its(), which stays non-init until patch 4/4.
Please annotate the caller here as well.

[...]

> @@ -157,6 +164,7 @@ int gicv3_lpi_init_rdist(void __iomem * rdist_base);
>  /* Initialize the host structures for LPIs and the host ITSes. */
>  int gicv3_lpi_init_host_lpis(unsigned int host_lpi_bits);
>  int gicv3_its_init(void);
> +void __init gicv3_lpi_update_host_flags(uint32_t flags);
Please, do not add __init here for a prototype.

~Michal

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

[Orzel, Michal]

On 28-May-26 02:25, Mykola Kvach wrote:
> From: Mykola Kvach <mykola_kvach@epam.com>
> 
> ITS quirks are currently matched only by IIDR and mask fields stored in
> each table entry. That is too coarse for integrations where the same GIC
> IP block can appear in several platforms but the workaround is only valid
> for a subset of boards.
> 
> 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. The R-Car Gen4 platform refinement is DT-only;
> ACPI-discovered ITSes do not match it.
> 
> Keep first-match semantics explicit. Assert that non-sentinel entries
> provide a matcher and that IIDR matching receives match data, but keep
> runtime guards so a malformed table entry does not become a NULL function
> call or NULL data dereference in non-debug builds. 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@epam.com>
> ---
> 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 | 67 +++++++++++++++++++++++++++++++--------
>  1 file changed, 53 insertions(+), 14 deletions(-)
> 
> diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
> index dc48a84789..e055914763 100644
> --- a/xen/arch/arm/gic-v3-its.c
> +++ b/xen/arch/arm/gic-v3-its.c
> @@ -53,8 +53,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
> @@ -64,11 +64,48 @@ struct its_quirk {
>      uint32_t lpi_flags;
>  };
>  
> +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);
> +
> +    match = data;
> +    iidr = readl_relaxed(hw_its->its_base + GITS_IIDR);
> +
> +    return (iidr & match->mask) == match->iidr;
The commit message says you keep a runtime guard so malformed table data
does not become a NULL data dereference in non-debug builds, but there is
no such guard - ASSERT() compiles out and match->mask is then read from
NULL.

> +}
> +
> +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") )
Given that IIDR 0x0201743b is not Renesas-specific as you mention in the cover
letter, this is a behavior changed and should be mentioned in the commit msg
(cover letter is not in git).

> +        return false;
> +
> +    return gicv3_its_match_iidr(hw_its, data);
> +}
> +
> +static const struct its_quirk_match_iidr rcar_gen4_iidr = {
__initconst

> +    .iidr = 0x0201743b,
> +    .mask = 0xffffffffU,
> +};
> +
>  static const struct its_quirk its_quirks[] = {
__initconstrel

>      {
> -        .desc	= "R-Car Gen4",
> -        .iidr	= 0x0201743b,
> -        .mask	= 0xffffffffU,
> +        .desc = "R-Car Gen4",
> +        .match = gicv3_its_match_quirk_gen4,
> +        .data = &rcar_gen4_iidr,
>          .its_flags = GICV3_QUIRK_MEM_NC_NS | GICV3_QUIRK_MEM_32BIT_ADDR,
>          .lpi_flags = GICV3_QUIRK_MEM_NC_NS | GICV3_QUIRK_MEM_32BIT_ADDR,
>      },
> @@ -77,18 +114,21 @@ static const struct its_quirk its_quirks[] = {
>      }
>  };
>  
> -static const struct its_quirk *__init gicv3_its_find_quirk(uint32_t iidr)
> +static const struct its_quirk *__init gicv3_its_find_quirk(
> +    const struct host_its *hw_its)
>  {
> -    const struct its_quirk *quirks = its_quirks;
> +    const struct its_quirk *quirk;
>  
>      /*
> -     * The first matching quirk wins. More specific quirks must be listed
> -     * before broader IIDR-only entries.
> +     * The first matching quirk wins. Entries that match a specific platform
> +     * must be listed before broader IIDR-only entries.
>       */
> -    for ( ; quirks->desc; quirks++ )
> +    for ( quirk = its_quirks; quirk->desc; quirk++ )
>      {
> -        if ( quirks->iidr == (quirks->mask & iidr) )
> -            return quirks;
> +        ASSERT(quirk->match);
> +
> +        if ( quirk->match && quirk->match(hw_its, quirk->data) )
> +            return quirk;
>      }
>  
>      return NULL;
> @@ -96,8 +136,7 @@ static const struct its_quirk *__init gicv3_its_find_quirk(uint32_t iidr)
>  
>  static void __init gicv3_its_collect_quirks(struct host_its *hw_its)
>  {
> -    uint32_t iidr = readl_relaxed(hw_its->its_base + GITS_IIDR);
> -    const struct its_quirk *quirk = gicv3_its_find_quirk(iidr);
> +    const struct its_quirk *quirk = gicv3_its_find_quirk(hw_its);
>  
>      if ( quirk )
>      {

~Michal

Re: [PATCH v2 4/4] xen/arm: its: handle dma-noncoherent on GIC and ITS nodes

[Orzel, Michal]

On 28-May-26 02:25, Mykola Kvach wrote:
> From: Mykola Kvach <mykola_kvach@epam.com>
> 
> The DT dma-noncoherent property describes the bus coherency of the device
> represented by the node. On an ITS subnode, that is memory accessed by that
> ITS, so add GICV3_QUIRK_MEM_NC_NS to the corresponding host_its before
> programming GITS tables and allocating ITTs.
> 
> When the property is present on the top-level GIC node, it describes the
> Redistributor side of the LPI path. Collect it in
> gicv3_lpi_init_host_lpis() and apply it only to the host LPI policy used
> for GICR_PROPBASER and GICR_PENDBASER setup.
> 
> Do not inherit the property between parent and child nodes: ITS-node
> non-coherency does not change the global host LPI policy, and GIC-node
> non-coherency does not change per-ITS quirk_flags.
> 
> ACPI is left unchanged; this patch only consumes the DT dma-noncoherent
> property.
> 
> Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
> ---
> Changes in v2:
> - Split v1's dma-noncoherent handling into explicit ITS-node and GIC-node
>   scopes.
> - Apply an ITS subnode property only to the matching host_its quirk_flags.
> - Collect the top-level GIC property from gic-v3-lpi.c before host LPI
>   allocations use host_lpi_flags.
> ---
>  xen/arch/arm/gic-v3-its.c | 21 +++++++++++++++++++--
>  xen/arch/arm/gic-v3-lpi.c | 22 +++++++++++++++++++++-
>  2 files changed, 40 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
> index e055914763..606b127487 100644
> --- a/xen/arch/arm/gic-v3-its.c
> +++ b/xen/arch/arm/gic-v3-its.c
> @@ -134,6 +134,21 @@ static const struct its_quirk *__init gicv3_its_find_quirk(
>      return NULL;
>  }
>  
> +static void __init gicv3_its_collect_fw_attrs(struct host_its *hw_its)
> +{
> +    /*
> +     * An ITS subnode property describes memory transactions made by that ITS.
> +     * Do not inherit it into the global host LPI/Redistributor policy.
> +     */
> +    if ( !hw_its->dt_node ||
> +         !dt_property_read_bool(hw_its->dt_node, "dma-noncoherent") )
> +        return;
> +
> +    hw_its->quirk_flags |= GICV3_QUIRK_MEM_NC_NS;
> +    printk("GICv3: ITS @%#"PRIpaddr" marked dma-noncoherent\n",
> +           hw_its->addr);
> +}
> +
>  static void __init gicv3_its_collect_quirks(struct host_its *hw_its)
>  {
>      const struct its_quirk *quirk = gicv3_its_find_quirk(hw_its);
> @@ -144,6 +159,8 @@ static void __init gicv3_its_collect_quirks(struct host_its *hw_its)
>          gicv3_lpi_update_host_flags(quirk->lpi_flags);
>          printk("GICv3: enabling workaround for ITS: %s\n", quirk->desc);
>      }
> +
> +    gicv3_its_collect_fw_attrs(hw_its);
>  }
>  
>  uint64_t gicv3_mem_get_cacheability(uint32_t flags)
> @@ -578,7 +595,7 @@ static int gicv3_disable_its(struct host_its *hw_its)
>      return -ETIMEDOUT;
>  }
>  
> -static int gicv3_its_init_single_its(struct host_its *hw_its)
> +static int __init gicv3_its_init_single_its(struct host_its *hw_its)
These __init additions have nothing to do with dma-noncoherent and
are not mentioned in the commit message. They belong with patch 2/4,
which is where the callees became __init.

>  {
>      uint64_t reg;
>      int i, ret;
> @@ -1221,7 +1238,7 @@ static void gicv3_its_acpi_init(void)
>  
>  #endif
>  
> -int gicv3_its_init(void)
> +int __init gicv3_its_init(void)
>  {
>      struct host_its *hw_its;
>      int ret;
> diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
> index 35f93e4756..c6f17b9b2d 100644
> --- a/xen/arch/arm/gic-v3-lpi.c
> +++ b/xen/arch/arm/gic-v3-lpi.c
> @@ -7,7 +7,9 @@
>   * Copyright (C) 2016,2017 - ARM Ltd
>   */
>  
> +#include <xen/acpi.h>
>  #include <xen/cpu.h>
> +#include <xen/device_tree.h>
>  #include <xen/lib.h>
>  #include <xen/mm.h>
>  #include <xen/param.h>
> @@ -101,6 +103,20 @@ void __init gicv3_lpi_update_host_flags(uint32_t flags)
>      host_lpi_flags |= flags;
>  }
>  
> +static void __init gicv3_lpi_collect_fw_attrs(void)
> +{
> +    /*
> +     * A top-level GIC node property describes the Redistributor side of the
> +     * LPI path. Do not inherit it into per-ITS policy.
> +     */
> +    if ( !acpi_disabled ||
> +         !dt_property_read_bool(dt_interrupt_controller, "dma-noncoherent") )
> +        return;
> +
> +    gicv3_lpi_update_host_flags(GICV3_QUIRK_MEM_NC_NS);
> +    printk("GICv3: GIC node marked dma-noncoherent for host LPI tables\n");
> +}
> +
>  static union host_lpi *gic_get_host_lpi(uint32_t plpi)
>  {
>      union host_lpi *block;
> @@ -442,7 +458,7 @@ integer_param("max_lpi_bits", max_lpi_bits);
>   * to the page with the actual "union host_lpi" entries. Our LPI limit
>   * avoids excessive memory usage.
>   */
> -int gicv3_lpi_init_host_lpis(unsigned int host_lpi_bits)
> +int __init gicv3_lpi_init_host_lpis(unsigned int host_lpi_bits)
>  {
>      unsigned int nr_lpi_ptrs;
>      int rc;
> @@ -450,6 +466,10 @@ int gicv3_lpi_init_host_lpis(unsigned int host_lpi_bits)
>      /* We rely on the data structure being atomically accessible. */
>      BUILD_BUG_ON(sizeof(union host_lpi) > sizeof(unsigned long));
>  
> +    gicv3_lpi_collect_fw_attrs();
> +    if ( host_lpi_flags )
> +        printk("GICv3: host LPI workaround flags: %#x\n", host_lpi_flags);
Every contributor to host_lpi_flags already prints its own line -
"enabling workaround for ITS: %s" from the quirk path. Please drop this one.

~Michal

Re: [PATCH v2 2/4] xen/arm: its: separate ITS and host LPI quirk scopes

[Mykola Kvach]

Hi Michal,

Thanks for the follow-up.

On Fri, Jul 31, 2026 at 10:24:47AM +0200, Orzel, Michal wrote:
> 
> 
> On 28-May-26 02:25, Mykola Kvach wrote:
> > From: Mykola Kvach <mykola_kvach@epam.com>
> > 
> > ITS quirks can impose restrictions on memory accessed by the ITS itself and
> > on shared host LPI/Redistributor state. These scopes are not identical, so
> > a single global ITS quirk state makes the host LPI policy depend implicitly
> > on the quirks seen while initializing host ITSes.
> > 
> > Add per-ITS quirk_flags to struct host_its and keep a separate
> > host_lpi_flags state in the LPI code. The quirk table now records the
> > ITS-private and host LPI scopes explicitly through its_flags and lpi_flags.
> > The R-Car Gen4 quirk applies the same memory-related restrictions to both
> > scopes, preserving the existing behavior without relying on an implicit
> > aggregation step.
> > 
> > This also removes the old assumption that all host ITSes must expose the
> > same quirk state. Host LPI restrictions are accumulated only from quirk
> > entries that explicitly set lpi_flags.
> > 
> > Use per-ITS quirk_flags for GITS_CBASER, GITS_BASER<n> and ITT allocations.
> > Use host_lpi_flags directly in gic-v3-lpi.c for GICR_PROPBASER and
> > GICR_PENDBASER setup. Memory-related quirk bits are named GICV3_QUIRK_MEM_*
> > and are translated by shared gicv3_mem_get_*() helpers.
> > 
> > Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
> I already gave R-b for this patch but noticed two issues:
> 
> [...]
> 
> >  
> > -static void gicv3_its_enable_quirks(struct host_its *hw_its)
> > +static void __init gicv3_its_collect_quirks(struct host_its *hw_its)
> The only caller of gicv3_its_collect_quirks() is
> gicv3_its_init_single_its(), which stays non-init until patch 4/4.
> Please annotate the caller here as well.

I plan to replace the first patch, whose release fix is now upstream,
with the initialization-order follow-up discussed with Julien. It will
prepare all ITSes and collect their quirks, initialize host LPI state,
and then activate the ITSes.

I'll put the __init annotations on the ITS preparation and activation
functions, and gicv3_its_init(), in that replacement patch. This will
make the quirk collector's caller init-only before the quirk-scope
changes are introduced.

> 
> [...]
> 
> > @@ -157,6 +164,7 @@ int gicv3_lpi_init_rdist(void __iomem * rdist_base);
> >  /* Initialize the host structures for LPIs and the host ITSes. */
> >  int gicv3_lpi_init_host_lpis(unsigned int host_lpi_bits);
> >  int gicv3_its_init(void);
> > +void __init gicv3_lpi_update_host_flags(uint32_t flags);
> Please, do not add __init here for a prototype.

I'll also remove __init from the gicv3_lpi_update_host_flags() prototype
and keep it on the definition.

Best regards,
Mykola

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

[Mykola Kvach]

On Fri, Jul 31, 2026 at 10:34:11AM +0200, Orzel, Michal wrote:
> 
> 
> On 28-May-26 02:25, Mykola Kvach wrote:
> > From: Mykola Kvach <mykola_kvach@epam.com>
> > 
> > ITS quirks are currently matched only by IIDR and mask fields stored in
> > each table entry. That is too coarse for integrations where the same GIC
> > IP block can appear in several platforms but the workaround is only valid
> > for a subset of boards.
> > 
> > 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. The R-Car Gen4 platform refinement is DT-only;
> > ACPI-discovered ITSes do not match it.
> > 
> > Keep first-match semantics explicit. Assert that non-sentinel entries
> > provide a matcher and that IIDR matching receives match data, but keep
> > runtime guards so a malformed table entry does not become a NULL function
> > call or NULL data dereference in non-debug builds. 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@epam.com>
> > ---
> > 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 | 67 +++++++++++++++++++++++++++++++--------
> >  1 file changed, 53 insertions(+), 14 deletions(-)
> > 
> > diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
> > index dc48a84789..e055914763 100644
> > --- a/xen/arch/arm/gic-v3-its.c
> > +++ b/xen/arch/arm/gic-v3-its.c
> > @@ -53,8 +53,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
> > @@ -64,11 +64,48 @@ struct its_quirk {
> >      uint32_t lpi_flags;
> >  };
> >  
> > +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);
> > +
> > +    match = data;
> > +    iidr = readl_relaxed(hw_its->its_base + GITS_IIDR);
> > +
> > +    return (iidr & match->mask) == match->iidr;
> The commit message says you keep a runtime guard so malformed table data
> does not become a NULL data dereference in non-debug builds, but there is
> no such guard - ASSERT() compiles out and match->mask is then read from
> NULL.

You're right: ASSERT() alone does not provide the guard described in
the commit message. I'll add an explicit NULL check before the IIDR
match data is dereferenced, so it also works in non-debug builds.

> 
> > +}
> > +
> > +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") )
> Given that IIDR 0x0201743b is not Renesas-specific as you mention in the cover
> letter, this is a behavior changed and should be mentioned in the commit msg
> (cover letter is not in git).

I'll document the change from IIDR-only matching to platform-restricted
matching in the commit message, including its effect on ACPI and other
platforms.

> 
> > +        return false;
> > +
> > +    return gicv3_its_match_iidr(hw_its, data);
> > +}
> > +
> > +static const struct its_quirk_match_iidr rcar_gen4_iidr = {
> __initconst
> 
> > +    .iidr = 0x0201743b,
> > +    .mask = 0xffffffffU,
> > +};
> > +
> >  static const struct its_quirk its_quirks[] = {
> __initconstrel

I'll also mark the IIDR match data __initconst and the pointer-containing
quirk table __initconstrel.

Best regards,
Mykola

Re: [PATCH v2 4/4] xen/arm: its: handle dma-noncoherent on GIC and ITS nodes

[Mykola Kvach]

On Fri, Jul 31, 2026 at 10:39:54AM +0200, Orzel, Michal wrote:
> 
> 
> On 28-May-26 02:25, Mykola Kvach wrote:
> > From: Mykola Kvach <mykola_kvach@epam.com>
> > 
> > The DT dma-noncoherent property describes the bus coherency of the device
> > represented by the node. On an ITS subnode, that is memory accessed by that
> > ITS, so add GICV3_QUIRK_MEM_NC_NS to the corresponding host_its before
> > programming GITS tables and allocating ITTs.
> > 
> > When the property is present on the top-level GIC node, it describes the
> > Redistributor side of the LPI path. Collect it in
> > gicv3_lpi_init_host_lpis() and apply it only to the host LPI policy used
> > for GICR_PROPBASER and GICR_PENDBASER setup.
> > 
> > Do not inherit the property between parent and child nodes: ITS-node
> > non-coherency does not change the global host LPI policy, and GIC-node
> > non-coherency does not change per-ITS quirk_flags.
> > 
> > ACPI is left unchanged; this patch only consumes the DT dma-noncoherent
> > property.
> > 
> > Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
> > ---
> > Changes in v2:
> > - Split v1's dma-noncoherent handling into explicit ITS-node and GIC-node
> >   scopes.
> > - Apply an ITS subnode property only to the matching host_its quirk_flags.
> > - Collect the top-level GIC property from gic-v3-lpi.c before host LPI
> >   allocations use host_lpi_flags.
> > ---
> >  xen/arch/arm/gic-v3-its.c | 21 +++++++++++++++++++--
> >  xen/arch/arm/gic-v3-lpi.c | 22 +++++++++++++++++++++-
> >  2 files changed, 40 insertions(+), 3 deletions(-)
> > 
> > diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
> > index e055914763..606b127487 100644
> > --- a/xen/arch/arm/gic-v3-its.c
> > +++ b/xen/arch/arm/gic-v3-its.c
> > @@ -134,6 +134,21 @@ static const struct its_quirk *__init gicv3_its_find_quirk(
> >      return NULL;
> >  }
> >  
> > +static void __init gicv3_its_collect_fw_attrs(struct host_its *hw_its)
> > +{
> > +    /*
> > +     * An ITS subnode property describes memory transactions made by that ITS.
> > +     * Do not inherit it into the global host LPI/Redistributor policy.
> > +     */
> > +    if ( !hw_its->dt_node ||
> > +         !dt_property_read_bool(hw_its->dt_node, "dma-noncoherent") )
> > +        return;
> > +
> > +    hw_its->quirk_flags |= GICV3_QUIRK_MEM_NC_NS;
> > +    printk("GICv3: ITS @%#"PRIpaddr" marked dma-noncoherent\n",
> > +           hw_its->addr);
> > +}
> > +
> >  static void __init gicv3_its_collect_quirks(struct host_its *hw_its)
> >  {
> >      const struct its_quirk *quirk = gicv3_its_find_quirk(hw_its);
> > @@ -144,6 +159,8 @@ static void __init gicv3_its_collect_quirks(struct host_its *hw_its)
> >          gicv3_lpi_update_host_flags(quirk->lpi_flags);
> >          printk("GICv3: enabling workaround for ITS: %s\n", quirk->desc);
> >      }
> > +
> > +    gicv3_its_collect_fw_attrs(hw_its);
> >  }
> >  
> >  uint64_t gicv3_mem_get_cacheability(uint32_t flags)
> > @@ -578,7 +595,7 @@ static int gicv3_disable_its(struct host_its *hw_its)
> >      return -ETIMEDOUT;
> >  }
> >  
> > -static int gicv3_its_init_single_its(struct host_its *hw_its)
> > +static int __init gicv3_its_init_single_its(struct host_its *hw_its)
> These __init additions have nothing to do with dma-noncoherent and
> are not mentioned in the commit message. They belong with patch 2/4,
> which is where the callees became __init.

I'll move the ITS __init annotations out of this patch and into the
replacement first patch, so they precede the init-only quirk collectors

> 
> >  {
> >      uint64_t reg;
> >      int i, ret;
> > @@ -1221,7 +1238,7 @@ static void gicv3_its_acpi_init(void)
> >  
> >  #endif
> >  
> > -int gicv3_its_init(void)
> > +int __init gicv3_its_init(void)
> >  {
> >      struct host_its *hw_its;
> >      int ret;
> > diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
> > index 35f93e4756..c6f17b9b2d 100644
> > --- a/xen/arch/arm/gic-v3-lpi.c
> > +++ b/xen/arch/arm/gic-v3-lpi.c
> > @@ -7,7 +7,9 @@
> >   * Copyright (C) 2016,2017 - ARM Ltd
> >   */
> >  
> > +#include <xen/acpi.h>
> >  #include <xen/cpu.h>
> > +#include <xen/device_tree.h>
> >  #include <xen/lib.h>
> >  #include <xen/mm.h>
> >  #include <xen/param.h>
> > @@ -101,6 +103,20 @@ void __init gicv3_lpi_update_host_flags(uint32_t flags)
> >      host_lpi_flags |= flags;
> >  }
> >  
> > +static void __init gicv3_lpi_collect_fw_attrs(void)
> > +{
> > +    /*
> > +     * A top-level GIC node property describes the Redistributor side of the
> > +     * LPI path. Do not inherit it into per-ITS policy.
> > +     */
> > +    if ( !acpi_disabled ||
> > +         !dt_property_read_bool(dt_interrupt_controller, "dma-noncoherent") )
> > +        return;
> > +
> > +    gicv3_lpi_update_host_flags(GICV3_QUIRK_MEM_NC_NS);
> > +    printk("GICv3: GIC node marked dma-noncoherent for host LPI tables\n");
> > +}
> > +
> >  static union host_lpi *gic_get_host_lpi(uint32_t plpi)
> >  {
> >      union host_lpi *block;
> > @@ -442,7 +458,7 @@ integer_param("max_lpi_bits", max_lpi_bits);
> >   * to the page with the actual "union host_lpi" entries. Our LPI limit
> >   * avoids excessive memory usage.
> >   */
> > -int gicv3_lpi_init_host_lpis(unsigned int host_lpi_bits)
> > +int __init gicv3_lpi_init_host_lpis(unsigned int host_lpi_bits)
> >  {
> >      unsigned int nr_lpi_ptrs;
> >      int rc;
> > @@ -450,6 +466,10 @@ int gicv3_lpi_init_host_lpis(unsigned int host_lpi_bits)
> >      /* We rely on the data structure being atomically accessible. */
> >      BUILD_BUG_ON(sizeof(union host_lpi) > sizeof(unsigned long));
> >  
> > +    gicv3_lpi_collect_fw_attrs();
> > +    if ( host_lpi_flags )
> > +        printk("GICv3: host LPI workaround flags: %#x\n", host_lpi_flags);
> Every contributor to host_lpi_flags already prints its own line -
> "enabling workaround for ITS: %s" from the quirk path. Please drop this one.

I'll drop the aggregate host-LPI-flags message and keep the per-source
diagnostics.

Best regards,
Mykola