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

[sashiko-bot@kernel.org]

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():

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.

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