xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Julien Grall <julien@xen.org>
To: Vikram Garhwal <vikram.garhwal@amd.com>, xen-devel@lists.xenproject.org
Cc: michal.orzel@amd.com, sstabellini@kernel.org, jbeulich@suse.com
Subject: Re: [XEN][PATCH v7 14/19] common/device_tree: Add rwlock for dt_host
Date: Mon, 5 Jun 2023 20:52:17 +0100	[thread overview]
Message-ID: <6e15489a-5213-3b8e-0b99-277c0ba989c3@xen.org> (raw)
In-Reply-To: <20230602004824.20731-15-vikram.garhwal@amd.com>

Hi,

On 02/06/2023 01:48, Vikram Garhwal wrote:
>   Dynamic programming ops will modify the dt_host and there might be other
>   function which are browsing the dt_host at the same time. To avoid the race
>   conditions, adding rwlock for browsing the dt_host during runtime.
Please explain that writer will be added in a follow-up patch.

> 
>   Reason behind adding rwlock instead of spinlock:
>      For now, dynamic programming is the sole modifier of dt_host in Xen during
>          run time. All other access functions like iommu_release_dt_device() are
>          just reading the dt_host during run-time. So, there is a need to protect
>          others from browsing the dt_host while dynamic programming is modifying
>          it. rwlock is better suitable for this task as spinlock won't be able to
>          differentiate between read and write access.
> 
> Signed-off-by: Vikram Garhwal <vikram.garhwal@amd.com>
> 
> ---
> Changes from v6:
>      Remove redundant "read_unlock(&dt_host->lock);" in the following case:
>           XEN_DOMCTL_deassign_device
> ---
>   xen/common/device_tree.c              |  4 ++++
>   xen/drivers/passthrough/device_tree.c | 15 +++++++++++++++
>   xen/include/xen/device_tree.h         |  6 ++++++
>   3 files changed, 25 insertions(+)
> 
> diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> index c5250a1644..c8fcdf8fa1 100644
> --- a/xen/common/device_tree.c
> +++ b/xen/common/device_tree.c
> @@ -2146,7 +2146,11 @@ int unflatten_device_tree(const void *fdt, struct dt_device_node **mynodes)
>   
>       dt_dprintk(" <- unflatten_device_tree()\n");
>   
> +    /* Init r/w lock for host device tree. */
> +    rwlock_init(&dt_host->lock);
> +
>       return 0;
> +
>   }
>   
>   static void dt_alias_add(struct dt_alias_prop *ap,
> diff --git a/xen/drivers/passthrough/device_tree.c b/xen/drivers/passthrough/device_tree.c
> index 301a5bcd97..f4d9deb624 100644
> --- a/xen/drivers/passthrough/device_tree.c
> +++ b/xen/drivers/passthrough/device_tree.c
> @@ -112,6 +112,8 @@ int iommu_release_dt_devices(struct domain *d)
>       if ( !is_iommu_enabled(d) )
>           return 0;
>   
> +    read_lock(&dt_host->lock);
> +
>       list_for_each_entry_safe(dev, _dev, &hd->dt_devices, domain_list)
>       {
>           rc = iommu_deassign_dt_device(d, dev);
> @@ -119,10 +121,14 @@ int iommu_release_dt_devices(struct domain *d)
>           {
>               dprintk(XENLOG_ERR, "Failed to deassign %s in domain %u\n",
>                       dt_node_full_name(dev), d->domain_id);
> +
> +            read_unlock(&dt_host->lock);
>               return rc;
>           }
>       }
>   
> +    read_unlock(&dt_host->lock);
> +
>       return 0;
>   }
>   
> @@ -246,6 +252,8 @@ int iommu_do_dt_domctl(struct xen_domctl *domctl, struct domain *d,
>       int ret;
>       struct dt_device_node *dev;
>   
> +    read_lock(&dt_host->lock);
> +
>       switch ( domctl->cmd )
>       {
>       case XEN_DOMCTL_assign_device:
> @@ -295,7 +303,10 @@ int iommu_do_dt_domctl(struct xen_domctl *domctl, struct domain *d,
>           spin_unlock(&dtdevs_lock);
>   
>           if ( d == dom_io )
> +        {
> +            read_unlock(&dt_host->lock);
>               return -EINVAL;
> +        }
>   
>           ret = iommu_add_dt_device(dev);
>           if ( ret < 0 )
> @@ -333,7 +344,10 @@ int iommu_do_dt_domctl(struct xen_domctl *domctl, struct domain *d,
>               break;
>   
>           if ( d == dom_io )
> +        {
> +            read_unlock(&dt_host->lock);
>               return -EINVAL;
> +        }
>   
>           ret = iommu_deassign_dt_device(d, dev);
>   
> @@ -348,5 +362,6 @@ int iommu_do_dt_domctl(struct xen_domctl *domctl, struct domain *d,
>           break;
>       }
>   
> +    read_unlock(&dt_host->lock);
>       return ret;
>   }
> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
> index e239f7de26..dee40d2ea3 100644
> --- a/xen/include/xen/device_tree.h
> +++ b/xen/include/xen/device_tree.h
> @@ -18,6 +18,7 @@
>   #include <xen/string.h>
>   #include <xen/types.h>
>   #include <xen/list.h>
> +#include <xen/rwlock.h>
>   
>   #define DEVICE_TREE_MAX_DEPTH 16
>   
> @@ -106,6 +107,11 @@ struct dt_device_node {
>       struct list_head domain_list;
>   
>       struct device dev;
> +
> +    /*
> +     * Lock that protects r/w updates to unflattened device tree i.e. dt_host.
> +     */

 From the description, it sounds like the rwlock will only be used to 
protect the entire device-tree rather than a single node. So it doesn't 
seem to be sensible to increase each node structure (there are a lot) by 
12 bytes.

Can you outline your plan?

> +    rwlock_t lock;
>   };
>   
>   #define dt_to_dev(dt_node)  (&(dt_node)->dev)

Cheers,

-- 
Julien Grall


  parent reply	other threads:[~2023-06-05 19:52 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-02  0:48 [XEN][PATCH v7 00/19] dynamic node programming using overlay dtbo Vikram Garhwal
2023-06-02  0:48 ` [XEN][PATCH v7 01/19] common/device_tree: handle memory allocation failure in __unflatten_device_tree() Vikram Garhwal
2023-06-02  7:09   ` Michal Orzel
2023-06-05 18:54   ` Julien Grall
2023-06-02  0:48 ` [XEN][PATCH v7 02/19] common/device_tree.c: unflatten_device_tree() propagate errors Vikram Garhwal
2023-06-02  7:14   ` Michal Orzel
2023-06-06 19:08     ` Vikram Garhwal
2023-06-02  0:48 ` [XEN][PATCH v7 03/19] xen/arm/device: Remove __init from function type Vikram Garhwal
2023-06-02  0:48 ` [XEN][PATCH v7 04/19] common/device_tree: change __unflatten_device_tree() type Vikram Garhwal
2023-06-02  7:15   ` Michal Orzel
2023-06-05 19:04   ` Julien Grall
2023-06-06 19:09     ` Vikram Garhwal
2023-08-16 23:49       ` Vikram Garhwal
2023-08-17  7:59         ` Julien Grall
2023-06-02  0:48 ` [XEN][PATCH v7 05/19] xen/arm: Add CONFIG_OVERLAY_DTB Vikram Garhwal
2023-06-02  1:43   ` Henry Wang
2023-06-02  7:16   ` Michal Orzel
2023-06-02  9:06   ` Jan Beulich
2023-06-02  9:22     ` Henry Wang
2023-06-06 19:11       ` Vikram Garhwal
2023-06-02  0:48 ` [XEN][PATCH v7 06/19] libfdt: Keep fdt functions after init for CONFIG_OVERLAY_DTB Vikram Garhwal
2023-06-02  9:09   ` Jan Beulich
2023-06-02  0:48 ` [XEN][PATCH v7 07/19] libfdt: overlay: change overlay_get_target() Vikram Garhwal
2023-06-05 19:05   ` Julien Grall
2023-06-02  0:48 ` [XEN][PATCH v7 08/19] xen/device-tree: Add device_tree_find_node_by_path() to find nodes in device tree Vikram Garhwal
2023-06-02  1:52   ` Henry Wang
2023-06-02  7:24     ` Michal Orzel
2023-06-05 19:12   ` Julien Grall
2023-06-06 20:29     ` Vikram Garhwal
2023-06-07  6:22       ` Michal Orzel
2023-06-07  6:27         ` Henry Wang
2023-06-07  8:30       ` Luca Fancellu
2023-06-02  0:48 ` [XEN][PATCH v7 09/19] xen/iommu: Move spin_lock from iommu_dt_device_is_assigned to caller Vikram Garhwal
2023-06-02  7:45   ` Michal Orzel
2023-06-05 19:22     ` Julien Grall
2023-06-06 20:33       ` Vikram Garhwal
2023-06-02  9:19   ` Jan Beulich
2023-06-02  9:26     ` Jan Beulich
2023-06-05 19:19   ` Julien Grall
2023-08-16 23:55     ` Vikram Garhwal
2023-06-02  0:48 ` [XEN][PATCH v7 10/19] xen/iommu: protect iommu_add_dt_device() with dtdevs_lock Vikram Garhwal
2023-06-02  9:21   ` Jan Beulich
2023-06-05 19:25   ` Julien Grall
2023-06-02  0:48 ` [XEN][PATCH v7 11/19] xen/iommu: Introduce iommu_remove_dt_device() Vikram Garhwal
2023-06-02  9:22   ` Jan Beulich
2023-06-05 19:37   ` Julien Grall
2023-08-16 23:58     ` Vikram Garhwal
2023-06-02  0:48 ` [XEN][PATCH v7 12/19] xen/smmu: Add remove_device callback for smmu_iommu ops Vikram Garhwal
2023-06-02  7:47   ` Michal Orzel
2023-06-02  0:48 ` [XEN][PATCH v7 13/19] asm/smp.h: Fix circular dependency for device_tree.h and rwlock.h Vikram Garhwal
2023-06-05 19:46   ` Julien Grall
2023-06-02  0:48 ` [XEN][PATCH v7 14/19] common/device_tree: Add rwlock for dt_host Vikram Garhwal
2023-06-02  1:58   ` Henry Wang
2023-06-05  7:10   ` Michal Orzel
2023-06-05 19:52   ` Julien Grall [this message]
2023-08-16 23:59     ` Vikram Garhwal
2023-06-02  0:48 ` [XEN][PATCH v7 15/19] xen/arm: Implement device tree node removal functionalities Vikram Garhwal
2023-06-02  9:31   ` Jan Beulich
2023-06-05  7:52   ` Michal Orzel
2023-06-05 21:07   ` Julien Grall
2023-08-17  0:31     ` Vikram Garhwal
2023-08-17  8:14       ` Julien Grall
2023-06-02  0:48 ` [XEN][PATCH v7 16/19] xen/arm: Implement device tree node addition functionalities Vikram Garhwal
2023-06-05  8:35   ` Michal Orzel
2023-06-02  0:48 ` [XEN][PATCH v7 17/19] tools/libs/ctrl: Implement new xc interfaces for dt overlay Vikram Garhwal
2023-06-12 11:17   ` Anthony PERARD
2023-06-02  0:48 ` [XEN][PATCH v7 18/19] tools/libs/light: Implement new libxl functions for device tree overlay ops Vikram Garhwal
2023-06-02  0:48 ` [XEN][PATCH v7 19/19] tools/xl: Add new xl command overlay for device tree overlay support Vikram Garhwal

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=6e15489a-5213-3b8e-0b99-277c0ba989c3@xen.org \
    --to=julien@xen.org \
    --cc=jbeulich@suse.com \
    --cc=michal.orzel@amd.com \
    --cc=sstabellini@kernel.org \
    --cc=vikram.garhwal@amd.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).