From: Stephen Rothwell <sfr@canb•auug.org.au>
To: Jason Gunthorpe <jgg@nvidia•com>, Joerg Roedel <joro@8bytes•org>
Cc: Jason Gunthorpe <jgg@ziepe•ca>, Joerg Roedel <jroedel@suse•de>,
Linux Kernel Mailing List <linux-kernel@vger•kernel.org>,
Linux Next Mailing List <linux-next@vger•kernel.org>,
Lu Baolu <baolu.lu@linux•intel.com>,
Nicolin Chen <nicolinc@nvidia•com>, Yi Liu <yi.l.liu@intel•com>
Subject: Re: linux-next: manual merge of the iommufd tree with the iommu tree
Date: Fri, 3 Nov 2023 10:53:55 +1100 [thread overview]
Message-ID: <20231103105355.71575cf6@canb.auug.org.au> (raw)
In-Reply-To: <20231025154420.718e27af@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 4454 bytes --]
Hi all,
On Wed, 25 Oct 2023 15:44:20 +1100 Stephen Rothwell <sfr@canb•auug.org.au> wrote:
>
> Today's linux-next merge of the iommufd tree got a conflict in:
>
> include/linux/iommu.h
>
> between commits:
>
> 1c68cbc64fe6 ("iommu: Add IOMMU_DOMAIN_PLATFORM")
> 4601cd2d7c4c ("iommu: Add ops->domain_alloc_paging()")
>
> from the iommu tree and commits:
>
> 1621aef1fbfe ("iommu: Add IOMMU_DOMAIN_NESTED")
> 909f4abd1097 ("iommu: Add new iommu op to create domains owned by userspace")
> 17dd7701a2e7 ("iommu: Pass in parent domain with user_data to domain_alloc_user op")
>
> from the iommufd tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc include/linux/iommu.h
> index b5b254e205c6,f347bf31761f..000000000000
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@@ -64,8 -66,10 +66,11 @@@ struct iommu_domain_geometry
> #define __IOMMU_DOMAIN_DMA_FQ (1U << 3) /* DMA-API uses flush queue */
>
> #define __IOMMU_DOMAIN_SVA (1U << 4) /* Shared process address space */
> +#define __IOMMU_DOMAIN_PLATFORM (1U << 5)
>
> + #define __IOMMU_DOMAIN_NESTED (1U << 5) /* User-managed address space nested
> + on a stage-2 translation */
> +
> #define IOMMU_DOMAIN_ALLOC_FLAGS ~__IOMMU_DOMAIN_DMA_FQ
> /*
> * This are the possible domain-types
> @@@ -94,7 -96,7 +99,8 @@@
> __IOMMU_DOMAIN_DMA_API | \
> __IOMMU_DOMAIN_DMA_FQ)
> #define IOMMU_DOMAIN_SVA (__IOMMU_DOMAIN_SVA)
> +#define IOMMU_DOMAIN_PLATFORM (__IOMMU_DOMAIN_PLATFORM)
> + #define IOMMU_DOMAIN_NESTED (__IOMMU_DOMAIN_NESTED)
>
> struct iommu_domain {
> unsigned type;
> @@@ -238,9 -327,19 +331,21 @@@ static inline int __iommu_copy_struct_f
> * op is allocated in the iommu driver and freed by the caller after
> * use. The information type is one of enum iommu_hw_info_type defined
> * in include/uapi/linux/iommufd.h.
> - * @domain_alloc: allocate iommu domain
> + * @domain_alloc: allocate and return an iommu domain if success. Otherwise
> + * NULL is returned. The domain is not fully initialized until
> + * the caller iommu_domain_alloc() returns.
> + * @domain_alloc_paging: Allocate an iommu_domain that can be used for
> + * UNMANAGED, DMA, and DMA_FQ domain types.
> + * @domain_alloc_user: Allocate an iommu domain corresponding to the input
> + * parameters as defined in include/uapi/linux/iommufd.h.
> + * Unlike @domain_alloc, it is called only by IOMMUFD and
> + * must fully initialize the new domain before return.
> + * Upon success, if the @user_data is valid and the @parent
> + * points to a kernel-managed domain, the new domain must be
> + * IOMMU_DOMAIN_NESTED type; otherwise, the @parent must be
> + * NULL while the @user_data can be optionally provided, the
> + * new domain must support __IOMMU_DOMAIN_PAGING.
> + * Upon failure, ERR_PTR must be returned.
> * @probe_device: Add device to iommu driver handling
> * @release_device: Remove device from iommu driver handling
> * @probe_finalize: Do final setup work after the device is added to an IOMMU
> @@@ -275,7 -372,9 +380,10 @@@ struct iommu_ops
>
> /* Domain allocation and freeing by the iommu driver */
> struct iommu_domain *(*domain_alloc)(unsigned iommu_domain_type);
> + struct iommu_domain *(*domain_alloc_paging)(struct device *dev);
> + struct iommu_domain *(*domain_alloc_user)(
> + struct device *dev, u32 flags, struct iommu_domain *parent,
> + const struct iommu_user_data *user_data);
>
> struct iommu_device *(*probe_device)(struct device *dev);
> void (*release_device)(struct device *dev);
This is now a conflict between the iommu tree and Linus' tree.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2023-11-02 23:54 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-25 4:44 linux-next: manual merge of the iommufd tree with the iommu tree Stephen Rothwell
2023-10-25 12:17 ` Jason Gunthorpe
2023-11-02 23:53 ` Stephen Rothwell [this message]
-- strict thread matches above, loose matches on Subject: below --
2025-06-30 6:00 Stephen Rothwell
2025-06-30 13:02 ` Jason Gunthorpe
2025-03-21 8:09 Stephen Rothwell
2023-10-27 4:55 Stephen Rothwell
2023-10-27 6:15 ` Stephen Rothwell
2023-10-30 18:26 ` Jason Gunthorpe
2023-10-31 5:12 ` Stephen Rothwell
2023-10-31 11:31 ` Jason Gunthorpe
2023-11-02 23:53 ` Stephen Rothwell
2023-11-03 0:33 ` Jason Gunthorpe
2023-10-26 3:27 Stephen Rothwell
2023-10-25 4:34 Stephen Rothwell
2023-10-25 12:12 ` Jason Gunthorpe
2023-10-25 12:16 ` Baolu Lu
2023-10-25 12:17 ` Jason Gunthorpe
2023-10-25 12:25 ` Baolu Lu
2023-10-23 4:56 Stephen Rothwell
2023-10-11 5:03 Stephen Rothwell
2023-10-11 13:58 ` Jason Gunthorpe
2023-08-16 6:21 Stephen Rothwell
2022-11-04 4:24 Stephen Rothwell
2022-11-04 12:33 ` Jason Gunthorpe
2022-11-04 19:21 ` Jason Gunthorpe
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=20231103105355.71575cf6@canb.auug.org.au \
--to=sfr@canb$(echo .)auug.org.au \
--cc=baolu.lu@linux$(echo .)intel.com \
--cc=jgg@nvidia$(echo .)com \
--cc=jgg@ziepe$(echo .)ca \
--cc=joro@8bytes$(echo .)org \
--cc=jroedel@suse$(echo .)de \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-next@vger$(echo .)kernel.org \
--cc=nicolinc@nvidia$(echo .)com \
--cc=yi.l.liu@intel$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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