All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vikram Garhwal <vikram.garhwal@amd.com>
To: Julien Grall <julien@xen.org>
Cc: xen-devel@lists.xenproject.org, 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: Wed, 16 Aug 2023 16:59:31 -0700	[thread overview]
Message-ID: <ZN1i41j7JD9yheTy@amd.com> (raw)
In-Reply-To: <6e15489a-5213-3b8e-0b99-277c0ba989c3@xen.org>

On Mon, Jun 05, 2023 at 08:52:17PM +0100, Julien Grall wrote:
> 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?
Yeah, so intent is to protect the dt_host as whole instead of each node.
I moved it out of struct and kept a single lock for dt_host.
> 
> > +    rwlock_t lock;
> >   };
> >   #define dt_to_dev(dt_node)  (&(dt_node)->dev)
> 
> Cheers,
> 
> -- 
> Julien Grall


  reply	other threads:[~2023-08-16 23:59 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
2023-08-16 23:59     ` Vikram Garhwal [this message]
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=ZN1i41j7JD9yheTy@amd.com \
    --to=vikram.garhwal@amd.com \
    --cc=jbeulich@suse.com \
    --cc=julien@xen.org \
    --cc=michal.orzel@amd.com \
    --cc=sstabellini@kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.