From nobody Sat Feb 7 19:08:31 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 91F1017D6 for ; Mon, 19 Jan 2026 20:16:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768853775; cv=none; b=tmmHzChsb0mzt1ZVdhc0A8WvxR34X21g0qI/Rr6C603JpZQMg+giKo6EBdyzMgp+n0VXl/yVX/lqkquO8EEBjkea3DcF3OelTIPa3THfAI/JtOyu9tWJNc1nobY+wMgu0XVUD7eqgBxIfTeB01kEmLzh/gR9RYZyztnH879n4xc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768853775; c=relaxed/simple; bh=r+lnFo9qZeEary3vJZbx0ODSSfcyPTnIWTCVuJs92dg=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=noJJF+IoMrYVGLPsCb25FFWK7fy1Xvd7pchRm2RZPo4hJSGgE33wHp2pbPv9AmhIgvCPWUAUODXOv3zHBLkJQheMnDpMGQN/s3gIF2MfEJXkbcliPre4uH/1jXv1qyiogn+iB3QYdJEm5AkDZOTt3Meoo84hua1AhfEovlJLJ9g= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=LGFzFYKb; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="LGFzFYKb" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AFAB4C116C6; Mon, 19 Jan 2026 20:16:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768853775; bh=r+lnFo9qZeEary3vJZbx0ODSSfcyPTnIWTCVuJs92dg=; h=From:To:Cc:Subject:Date:From; b=LGFzFYKbYh/RKOtiPm/dKkJJeJuwcAn6CP0LXRZDFxW5oGtKMmf6b3DX5rnE6MkH1 88SrP2ZZcrykDp3fG+5O1Wl3MzvUgkldFeDIfsWlR22EgCBXj+CKKsqkhm+oLiHvSE BXAAOPUZGnzSTLlsgf11jTPm/tSm0rOOhbaQxIebT1WI7DlxPXFu6ehD6PGX6DHUEG w7FRDv5q0uiExGa8eOjKaxE74nX6d4LJmHzOjYhAkU8REmtrKxlVKtMAh56G2XUQNR Y9IMKF/zqaQsEuPcVAKy63LVG8OXc3BB1obGOqEs0mJ2W/LWuQNng/kDSN8gkVkUcq opQsxVN+umY7A== From: Arnd Bergmann To: Marc Zyngier , Thomas Gleixner Cc: Arnd Bergmann , Lorenzo Pieralisi , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: [PATCH] irqchip: gic-v3-its: avoid truncating memory addresses Date: Mon, 19 Jan 2026 21:15:12 +0100 Message-Id: <20260119201603.2713066-1-arnd@kernel.org> X-Mailer: git-send-email 2.39.5 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Arnd Bergmann On 32-bit machines with CONFIG_ARM_LPAE, it is possible for lowmem allocations to be backed by addresses physical memory above the 32-bit address limit, as I found while experimenting with larger VMSPLIT configurations. This caused the qemu virt model to crash in the GICv3 driver, which allocates the 'itt' object using GFP_KERNEL. Since all memory below the 4GB physical address limit is in ZONE_DMA in this configuration, kmalloc defaults to higher addresses for ZONE_NORMAL, and the its driver stores the physical address in a 32-bit 'unsigned long' variable. Change the itt_addr variable to the correct phys_addr_t type instead, along with all other variables in this driver that hold a physical address. I checked the gicv5 driver for the same problem, and it correctly uses u64 variables, while all other irqchip drivers don't call virt_to_phys or similar interfaces. I expect other drivers to have similar issues, but fixing this one is sufficient for booting a virtio based guest. Fixes: cc2d3216f53c ("irqchip: GICv3: ITS command queue") Signed-off-by: Arnd Bergmann Reviewed-by: Marc Zyngier --- drivers/irqchip/irq-gic-v3-its.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-= its.c index ada585bfa451..2988def30972 100644 --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -709,7 +709,7 @@ static struct its_collection *its_build_mapd_cmd(struct= its_node *its, struct its_cmd_block *cmd, struct its_cmd_desc *desc) { - unsigned long itt_addr; + phys_addr_t itt_addr; u8 size =3D ilog2(desc->its_mapd_cmd.dev->nr_ites); =20 itt_addr =3D virt_to_phys(desc->its_mapd_cmd.dev->itt); @@ -879,7 +879,7 @@ static struct its_vpe *its_build_vmapp_cmd(struct its_n= ode *its, struct its_cmd_desc *desc) { struct its_vpe *vpe =3D valid_vpe(its, desc->its_vmapp_cmd.vpe); - unsigned long vpt_addr, vconf_addr; + phys_addr_t vpt_addr, vconf_addr; u64 target; bool alloc; =20 @@ -2477,10 +2477,10 @@ static int its_setup_baser(struct its_node *its, st= ruct its_baser *baser, baser->psz =3D psz; tmp =3D indirect ? GITS_LVL1_ENTRY_SIZE : esz; =20 - pr_info("ITS@%pa: allocated %d %s @%lx (%s, esz %d, psz %dK, shr %d)\n", + pr_info("ITS@%pa: allocated %d %s @%llx (%s, esz %d, psz %dK, shr %d)\n", &its->phys_base, (int)(PAGE_ORDER_TO_SIZE(order) / (int)tmp), its_base_type_string[type], - (unsigned long)virt_to_phys(base), + (u64)virt_to_phys(base), indirect ? "indirect" : "flat", (int)esz, psz / SZ_1K, (int)shr >> GITS_BASER_SHAREABILITY_SHIFT); =20 --=20 2.39.5