xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@linaro.org>
To: Sameer Goel <sgoel@codeaurora.org>,
	xen-devel@lists.xenproject.org, julien.grall@arm.com,
	mjaggi@caviumnetworks.com
Cc: sstabellini@kernel.org, wei.liu2@citrix.com,
	george.dunlap@eu.citrix.com, Andrew.Cooper3@citrix.com,
	jbeulich@suse.com, Ian.Jackson@citrix.com, nd@arm.com,
	robin.murphy@arm.com, shankerd@codeaurora.org
Subject: Re: [RFC v2 3/7] xen/passthrough/arm: Introduce iommu_fwspec
Date: Thu, 12 Oct 2017 14:05:58 +0100	[thread overview]
Message-ID: <abec4356-f81f-c5d1-dda1-f598fd9af195@linaro.org> (raw)
In-Reply-To: <1505954230-18892-4-git-send-email-sgoel@codeaurora.org>

Hi,

On 21/09/17 01:37, Sameer Goel wrote:
> Introduce a common structure to hold the fw (ACPI or DT) defined
> configuration for SMMU hw. The current use case is for arm SMMUs. So,
> making this architecture specific.
> 
> Based on Linux kernel commit 57f98d2f61e1: iommu: Introduce iommu_fwspec
> Signed-off-by: Sameer Goel <sgoel@codeaurora.org>
> ---
>   xen/drivers/passthrough/arm/iommu.c | 66 +++++++++++++++++++++++++++++++++++++
>   xen/include/asm-arm/device.h        |  1 +
>   xen/include/xen/iommu.h             | 29 ++++++++++++++++
>   3 files changed, 96 insertions(+)
> 
> diff --git a/xen/drivers/passthrough/arm/iommu.c b/xen/drivers/passthrough/arm/iommu.c
> index 95b1abb..41c6497 100644
> --- a/xen/drivers/passthrough/arm/iommu.c
> +++ b/xen/drivers/passthrough/arm/iommu.c
> @@ -73,3 +73,69 @@ int arch_iommu_populate_page_table(struct domain *d)
>       /* The IOMMU shares the p2m with the CPU */
>       return -ENOSYS;
>   }
> +
> +const struct iommu_ops *iommu_ops_from_fwnode(struct fwnode_handle *fwnode)
> +{
> +    return iommu_get_ops();

Can you please add a comment explain why you always return iommu_get_ops()?

Would it be possible that the device is not behind an IOMMU?

> +}
> +
> +int iommu_fwspec_init(struct device *dev, struct fwnode_handle *iommu_fwnode,
> +        const struct iommu_ops *ops)
> +{
> +    struct iommu_fwspec *fwspec = dev->iommu_fwspec;
> +
> +    if ( fwspec )
> +        return ops == fwspec->ops ? 0 : -EINVAL;
> +
> +    fwspec = _xzalloc(sizeof(struct iommu_fwspec), sizeof(void *));

On the previous version this was xzalloc(struct iommu_fwspec), why?

I also don't understand the align on sizeof(void *).

> +    if ( !fwspec )
> +        return -ENOMEM;
> +
> +    fwspec->iommu_fwnode = iommu_fwnode;
> +    fwspec->ops = ops;
> +    dev->iommu_fwspec = fwspec;
> +
> +    return 0;
> +}
> +
> +void iommu_fwspec_free(struct device *dev)
> +{
> +    struct iommu_fwspec *fwspec = dev->iommu_fwspec;
> +
> +    if ( fwspec )
> +    {

Linux is dropping the reference on the iommu_fwnode. Are we never 
expecting to take reference on the it in Xen?

> +        xfree(fwspec);
> +        dev->iommu_fwspec = NULL;
> +    }
> +}
> +
> +int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids)
> +{
> +    struct iommu_fwspec *fwspec = dev->iommu_fwspec;
> +    struct iommu_fwspec *fwspec_n = NULL;
> +    size_t size, size_n;
> +    int i;
> +
> +    if ( !fwspec )
> +        return -EINVAL;
> +
> +    size = offsetof(struct iommu_fwspec, ids[fwspec->num_ids]);
> +    size_n = offsetof(struct iommu_fwspec, ids[fwspec->num_ids + num_ids]);
> +    if ( size_n > size )
> +    { > +        fwspec_n = _xzalloc(size_n, sizeof(void *));

Same question about _xzalloc() here.

> +        if ( !fwspec_n )
> +            return -ENOMEM;
> +
> +        memcpy(fwspec_n, fwspec, size);
> +        xfree(fwspec);
> +    }
> +
> +    for (i = 0; i < num_ids; i++)
> +        fwspec_n->ids[fwspec_n->num_ids + i] = ids[i];
> +
> +    fwspec_n->num_ids += num_ids;
> +    dev->iommu_fwspec = fwspec_n;
> +
> +    return 0;
> +}
> diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
> index 78c38fe..5027c87 100644
> --- a/xen/include/asm-arm/device.h
> +++ b/xen/include/asm-arm/device.h
> @@ -21,6 +21,7 @@ struct device
>       struct dt_device_node *of_node; /* Used by drivers imported from Linux */
>   #endif
>       struct fwnode_handle *fwnode; /*fw device node identifier */
> +    struct iommu_fwspec *iommu_fwspec;
>       struct dev_archdata archdata;
>   };
>   
> diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
> index 0dac4f3..34e8d68 100644
> --- a/xen/include/xen/iommu.h
> +++ b/xen/include/xen/iommu.h
> @@ -208,4 +208,33 @@ DECLARE_PER_CPU(bool_t, iommu_dont_flush_iotlb);
>   extern struct spinlock iommu_pt_cleanup_lock;
>   extern struct page_list_head iommu_pt_cleanup_list;
>   
> +/**
> + * Following block was ported from Linux to help with the implementation of
> + * arm64 iommu devices. Hence the architecture specific compile
> + */
> +
> +#if defined(CONFIG_ARM)

