Re: [PATCH] SUPPORT.md: Mark Renesas IPMMU-VMSA (Arm) as supported

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Thu, 17 Sep 2020, Oleksandr Tyshchenko wrote:
> On Wed, Sep 16, 2020 at 8:02 PM Julien Grall <julien@xxxxxxx> wrote:
>       Hi Oleksandr,
> 
> 
> Hi Julien
> 
> [sorry for the possible format issues]
>  
> 
>       On 14/09/2020 20:37, Oleksandr Tyshchenko wrote:
>       > From: Oleksandr Tyshchenko <oleksandr_tyshchenko@xxxxxxxx>
>       >
>       > And remove dependencies on CONFIG_EXPERT.
> 
>       In order to help to make the decision, can you provide the following
>       information:
>           - Is it functionally complete?
> 
>  
> I think, yes. At least I am not aware of any remaining issues which prevent 
> us from using Xen driver normally these days.
> There was one important issue related to the known R-Car Gen3 IPMMU-VMSA 
> limitation to handle maximum 40-bit IPA only (so 4-level
> translation table is not supported) and
> this issue didn't allow us to have the Xen driver *completely* functional. 
> Hopefully, we have already found a proper way to handle this in
> Xen on Arm [1]:
>  
>           - Can it work on all known platforms with IPMMU VMSA?
> 
>  
> I don't think Xen driver will work on all known platforms with the IPMMU-VMSA.
> Xen driver is supposed to be used with newest R-Car Gen3 SoC revisions only 
> (H3 ES3.0, M3-W+, etc.) which IPMMU H/W supports stage 2
> translation
> table format (to be able to share the P2M with the CPU). On older SoC 
> revisions it won't work (driver performs a special check at the
> initialization time to see whether
> the P2M sharing is supported in current SoC revision). Being honest, the 
> R-Car Gen3 family is not limited by these 3 SoCs (H3, M3-W+, M3N)
> the driver is looking for.
> There are other SoCs: E3, D3, V3H, V3M, etc, which are quite new and likely 
> have a *proper* IPMMU H/W to be used in Xen. But, I don't have
> a possibility to check
> them in order to be 100% sure and extend a number of supported SoCs in the 
> driver.
>  
>           - Is there any plan to smoke (manually or automatically) test the 
> driver?
> 
>  
> Yes, there is a plan to perform manual tests. Actually, this is what we 
> usually do in the context of our development.
> After all, device passthrough is one of the important features and keeping 
> this driver in a functional state is our target.
> 
> [1]  
> https://lists.xenproject.org/archives/html/xen-devel/2019-09/msg02967.html

Keeping in mind what Julien wrote in his reply about security support, I
think it only makes sense to change IPMMU-VMSA to "Supported, not
security supported".

In that regard, also reading your answer, I think it is OK to make the
change.