Re: [PATCH v2 02/23] xen/arm: smmuv3: Add support for stage-1 and nested stage translation

[Bertrand Marquis <Bertrand.Marquis@xxxxxxx>]

Hi,

> On 10 Jun 2026, at 18:24, Julien Grall <julien@xxxxxxx> wrote:
> 
> 
> 
> On 08/06/2026 10:25, Milan Djokic wrote:
>> Hi Julien,
> 
> Hi Milan,
>> On 5/24/26 13:00, Julien Grall wrote:
>>> Hi Milan,
>>> 
>>> On 28/04/2026 11:16, Milan Djokic wrote:
>>>>>> The original idea was to also allow stage-1-only support. But I'm not
>>>>>> sure if stage-1-only usecase is useful or even valid for Xen.. I will
>>>>>> update the patch series with the missing parts for stage-1-only support,
>>>>>> pointed out by Luca, but the question remains if this is needed at all.
>>>>>> If not, I can revert to original state where stage-2 was always
>>>>>> required.
>>>>> 
>>>>> By "stage-1 only" support, do you mean Xen would use the stage-1 in
>>>>> replacement of the stage-2? Or do you mean the guest will use the
>>>>> stage-1 page-table and there will be no isolation from Xen?
>>>>> 
>>>>> If the former, then I believe the page tables don't have the exact same
>>>>> format. Today, the page-tables are shared between the CPU and IOMMU, so
>>>>> this would need to be duplicated. For now, I am not sure this is worth
>>>>> to do.
>>>>> 
>>>>> If the latter, this would require the guest to be directly mapped (i.e.
>>>>> IPA == PA) but it would also open a big hole. So I would want to
>>>>> understand the exact use case first.
>>>>> 
>>>> 
>>>> The latter. In this case, the guest would configure stage-1 while
>>>> stage-2 translation is not used, so there is no additional isolation
>>>> enforced by Xen. This would only be intended for specific usecases with
>>>> trusted domains. But yes, this opens a significant hole if used with
>>>> untrusted guests. If there is no strong usecase, we could restrict the
>>>> implementation to always require stage-2.
>>> 
>>> It is still unclear what would be the exact use-case. Is it a system
>>> where the SMMU doesn't support stage-2? Performance reason?
>>> 
>> This primarily targets systems where the SMMU does not support Stage-2 
>> translation.
>> If we decide to keep this code, I will address the associated security 
>> considerations and document the corresponding AoU in the design. Otherwise, 
>> we can fall back to supporting only the "nested" translation case.
> 
> Thanks for the feedback. I think for such setup, I would consider whether we 
> can use the stage-1 in Xen to protect the device. AFAIK, this what Linux will 
> do.
> 
> I would be interested to hear what the other maintainers think.

Giving access to the smmu to a guest means giving it a solution to access 
whatever he wants through a DMA engine.
This is not less secure than no SMMU at all but I would definitely think that 
in such a case SMMU should be reserved for
Xen to use it to protect from accessing other guests memory using DMA.

Now i know that in some setups there are cases where a specific device cannot 
be used without an SMMU (mostly GPUs
but there might be others). In that case, the device cannot be used easily if 
the kernel cannot use the SMMU to remap the
memory at a convenient place for the device.

We should not disallow such cases completely but we should give strong 
recommandations when such a setup is used.

Cheers
Bertrand

> 
> Cheers,
> 
> -- 
> Julien Grall