If it is Arm only, then it should be moved in asm-arm/iommu.h.

> +/**
> + * struct iommu_fwspec - per-device IOMMU instance data
> + * @ops: ops for this device's IOMMU
> + * @iommu_fwnode: firmware handle for this device's IOMMU
> + * @iommu_priv: IOMMU driver private data for this device
> + * @num_ids: number of associated device IDs
> + * @ids: IDs which this device may present to the IOMMU
> + */
> +struct iommu_fwspec {
> +    const struct iommu_ops *ops;
> +    struct fwnode_handle   *iommu_fwnode;
> +    void                   *iommu_priv;
> +    unsigned int           num_ids;
> +    u32                    ids[1];
> +};
> +
> +int iommu_fwspec_init(struct device *dev, struct fwnode_handle *iommu_fwnode,
> +		      const struct iommu_ops *ops);
> +void iommu_fwspec_free(struct device *dev);
> +int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids);
> +const struct iommu_ops *iommu_ops_from_fwnode(struct fwnode_handle *fwnode);
> +
> +#endif
>   #endif /* _IOMMU_H_ */
> 

Cheers,

-- 
Julien Grall

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

  reply	other threads:[~2017-10-12 13:06 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-21  0:37 [RFC v2 0/7] SMMUv3 driver and the supporting framework Sameer Goel
2017-09-21  0:37 ` [RFC v2 1/7] passthrough/arm: Modify SMMU driver to use generic device definition Sameer Goel
2017-09-21  0:37 ` [RFC v2 2/7] arm64: Add definitions for fwnode_handle Sameer Goel
2017-10-12 12:45   ` Julien Grall
2017-10-19 14:53     ` Goel, Sameer
2017-10-24 14:08       ` Julien Grall
2017-11-09  0:56         ` Goel, Sameer
2017-09-21  0:37 ` [RFC v2 3/7] xen/passthrough/arm: Introduce iommu_fwspec Sameer Goel
2017-10-12 13:05   ` Julien Grall [this message]
2017-10-12 13:36     ` Julien Grall
2017-10-19 14:58     ` Goel, Sameer
2017-09-21  0:37 ` [RFC v2 4/7] ACPI: arm: Support for IORT Sameer Goel
2017-09-21  0:37 ` [RFC v2 5/7] acpi:arm64: Add support for parsing IORT table Sameer Goel
2017-10-10 12:36   ` Manish Jaggi
2017-10-19 15:00     ` Goel, Sameer
2017-10-20  6:25       ` Manish Jaggi
2017-10-12 14:06   ` Julien Grall
2017-10-19 15:21     ` Goel, Sameer
2017-10-24 14:26       ` Julien Grall
2017-10-12 14:23   ` Julien Grall
2017-11-08 14:41   ` Manish Jaggi
2017-11-15  1:27     ` Goel, Sameer
2017-11-15  8:58       ` Julien Grall
2017-09-21  0:37 ` [RFC v2 6/7] Add verbatim copy of arm-smmu-v3.c from Linux Sameer Goel
2017-09-21  0:37 ` [RFC v2 7/7] xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver Sameer Goel
2017-09-26  0:03   ` Goel, Sameer
2017-10-12 16:36   ` Julien Grall
2017-11-19  7:45     ` Goel, Sameer
2017-11-20 14:25       ` Julien Grall
2017-11-20 15:19         ` Robin Murphy
2017-11-20 15:24           ` Julien Grall
2017-11-22  2:17         ` Goel, Sameer
2017-11-27 12:28           ` Julien Grall
2017-09-21  5:43 ` [RFC v2 0/7] SMMUv3 driver and the supporting framework Manish Jaggi

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=abec4356-f81f-c5d1-dda1-f598fd9af195@linaro.org \
    --to=julien.grall@linaro.org \
    --cc=Andrew.Cooper3@citrix.com \
    --cc=Ian.Jackson@citrix.com \
    --cc=george.dunlap@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=julien.grall@arm.com \
    --cc=mjaggi@caviumnetworks.com \
    --cc=nd@arm.com \
    --cc=robin.murphy@arm.com \
    --cc=sgoel@codeaurora.org \
    --cc=shankerd@codeaurora.org \
    --cc=sstabellini@kernel.org \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /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).