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

[Milan Djokic <milan_djokic@xxxxxxxx>]

Hi Julien,

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.
> Overall, I would rather not add any extra code in Xen without any strong
> use case.
>
> Cheers,
BR,
Milan