From: Vikram Garhwal <vikram.garhwal@amd.com>
To: Julien Grall <julien@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>,
michal.orzel@amd.com, sstabellini@kernel.org,
Andrew Cooper <andrew.cooper3@citrix.com>,
George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
xen-devel@lists.xenproject.org
Subject: Re: [XEN][PATCH v8 09/19] xen/iommu: Move spin_lock from iommu_dt_device_is_assigned to caller
Date: Mon, 21 Aug 2023 12:46:28 -0700 [thread overview]
Message-ID: <ZOO/FDJaqA68eaAl@amd.com> (raw)
In-Reply-To: <e667948d-944d-2649-7063-3725cc68ca8c@xen.org>
Hi Julien
On Fri, Aug 18, 2023 at 09:35:02PM +0100, Julien Grall wrote:
> Hi Vikram,
>
> On 18/08/2023 20:52, Vikram Garhwal wrote:
> > Hi Jan
> > On Thu, Aug 17, 2023 at 09:05:44AM +0200, Jan Beulich wrote:
> > > On 17.08.2023 02:39, Vikram Garhwal wrote:
> > > > --- /dev/null
> > > > +++ b/xen/include/xen/iommu-private.h
> > >
> > > I don't think private headers should live in include/xen/. Judging from only
> > > the patches I was Cc-ed on, ...
> > Thank you for suggestion. Do you where can i place it then?
> > Please see another comment down regarding who might be using this function.
> > >
> > > > @@ -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
> > >
> > > ... I don't even see the need for the declaration, as the function is used
> > > only from the file also defining it. But of course if there is a use
> > > elsewhere (in Arm-only code, as is suggested by the description here), then
> > > the header (under a suitable name) wants to live under drivers/passthrough/
> > > (and of course be included only from anywhere in that sub-tree).
> > >
> > This is also use in smmu.c:arm_smmu_dt_remove_device_legacy(). This is added in
> > 12/19 patch(xen/smmu: Add remove_device callback for smmu_iommu ops).
>
> AFAICT, the caller of this function (iommu_remove_dt_device()) will already
> check if the device was assigned and bail out if that's the case.
>
>
> So why do we need to check it again in the SMMU driver?
>
This was comment from you in v2:
"Even if the IOMMU subsystem check it, it would be good that the SMMU
driver also check the device is not currently used before removing it.
If it is, then we should return -EBUSY."
Link:https://patchew.org/Xen/1636441347-133850-1-git-send-email-fnu.vikram@xilinx.com/1636441347-133850-7-git-send-email-fnu.vikram@xilinx.com/
And there was similar comment from Michal in v5.
That's why this was kept.
Regards,
Vikram
> And if you really need to then you most likely want to check the internal
> state of the SMMU driver rather than the generic state.
>
> Cheers,
>
> --
> Julien Grall
next prev parent reply other threads:[~2023-08-21 19:46 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-17 0:39 [XEN][PATCH v8 00/19] dynamic node programming using overlay dtbo Vikram Garhwal
2023-08-17 0:39 ` [XEN][PATCH v8 01/19] common/device_tree: handle memory allocation failure in __unflatten_device_tree() Vikram Garhwal
2023-08-17 0:39 ` [XEN][PATCH v8 02/19] common/device_tree.c: unflatten_device_tree() propagate errors Vikram Garhwal
2023-08-17 0:39 ` [XEN][PATCH v8 03/19] xen/arm/device: Remove __init from function type Vikram Garhwal
2023-08-17 0:39 ` [XEN][PATCH v8 04/19] common/device_tree: Export __unflatten_device_tree() Vikram Garhwal
2023-08-17 0:39 ` [XEN][PATCH v8 05/19] xen/arm: Add CONFIG_OVERLAY_DTB Vikram Garhwal
2023-08-17 0:39 ` [XEN][PATCH v8 06/19] libfdt: Keep fdt functions after init for CONFIG_OVERLAY_DTB Vikram Garhwal
2023-08-17 0:39 ` [XEN][PATCH v8 07/19] libfdt: overlay: change overlay_get_target() Vikram Garhwal
2023-08-17 0:39 ` [XEN][PATCH v8 08/19] xen/device-tree: Add device_tree_find_node_by_path() to find nodes in device tree Vikram Garhwal
2023-08-17 0:39 ` [XEN][PATCH v8 09/19] xen/iommu: Move spin_lock from iommu_dt_device_is_assigned to caller Vikram Garhwal
2023-08-17 7:05 ` Jan Beulich
2023-08-18 19:52 ` Vikram Garhwal
2023-08-18 20:35 ` Julien Grall
2023-08-21 19:46 ` Vikram Garhwal [this message]
2023-08-21 20:15 ` Julien Grall
2023-08-21 6:32 ` Jan Beulich
2023-08-17 0:39 ` [XEN][PATCH v8 10/19] xen/iommu: protect iommu_add_dt_device() with dtdevs_lock Vikram Garhwal
2023-08-17 0:39 ` [XEN][PATCH v8 11/19] xen/iommu: Introduce iommu_remove_dt_device() Vikram Garhwal
2023-08-17 7:06 ` Jan Beulich
2023-08-17 0:39 ` [XEN][PATCH v8 12/19] xen/smmu: Add remove_device callback for smmu_iommu ops Vikram Garhwal
2023-08-17 0:39 ` [XEN][PATCH v8 13/19] asm/smp.h: Fix circular dependency for device_tree.h and rwlock.h Vikram Garhwal
2023-08-17 0:39 ` [XEN][PATCH v8 14/19] common/device_tree: Add rwlock for dt_host Vikram Garhwal
2023-08-17 0:39 ` [XEN][PATCH v8 15/19] xen/arm: Implement device tree node removal functionalities Vikram Garhwal
2023-08-17 0:39 ` [XEN][PATCH v8 16/19] xen/arm: Implement device tree node addition functionalities Vikram Garhwal
2023-08-17 0:39 ` [XEN][PATCH v8 17/19] tools/libs/ctrl: Implement new xc interfaces for dt overlay Vikram Garhwal
2023-08-17 0:39 ` [XEN][PATCH v8 18/19] tools/libs/light: Implement new libxl functions for device tree overlay ops Vikram Garhwal
2023-08-17 0:39 ` [XEN][PATCH v8 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=ZOO/FDJaqA68eaAl@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.