xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@arm.com>
To: Oleksandr Tyshchenko <olekstysh@gmail.com>,
	xen-devel@lists.xenproject.org
Cc: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
	Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>,
	sstabellini@kernel.org, Volodymyr_Babchuk@epam.com
Subject: Re: [Xen-devel] [PATCH V3 8/8] iommu/arm: Add Renesas IPMMU-VMSA support
Date: Mon, 9 Sep 2019 22:24:38 +0100	[thread overview]
Message-ID: <2b1d815c-720d-46c1-04de-0b8eb627b22f@arm.com> (raw)
In-Reply-To: <1566324587-3442-9-git-send-email-olekstysh@gmail.com>

Hi Oleksandr,

On 8/20/19 7:09 PM, Oleksandr Tyshchenko wrote:
> diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/Kconfig
> index bc0e9cd..c93a6b2 100644
> --- a/xen/arch/arm/platforms/Kconfig
> +++ b/xen/arch/arm/platforms/Kconfig
> @@ -25,6 +25,7 @@ config RCAR3
>   	bool "Renesas RCar3 support"
>   	depends on ARM_64
>   	select HAS_SCIF
> +	select IPMMU_VMSA

As discussed previously, I think the IPMMU driver should be merged as 
tech preview for a couple of release to allow more users to test before 
we mark it as supported.

Based on this, I would not advise to select IPMMU_VMSA by default as 
user may not want to use tech preview code by default. Instead I would 
only select if EXPERT is set.

>   	---help---
>   	Enable all the required drivers for Renesas RCar3
>   
> diff --git a/xen/drivers/passthrough/Kconfig b/xen/drivers/passthrough/Kconfig
> index a3c0649..47eadb4 100644
> --- a/xen/drivers/passthrough/Kconfig
> +++ b/xen/drivers/passthrough/Kconfig
> @@ -12,4 +12,17 @@ config ARM_SMMU
>   
>   	  Say Y here if your SoC includes an IOMMU device implementing the
>   	  ARM SMMU architecture.
> +
> +config IPMMU_VMSA
> +	bool "Renesas IPMMU-VMSA found in R-Car Gen3 SoCs"
> +	default n
> +	depends on ARM_64
> +	---help---
> +	  Support for implementations of the Renesas IPMMU-VMSA found
> +	  in R-Car Gen3 SoCs.
> +
> +	  Say Y here if you are using newest R-Car Gen3 SoCs revisions
> +	  (H3 ES3.0, M3-W+, etc) which IPMMU hardware supports stage 2
> +	  translation table format and is able to use CPU's P2M table as is.
> +
>   endif

[...]

> +    /* Wait until the Root device has been registered for sure. */
> +    if ( !mmu->root )
> +    {
> +        dev_err(&node->dev, "Root IPMMU hasn't been registered yet\n");

This is a bit odd to throw an error if we are going to defer the probe.

> +        ret = -EAGAIN;
> +        goto out;
> +    }

[...]

