From: Steven Price <steven.price@arm.com>
To: "Christian König" <christian.koenig@amd.com>,
"Marc Zyngier" <maz@kernel.org>,
"Sumit Semwal" <sumit.semwal@linaro.org>,
"Thomas Gleixner" <tglx@kernel.org>
Cc: "T.J. Mercier" <tjmercier@google.com>,
Benjamin Gaignard <benjamin.gaignard@collabora.com>,
Brian Starkey <Brian.Starkey@arm.com>,
John Stultz <jstultz@google.com>,
dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
Jason Gunthorpe <jgg@ziepe.ca>, Jiri Pirko <jiri@resnulli.us>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>
Subject: Re: [PATCH v2 2/4] irqchip/gic-v3-its: Allocate VPE tables from sleepable context
Date: Thu, 20 Aug 2026 16:46:14 +0100 [thread overview]
Message-ID: <c25502d3-35c6-4281-a9ec-856f789fb1b4@arm.com> (raw)
In-Reply-To: <20260820150034.88729-3-steven.price@arm.com>
On 20/08/2026 16:00, Steven Price wrote:
> The VPE L1 table is allocated from the CPU-starting hotplug state,
> where interrupts are disabled. Although the page allocation uses
> GFP_ATOMIC, its_alloc_pages() subsequently calls
> set_memory_decrypted(), which can sleep while splitting the arm64
> linear map.
>
> Move the allocation to the existing CPU-online callback, which runs in
> sleepable context, and use GFP_KERNEL for both allocations performed
> there. Register the callback even without EFI, since it is now also
> responsible for VPE table allocation.
Ok, Sashiko pointed out this is bunk:
> Does moving this allocation to the CPUHP_AP_ONLINE_DYN callback expose
> uninitialized GICv4.1 redistributor state to concurrent VPE mappings?
>
> The CPUHP_AP_ONLINE_DYN state runs for its_cpu_memreserve_lpi() in the hotplug
> thread asynchronously after the CPU has already been marked online in
> cpu_online_mask.
>
> Could a concurrent process changing IRQ affinities (like irqbalance) observe
> the CPU in cpu_online_mask and route a virtual interrupt to it via
> its_vpe_set_affinity() before the hotplug thread has executed this table
> allocation?
>
> If a VMAPP command executes before allocate_vpe_l1_table() programs the
> GICR_VPROPBASER, it appears the hardware could use stale or uninitialized
> physical addresses, leading to unpredictable behavior or dropped interrupts.
Please ignore this patch. I thought this was a bit too simple to fix :(
I guess some sort of preallocation might be the solution.
Thanks,
Steve
> Fixes: b08e2f42e86b ("irqchip/gic-v3-its: Share ITS tables with a non-trusted hypervisor")
> Signed-off-by: Steven Price <steven.price@arm.com>
> ---
> drivers/irqchip/irq-gic-v3-its.c | 30 +++++++++++++++---------------
> 1 file changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index a055837832bc..71515dbff9ec 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -2932,7 +2932,7 @@ static int allocate_vpe_l1_table(void)
> if (val & GICR_VPROPBASER_4_1_VALID)
> goto out;
>
> - gic_data_rdist()->vpe_table_mask = kzalloc_obj(cpumask_t, GFP_ATOMIC);
> + gic_data_rdist()->vpe_table_mask = kzalloc_obj(cpumask_t, GFP_KERNEL);
> if (!gic_data_rdist()->vpe_table_mask)
> return -ENOMEM;
>
> @@ -2999,7 +2999,7 @@ static int allocate_vpe_l1_table(void)
>
> pr_debug("np = %d, npg = %lld, psz = %d, epp = %d, esz = %d\n",
> np, npg, psz, epp, esz);
> - page = its_alloc_pages(GFP_ATOMIC | __GFP_ZERO, get_order(np * PAGE_SIZE));
> + page = its_alloc_pages(GFP_KERNEL | __GFP_ZERO, get_order(np * PAGE_SIZE));
> if (!page)
> return -ENOMEM;
>
> @@ -3268,16 +3268,6 @@ static void its_cpu_init_lpis(void)
> val = its_clear_vpend_valid(vlpi_base, 0, 0);
> }
>
> - if (allocate_vpe_l1_table()) {
> - /*
> - * If the allocation has failed, we're in massive trouble.
> - * Disable direct injection, and pray that no VM was
> - * already running...
> - */
> - gic_rdists->has_rvpeid = false;
> - gic_rdists->has_vlpis = false;
> - }
> -
> /* Make sure the GIC has seen the above */
> dsb(sy);
> gic_data_rdist()->flags |= RD_LOCAL_LPI_ENABLED;
> @@ -5452,6 +5442,19 @@ static int its_cpu_memreserve_lpi(unsigned int cpu)
> if (gic_data_rdist()->flags & RD_LOCAL_MEMRESERVE_DONE)
> return 0;
>
> + if (allocate_vpe_l1_table()) {
> + /*
> + * If the allocation has failed, we're in massive trouble.
> + * Disable direct injection, and pray that no VM was
> + * already running...
> + */
> + gic_rdists->has_rvpeid = false;
> + gic_rdists->has_vlpis = false;
> + }
> +
> + if (!efi_enabled(EFI_CONFIG_TABLES))
> + goto out;
> +
> pend_page = gic_data_rdist()->pend_page;
> if (WARN_ON(!pend_page)) {
> ret = -ENOMEM;
> @@ -5793,9 +5796,6 @@ int __init its_lpi_memreserve_init(void)
> {
> int state;
>
> - if (!efi_enabled(EFI_CONFIG_TABLES))
> - return 0;
> -
> if (list_empty(&its_nodes))
> return 0;
>
next prev parent reply other threads:[~2026-08-20 15:46 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-20 15:00 [PATCH v2 0/4] Clear shared pages after private-to-shared conversion Steven Price
2026-08-20 15:00 ` [PATCH v2 1/4] irqchip/gic-v3-its: Zero shared pages after conversion Steven Price
2026-08-20 15:00 ` [PATCH v2 2/4] irqchip/gic-v3-its: Allocate VPE tables from sleepable context Steven Price
2026-08-20 15:46 ` Steven Price [this message]
2026-08-20 15:00 ` [PATCH v2 3/4] dma-buf: heaps: Zero system shared heap pages after conversion Steven Price
2026-08-20 15:00 ` [PATCH v2 4/4] dma-buf: heaps: Fix shared system heap allocation rollback Steven Price
2026-08-20 16:56 ` Jason Gunthorpe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c25502d3-35c6-4281-a9ec-856f789fb1b4@arm.com \
--to=steven.price@arm.com \
--cc=Brian.Starkey@arm.com \
--cc=benjamin.gaignard@collabora.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jgg@ziepe.ca \
--cc=jiri@resnulli.us \
--cc=jstultz@google.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=maz@kernel.org \
--cc=sumit.semwal@linaro.org \
--cc=suzuki.poulose@arm.com \
--cc=tglx@kernel.org \
--cc=tjmercier@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox