Message ID | 1600112240-31726-1-git-send-email-olekstysh@gmail.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | SUPPORT.md: Mark Renesas IPMMU-VMSA (Arm) as supported | expand |
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,
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
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.
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.
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