Re: [PATCH v9 19/25] iommu/arm-smmu-v3-kvm: Share other queues

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] iommu/arm-smmu-v3-kvm: EL2 panic on kexec due to locked EVTQ/PRIQ base addresses
--

commit bfd6e271a581b5d4148ccc397cc5a82480d46470
Author: Mostafa Saleh <smostafa@google.com>

    iommu/arm-smmu-v3-kvm: Share other queues

This commit introduces pinning and sharing of the event and PRI queues in the
hypervisor to prevent the host from writing to protected memory. It enforces
that the host cannot change the base addresses of these queues once they are
shared.

> diff --git a/drivers/iommu/arm/arm-smmu-v3/pkvm/arm-smmu-v3-hyp.c b/drivers/iommu/arm/arm-smmu-v3/pkvm/arm-smmu-v3-hyp.c
> index 132f3a9ba3084..1972df1d2a8dc 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/pkvm/arm-smmu-v3-hyp.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/pkvm/arm-smmu-v3-hyp.c
[ ... ]
> @@ -806,6 +852,34 @@ static bool smmu_dabt_device(struct hyp_arm_smmu_v3_device *smmu,
>  
>  		mask = read_write;
>  		break;
> +	case ARM_SMMU_EVTQ_BASE:
> +		if (len != sizeof(u64))
> +			break;
> +
> +		if (is_write) {
> +			/* See ARM_SMMU_CR0 */
> +			if (is_evtq_enabled(smmu) ||
> +			    (smmu->evtq_shared && smmu->evtq_base != val))
> +				break;

[Severity: High]
Does this rigid check prevent the host from performing a successful kexec?

When the host executes a kexec, the new kernel boots and initializes its own
SMMUv3 driver, allocating new memory for the EVTQ and writing the new base
address here. Since EL2 state persists across kexec and the hypervisor never
clears smmu->evtq_shared upon disable, this condition evaluates to true.

The break leaves mask = 0, which then triggers the WARN_ON(!mask) at the end
of the handler, resulting in a fatal hypervisor panic.

> +			smmu->evtq_base = val;
> +		}
> +		mask = read_write;
> +		break;
> +
> +	case ARM_SMMU_PRIQ_BASE:
> +		if (len != sizeof(u64))
> +			break;
> +
> +		if (is_write) {
> +			/* See ARM_SMMU_CR0 */
> +			if (is_priq_enabled(smmu) ||
> +			    (smmu->priq_shared && smmu->priq_base != val))
> +				break;

[Severity: High]
Similarly, does this check for the PRIQ base address cause the hypervisor to
panic during kexec?

Just like EVTQ, the new kernel initialized during kexec will write a new
PRIQ base address, triggering this break and hitting the same fatal
WARN_ON(!mask) further down.

> +			smmu->priq_base = val;
> +		}
> +		mask = read_write;
> +		break;
> +

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261015200903.2735565-1-smostafa@google.com?part=19