[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XEN][PATCH v8 09/19] xen/iommu: Move spin_lock from iommu_dt_device_is_assigned to caller


  • To: Julien Grall <julien@xxxxxxx>
  • From: Vikram Garhwal <vikram.garhwal@xxxxxxx>
  • Date: Mon, 21 Aug 2023 12:46:28 -0700
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=5c3qeAlpaGDIznTiV52LeUK73FrSjST/Uwpj7NRl5cc=; b=bu2g06DVOpERfSwy7TM1+nsJue/5WHWYEcz0+ZZzgmufC0eE3gs0XxYa5mJFKEM7xDSngzTsVnWg2H7s4MEIuLDZn26275+AD5sq3DfhWESFYLpwdtd8tXMopY3F4NUfmnzjEd65UIyxDMmHO5tEISMmovy1IQIeFv6SfbSROday7SYvztUZn8nwd5Ylh0f5DcMsIlKI6SHx+04AHgu9K6Aen/L7+XAtgUpCot55yjXLZUnsxhdHdY5DVQjhXaIzSX1/oPRSw5Trxvdm7047ZWzBcBYJ/wfJJnCv+rISDBQ4febDuEQnyFr1h9fTxgTikJntRWwY3NcpHGUXZcB94Q==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Xwp7ZQmz61vTA+3ylRHM+B0CfhSDPdaVXmg8/UTnGv4O3y1+/FGeGvgAMPdp10wm5QgEEerTyK7sc9HQqM+iuMVUiSvr21XpEtCJiZLoO9XbmnPaMEvcjHkXpOcKCle1aI4T2AiK9HiDzBnlE0231J/zcJcAAbcixupkBQKVcQlb30QrpwNPOWMUT88J3XHMsCnNlDKFj3M8HrjaLGU5ka5bQsXpSCdmrxGAVCPBkz+dNh1T1iIYqVeUDgWfYnRKAdZIMlPX0QvQCSuRNn6sDYyqOo2GVCTx5cpPaX/XT9uC69kilA8FlXEXZWJPbO+OP3pGnjZSMi61JEJeWq1faw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com;
  • Cc: Jan Beulich <jbeulich@xxxxxxxx>, michal.orzel@xxxxxxx, sstabellini@xxxxxxxxxx, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 21 Aug 2023 19:46:43 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.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@xxxxxxxxxx/1636441347-133850-7-git-send-email-fnu.vikram@xxxxxxxxxx/

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



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.