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,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>
Subject: Re: [XEN][PATCH v9 09/19] xen/iommu: Move spin_lock from iommu_dt_device_is_assigned to caller
Date: Thu, 24 Aug 2023 22:09:38 -0700	[thread overview]
Message-ID: <ZOg3kurjD16J2vtr@amd.com> (raw)
In-Reply-To: <e77c9551-a167-468f-b889-e2a0a18471c6@xen.org>

Hi Julien,
On Tue, Aug 22, 2023 at 08:43:27PM +0100, Julien Grall wrote:
> Hi Vikram,
> 
> On 19/08/2023 01:28, Vikram Garhwal wrote:
> > Rename iommu_dt_device_is_assigned() to iommu_dt_device_is_assigned_locked().
> > Remove static type so this can also be used by SMMU drivers to check if the
> > device is being used before removing.
> 
> I have commented on v8. But I will comment here to make easier to keep track
> of comment.
> 
> I don't think iommu_dt_device_is_assigned_locked() should be called from the
> SMMU. If you want to check a device is assigned then it would be best to use
> the internal state of the SMMU.
> 
> This has two benefits:
>   * This avoids what I view as a layer of violation
>   * This confirmed that the internal state match with what we expect
> 
> > 
> > Moving spin_lock to caller was done to prevent the concurrent access to
> > iommu_dt_device_is_assigned while doing add/remove/assign/deassign. Follow-up
> > patches in this series introduces node add/remove feature.
> > 
> > Also, caller is required hold the correct lock so moved the function prototype
> > to a private header.
> 
> I don't understand how requiring the caller to hold the correct lock means
> you need to move the protype in a private header. Can you clarify?
> 
With removal of check in smmu.c, this header is no longer required.
will remove private header too.
> > 
> > Signed-off-by: Vikram Garhwal <vikram.garhwal@amd.com>
> > 
> > ---
> > Changes from v7:
> >      Update commit message.
> >      Add ASSERT().
> > ---
> > ---
> >   xen/drivers/passthrough/device_tree.c | 26 +++++++++++++++++++++----
> >   xen/include/xen/iommu-private.h       | 28 +++++++++++++++++++++++++++
> >   2 files changed, 50 insertions(+), 4 deletions(-)
> >   create mode 100644 xen/include/xen/iommu-private.h
> > 
> > diff --git a/xen/drivers/passthrough/device_tree.c b/xen/drivers/passthrough/device_tree.c
> > index 1c32d7b50c..5796ee1f93 100644
> > --- a/xen/drivers/passthrough/device_tree.c
> > +++ b/xen/drivers/passthrough/device_tree.c
> > @@ -18,6 +18,7 @@
> >   #include <xen/device_tree.h>
> >   #include <xen/guest_access.h>
> >   #include <xen/iommu.h>
> > +#include <xen/iommu-private.h>
> >   #include <xen/lib.h>
> >   #include <xen/sched.h>
> >   #include <xsm/xsm.h>
> > @@ -83,16 +84,16 @@ fail:
> >       return rc;
> >   }
> > -static bool_t iommu_dt_device_is_assigned(const struct dt_device_node *dev)
> > +bool_t iommu_dt_device_is_assigned_locked(const struct dt_device_node *dev)
> >   {
> >       bool_t assigned = 0;
> > +    ASSERT(spin_is_locked(&dtdevs_lock));
> > +
> >       if ( !dt_device_is_protected(dev) )
> >           return 0;
> > -    spin_lock(&dtdevs_lock);
> >       assigned = !list_empty(&dev->domain_list);
> > -    spin_unlock(&dtdevs_lock);
> >       return assigned;
> >   }
> > @@ -213,27 +214,44 @@ int iommu_do_dt_domctl(struct xen_domctl *domctl, struct domain *d,
> >           if ( (d && d->is_dying) || domctl->u.assign_device.flags )
> >               break;
> > +        /*
> > +         * To ensure that the dev doesn't disappear between the time we look it
> > +         * up with dt_find_node_by_gpath() and we check the assignment later.
> > +         */
> > +        spin_lock(&dtdevs_lock);
> 
> This change doesn't look to be explained in the commit message. But looking
> at the code after this series is applied, you justified the addition of
> read_lock(&dt_host_lock) to protect access to the device-tree. This will be
> held longer than dtdevs_lock. So is it actually necessary to move the
> locking earlier?
I re-looked at the implementation and actually, dt_host_lock will protect the
dt related changes. I will move it down before iommu_dt_device_is_assigned_lock()
call.
> 
> > +
> >           ret = dt_find_node_by_gpath(domctl->u.assign_device.u.dt.path,
> >                                       domctl->u.assign_device.u.dt.size,
> >                                       &dev);
> >           if ( ret )
> > +        {
> > +            spin_unlock(&dtdevs_lock);
> >               break;
> > +        }
> >           ret = xsm_assign_dtdevice(XSM_HOOK, d, dt_node_full_name(dev));
> >           if ( ret )
> > +        {
> > +            spin_unlock(&dtdevs_lock);
> >               break;
> > +        }
> >           if ( domctl->cmd == XEN_DOMCTL_test_assign_device )
> >           {
> > -            if ( iommu_dt_device_is_assigned(dev) )
> > +
> > +            if ( iommu_dt_device_is_assigned_locked(dev) )
> >               {
> >                   printk(XENLOG_G_ERR "%s already assigned.\n",
> >                          dt_node_full_name(dev));
> >                   ret = -EINVAL;
> >               }
> > +
> > +            spin_unlock(&dtdevs_lock);
> >               break;
> >           }
> > +        spin_unlock(&dtdevs_lock);
> > +
> >           if ( d == dom_io )
> >               return -EINVAL;
> > diff --git a/xen/include/xen/iommu-private.h b/xen/include/xen/iommu-private.h
> > new file mode 100644
> > index 0000000000..bb5c94e7a6
> > --- /dev/null
> > +++ b/xen/include/xen/iommu-private.h
> > @@ -0,0 +1,28 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +/*
> > + * xen/iommu-private.h
> > + */
> > +#ifndef __XEN_IOMMU_PRIVATE_H__
> > +#define __XEN_IOMMU_PRIVATE_H__
> > +
> > +#ifdef CONFIG_HAS_DEVICE_TREE
> > +#include <xen/device_tree.h>
> > +
> > +/*
> > + * Checks if dt_device_node is assigned to a domain or not. This function
> > + * expects to be called with dtdevs_lock acquired by caller.
> > + */
> > +bool_t iommu_dt_device_is_assigned_locked(const struct dt_device_node *dev);
> > +#endif
> > +
> > +#endif /* __XEN_IOMMU_PRIVATE_H__ */
> > +
> > +/*
> > + * Local variables:
> > + * mode: C
> > + * c-file-style: "BSD"
> > + * c-basic-offset: 4
> > + * tab-width: 4
> > + * indent-tabs-mode: nil
> > + * End:
> > + */
> 
> Cheers,
> 
> -- 
> Julien Grall


  reply	other threads:[~2023-08-25  5:10 UTC|newest]

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

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=ZOg3kurjD16J2vtr@amd.com \
    --to=vikram.garhwal@amd.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=george.dunlap@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=julien@xen.org \
    --cc=michal.orzel@amd.com \
    --cc=sstabellini@kernel.org \
    --cc=wl@xen.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.