> +static __init bool ipmmu_stage2_supported(void)
> +{
> +    struct dt_device_node *np;
> +    uint64_t addr, size;
> +    void __iomem *base;
> +    uint32_t product, cut;
> +    static enum
> +    {
> +        UNKNOWN,
> +        SUPPORTED,
> +        NOTSUPPORTED
> +    } stage2_supported = UNKNOWN;
> +
> +    /* Use the flag to avoid checking for the compatibility more then once. */

There are only one IOMMU root that will always be initialized first. So 
can't you move this code in the root IOMMU path?

> +    switch ( stage2_supported )
> +    {
> +    case SUPPORTED:
> +        return true;
> +
> +    case NOTSUPPORTED:
> +        return false;
> +
> +    case UNKNOWN:
> +    default:
> +        stage2_supported = NOTSUPPORTED;
> +        break;
> +    }
> +
> +    np = dt_find_compatible_node(NULL, NULL, "renesas,prr");
> +    if ( !np )
> +    {
> +        printk(XENLOG_ERR "ipmmu: Failed to find PRR node\n");
> +        return false;
> +    }
> +
> +    if ( dt_device_get_address(np, 0, &addr, &size) )
> +    {
> +        printk(XENLOG_ERR "ipmmu: Failed to get PRR MMIO\n");
> +        return false;
> +    }
> +
> +    base = ioremap_nocache(addr, size);
> +    if ( !base )
> +    {
> +        printk(XENLOG_ERR "ipmmu: Failed to ioremap PRR MMIO\n");
> +        return false;
> +    }
> +
> +    product = readl(base);
> +    cut = product & RCAR_CUT_MASK;
> +    product &= RCAR_PRODUCT_MASK;
> +
> +    switch ( product )
> +    {
> +    case RCAR_PRODUCT_H3:
> +    case RCAR_PRODUCT_M3W:
> +        if ( cut >= RCAR_CUT_VER30 )
> +            stage2_supported = SUPPORTED;
> +        break;
> +
> +    case RCAR_PRODUCT_M3N:
> +        stage2_supported = SUPPORTED;
> +        break;
> +
> +    default:
> +        printk(XENLOG_ERR "ipmmu: Unsupported SoC version\n");
> +        break;
> +    }
> +
> +    iounmap(base);
> +
> +    return stage2_supported == SUPPORTED;
> +}
> +
> +static const struct dt_device_match ipmmu_dt_match[] __initconst =
> +{
> +    DT_MATCH_COMPATIBLE("renesas,ipmmu-r8a7795"),
> +    DT_MATCH_COMPATIBLE("renesas,ipmmu-r8a77965"),
> +    DT_MATCH_COMPATIBLE("renesas,ipmmu-r8a7796"),
> +    { /* sentinel */ },
> +};
> +
> +static __init int ipmmu_init(struct dt_device_node *node, const void *data)
> +{
> +    int ret;
> +
> +    /*
> +     * Even if the device can't be initialized, we don't want to give
> +     * the IPMMU device to dom0.
> +     */
> +    dt_device_set_used_by(node, DOMID_XEN);
> +
> +    if ( !iommu_hap_pt_share )

iommu_hap_pt_share will soon be hardcoded to true on Arm (see [1]). Even 
without the patch, the value of iommu_hap_pt_share should be ignored as 
done by the SMMU.

> +    {
> +        printk_once(XENLOG_ERR "ipmmu: P2M table must always be shared between the CPU and the IPMMU\n");
> +        return -EINVAL;
> +    }
> +
> +    if ( !ipmmu_stage2_supported() )
> +    {
> +        printk_once(XENLOG_ERR "ipmmu: P2M sharing is not supported in current SoC revision\n");
> +        return -ENODEV;

The if part is returning so...

> +    }
> +    else

... the else part is not necessary removing one layer of indentation.

> +    {
> +        /*
> +         * As 4-level translation table is not supported in IPMMU, we need
> +         * to check IPA size used for P2M table beforehand to be sure it is
> +         * 3-level and the IPMMU will be able to use it.
> +         *
> +         * TODO: First initialize the IOMMU and gather the requirements and
> +         * then initialize the P2M. In the P2M code, take into the account
> +         * the IOMMU requirements and restrict "pa_range" if necessary.
> +         */
> +        if ( IPMMU_MAX_P2M_IPA_BITS < p2m_ipa_bits )
> +        {
> +            printk_once(XENLOG_ERR "ipmmu: P2M IPA size is not supported (P2M=%u IPMMU=%u)!\n",
> +                        p2m_ipa_bits, IPMMU_MAX_P2M_IPA_BITS);
> +            return -ENODEV;
> +        }
> +    }
> +
> +    ret = ipmmu_probe(node);
> +    if ( ret )
> +    {
> +        dev_err(&node->dev, "Failed to init IPMMU (%d)\n", ret);
> +        return ret;
> +    }
> +
> +    iommu_set_ops(&ipmmu_iommu_ops);
> +
> +    return 0;
> +}
> +
> +DT_DEVICE_START(ipmmu, "Renesas IPMMU-VMSA", DEVICE_IOMMU)
> +    .dt_match = ipmmu_dt_match,
> +    .init = ipmmu_init,
> +DT_DEVICE_END
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> 

