Mailing List Archive

[PATCH] SUPPORT.md: Mark Renesas IPMMU-VMSA (Arm) as supported
From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>

And remove dependencies on CONFIG_EXPERT.

Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
---
SUPPORT.md | 2 +-
xen/arch/arm/platforms/Kconfig | 2 +-
xen/drivers/passthrough/Kconfig | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/SUPPORT.md b/SUPPORT.md
index 1479055..5a96a12 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -64,7 +64,7 @@ supported in this document.
Status, Intel VT-d: Supported
Status, ARM SMMUv1: Supported
Status, ARM SMMUv2: Supported
- Status, Renesas IPMMU-VMSA: Tech Preview
+ Status, Renesas IPMMU-VMSA: Supported

### ARM/GICv3 ITS

diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/Kconfig
index 4bb7319..c93a6b2 100644
--- a/xen/arch/arm/platforms/Kconfig
+++ b/xen/arch/arm/platforms/Kconfig
@@ -25,7 +25,7 @@ config RCAR3
bool "Renesas RCar3 support"
depends on ARM_64
select HAS_SCIF
- select IPMMU_VMSA if EXPERT
+ select IPMMU_VMSA
---help---
Enable all the required drivers for Renesas RCar3

diff --git a/xen/drivers/passthrough/Kconfig b/xen/drivers/passthrough/Kconfig
index 73f4ad8..0036007 100644
--- a/xen/drivers/passthrough/Kconfig
+++ b/xen/drivers/passthrough/Kconfig
@@ -14,7 +14,7 @@ config ARM_SMMU
ARM SMMU architecture.

config IPMMU_VMSA
- bool "Renesas IPMMU-VMSA found in R-Car Gen3 SoCs" if EXPERT
+ bool "Renesas IPMMU-VMSA found in R-Car Gen3 SoCs"
depends on ARM_64
---help---
Support for implementations of the Renesas IPMMU-VMSA found
--
2.7.4
Re: [PATCH] SUPPORT.md: Mark Renesas IPMMU-VMSA (Arm) as supported [ In reply to ]
Hi Oleksandr,

On 14/09/2020 20:37, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>
> And remove dependencies on CONFIG_EXPERT.

In order to help to make the decision, can you provide the following
information:
- Is it functionally complete?
- Can it work on all known platforms with IPMMU VMSA?
- Is there any plan to smoke (manually or automatically) test the
driver?

> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
> ---
> SUPPORT.md | 2 +-
> xen/arch/arm/platforms/Kconfig | 2 +-
> xen/drivers/passthrough/Kconfig | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/SUPPORT.md b/SUPPORT.md
> index 1479055..5a96a12 100644
> --- a/SUPPORT.md
> +++ b/SUPPORT.md
> @@ -64,7 +64,7 @@ supported in this document.
> Status, Intel VT-d: Supported
> Status, ARM SMMUv1: Supported
> Status, ARM SMMUv2: Supported
> - Status, Renesas IPMMU-VMSA: Tech Preview
> + Status, Renesas IPMMU-VMSA: Supported

Not entirely directed to the IPMMU-VMSA. Passthrough is not security
supported on Arm today, so it is a bit odd to make the IOMMU drivers
security supported.

I am thinking to downgrade the ARM SMMUv{1, 2} to "supported, not
security supported" to avoid any confusion if a potential security issue
arise.

Stefano, what do you think?

>
> ### ARM/GICv3 ITS
>
> diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/Kconfig
> index 4bb7319..c93a6b2 100644
> --- a/xen/arch/arm/platforms/Kconfig
> +++ b/xen/arch/arm/platforms/Kconfig
> @@ -25,7 +25,7 @@ config RCAR3
> bool "Renesas RCar3 support"
> depends on ARM_64
> select HAS_SCIF
> - select IPMMU_VMSA if EXPERT
> + select IPMMU_VMSA
> ---help---
> Enable all the required drivers for Renesas RCar3
>
> diff --git a/xen/drivers/passthrough/Kconfig b/xen/drivers/passthrough/Kconfig
> index 73f4ad8..0036007 100644
> --- a/xen/drivers/passthrough/Kconfig
> +++ b/xen/drivers/passthrough/Kconfig
> @@ -14,7 +14,7 @@ config ARM_SMMU
> ARM SMMU architecture.
>
> config IPMMU_VMSA
> - bool "Renesas IPMMU-VMSA found in R-Car Gen3 SoCs" if EXPERT
> + bool "Renesas IPMMU-VMSA found in R-Car Gen3 SoCs"
> depends on ARM_64
> ---help---
> Support for implementations of the Renesas IPMMU-VMSA found
>

Cheers,

--
Julien Grall
Re: [PATCH] SUPPORT.md: Mark Renesas IPMMU-VMSA (Arm) as supported [ In reply to ]
On Wed, Sep 16, 2020 at 8:02 PM Julien Grall <julien@xen.org> 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@epam.com>
> >
> > 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

--
Regards,

Oleksandr Tyshchenko
Re: [PATCH] SUPPORT.md: Mark Renesas IPMMU-VMSA (Arm) as supported [ In reply to ]
On Wed, 16 Sep 2020, Julien Grall wrote:
> Hi Oleksandr,
>
> On 14/09/2020 20:37, Oleksandr Tyshchenko wrote:
> > From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
> >
> > And remove dependencies on CONFIG_EXPERT.
>
> In order to help to make the decision, can you provide the following
> information:
> - Is it functionally complete?
> - Can it work on all known platforms with IPMMU VMSA?
> - Is there any plan to smoke (manually or automatically) test the driver?
>
> > Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
> > ---
> > SUPPORT.md | 2 +-
> > xen/arch/arm/platforms/Kconfig | 2 +-
> > xen/drivers/passthrough/Kconfig | 2 +-
> > 3 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/SUPPORT.md b/SUPPORT.md
> > index 1479055..5a96a12 100644
> > --- a/SUPPORT.md
> > +++ b/SUPPORT.md
> > @@ -64,7 +64,7 @@ supported in this document.
> > Status, Intel VT-d: Supported
> > Status, ARM SMMUv1: Supported
> > Status, ARM SMMUv2: Supported
> > - Status, Renesas IPMMU-VMSA: Tech Preview
> > + Status, Renesas IPMMU-VMSA: Supported
>
> Not entirely directed to the IPMMU-VMSA. Passthrough is not security supported
> on Arm today, so it is a bit odd to make the IOMMU drivers security supported.
>
> I am thinking to downgrade the ARM SMMUv{1, 2} to "supported, not security
> supported" to avoid any confusion if a potential security issue arise.
>
> Stefano, what do you think?

Yes, I agree.
Re: [PATCH] SUPPORT.md: Mark Renesas IPMMU-VMSA (Arm) as supported [ In reply to ]
On Thu, 17 Sep 2020, Oleksandr Tyshchenko wrote:
> On Wed, Sep 16, 2020 at 8:02 PM Julien Grall <julien@xen.org> 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@epam.com>
> >
> > 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.