Re: [PATCH v8 22/25] iommu/arm-smmu-v3-kvm: Shadow the CPU stage-2 page table

[Mostafa Saleh <smostafa@google.com>]

On Tue, Sep 22, 2026 at 01:38:15PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] arm-smmu-v3-kvm: panic on EL2 allocation failure during STE reshadow
> --
> 
> commit 866d2f52e473ce62e2402494a1198d807826d481
> Author: Mostafa Saleh <smostafa@google.com>
> Subject: iommu/arm-smmu-v3-kvm: Shadow the CPU stage-2 page table
> 
> The hypervisor calls back into the driver on every change to the host
> stage-2 page table.
> Mirror those changes into an identity mapped stage-2 for the SMMUv3,
> That would be attached to all active SIDs.
> 
> [ ... ]
> 
> > diff --git a/drivers/iommu/arm/arm-smmu-v3/pkvm/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/pkvm/arm-smmu-v3.c
> > index 6e023e968ed3a..6f0ea3a4e48df 100644
> > --- a/drivers/iommu/arm/arm-smmu-v3/pkvm/arm-smmu-v3.c
> > +++ b/drivers/iommu/arm/arm-smmu-v3/pkvm/arm-smmu-v3.c
> 
> [ ... ]
> 
> [Severity: High]
> Can a routine allocation failure lead to a hypervisor panic here?
> 
> Looking at smmu_reshadow_ste() in drivers/iommu/arm/arm-smmu-v3/pkvm/arm-smmu-v3.c,
> the dynamic allocation can legitimately fail with -ENOMEM when the pool is
> exhausted:
> 
> drivers/iommu/arm/arm-smmu-v3/pkvm/arm-smmu-v3.c:smmu_reshadow_ste() {
> 	...
> 			l2table = pkvm_iommu_alloc_pages(get_order(sizeof(*l2table)));
> 			if (!l2table)
> 				return -ENOMEM;
> 	...
> }
> 
> This -ENOMEM error is mapped to a true return value in smmu_filter_command():
> 

-ENOMEM shouldn't happen here as the pool should cover the worst case
and there is no way to recover from it so it panics.

> drivers/iommu/arm/arm-smmu-v3/pkvm/arm-smmu-v3.c:smmu_filter_command() {
> 	...
> 		ret = smmu_reshadow_ste(smmu, sid, leaf);
> 		hyp_spin_lock(&smmu->hw_lock);
> 		if (ret)
> 			return true;
> 	...
> }
> 
> Which is then wrapped in a WARN_ON() in smmu_emulate_cmdq_insert():
> 
> drivers/iommu/arm/arm-smmu-v3/pkvm/arm-smmu-v3.c:smmu_emulate_cmdq_insert() {
> 	...
> 		skip = smmu_filter_command(smmu, cmd);
> 		if (WARN_ON(skip))
> 			continue;
> 	...
> }
> 
> Does this WARN_ON() turn the -ENOMEM condition into a fatal hypervisor
> panic?
> 
> At EL2, WARN_ON() expands to a fatal BRK instruction, crashing the hypervisor.
> Host userspace processes can trigger this path (e.g., via VFIO device
> assignment) by configuring multiple devices to exhaust the L2 table pool,
> leading to a host-userspace-reachable panic.

User space can not invent new SIDs, the kernel need to allocate for
those regardless.

Thanks,
Mostafa

> 
> Could this be updated to handle hyp_alloc_pages() failures without
> triggering a fatal assertion?
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260922131259.2975334-1-smostafa@google.com?part=22