[1] <20190902145014.36442-6-paul.durrant@citrix.com>

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  parent reply	other threads:[~2019-09-09 21:25 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-20 18:09 [Xen-devel] [PATCH V3 0/8] iommu/arm: Add Renesas IPMMU-VMSA support + Linux's iommu_fwspec Oleksandr Tyshchenko
2019-08-20 18:09 ` [Xen-devel] [PATCH V3 1/8] iommu/arm: Add iommu_helpers.c file to keep common for IOMMUs stuff Oleksandr Tyshchenko
2019-09-09 11:45   ` Julien Grall
2019-09-09 14:12     ` Oleksandr
2019-08-20 18:09 ` [Xen-devel] [PATCH V3 2/8] iommu/arm: Add ability to handle deferred probing request Oleksandr Tyshchenko
2019-09-09 12:24   ` Julien Grall
2019-09-09 14:19     ` Oleksandr
2019-08-20 18:09 ` [Xen-devel] [PATCH V3 3/8] xen/common: Introduce _xrealloc function Oleksandr Tyshchenko
2019-08-21  8:09   ` Paul Durrant
2019-08-21 14:36     ` Oleksandr
2019-08-21 15:47       ` Paul Durrant
2019-08-21 17:04         ` Oleksandr
2019-08-20 18:09 ` [Xen-devel] [PATCH V3 4/8] xen/common: Introduce xrealloc_flex_struct() helper macros Oleksandr Tyshchenko
2019-08-27 13:28   ` Jan Beulich
2019-08-28 18:23     ` Oleksandr
2019-08-29  7:21       ` Jan Beulich
2019-08-29 19:04         ` Oleksandr
2019-08-20 18:09 ` [Xen-devel] [PATCH V3 5/8] iommu/arm: Add lightweight iommu_fwspec support Oleksandr Tyshchenko
2019-09-09 14:36   ` Julien Grall
2019-09-09 14:41     ` Oleksandr
2019-08-20 18:09 ` [Xen-devel] [PATCH V3 6/8] iommu: Add of_xlate callback Oleksandr Tyshchenko
2019-08-27 13:30   ` Jan Beulich
2019-08-27 14:59     ` Oleksandr
2019-08-27 15:11       ` Jan Beulich
2019-09-09 12:37         ` Julien Grall
2019-09-09 14:28           ` Oleksandr
2019-08-20 18:09 ` [Xen-devel] [PATCH V3 7/8] iommu/arm: Introduce iommu_add_dt_device API Oleksandr Tyshchenko
2019-09-09 15:04   ` Julien Grall
2019-09-09 15:48     ` Oleksandr
2019-09-10 13:34       ` Oleksandr
2019-09-10 14:30         ` Julien Grall
2019-08-20 18:09 ` [Xen-devel] [PATCH V3 8/8] iommu/arm: Add Renesas IPMMU-VMSA support Oleksandr Tyshchenko
2019-08-29  8:37   ` Yoshihiro Shimoda
2019-08-29 10:56     ` Oleksandr
2019-09-02  7:04       ` Yoshihiro Shimoda
2019-09-09 14:33         ` Oleksandr
2019-08-29 11:19   ` Oleksandr
2019-09-09 21:24   ` Julien Grall [this message]
2019-09-10 11:04     ` Oleksandr
2019-09-10 14:31       ` Julien Grall
2019-09-11 15:29         ` Oleksandr

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2b1d815c-720d-46c1-04de-0b8eb627b22f@arm.com \
    --to=julien.grall@arm.com \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=oleksandr_tyshchenko@epam.com \
    --cc=olekstysh@gmail.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    --cc=yoshihiro.shimoda.uh@renesas.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).