From: Nicolin Chen <nicolinc@nvidia.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Yi Liu <yi.l.liu@intel.com>, "Tian, Kevin" <kevin.tian@intel.com>,
"joro@8bytes.org" <joro@8bytes.org>,
"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
"robin.murphy@arm.com" <robin.murphy@arm.com>,
"baolu.lu@linux.intel.com" <baolu.lu@linux.intel.com>,
"cohuck@redhat.com" <cohuck@redhat.com>,
"eric.auger@redhat.com" <eric.auger@redhat.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"mjrosato@linux.ibm.com" <mjrosato@linux.ibm.com>,
"chao.p.peng@linux.intel.com" <chao.p.peng@linux.intel.com>,
"yi.y.sun@linux.intel.com" <yi.y.sun@linux.intel.com>,
"peterx@redhat.com" <peterx@redhat.com>,
"jasowang@redhat.com" <jasowang@redhat.com>,
"shameerali.kolothum.thodi@huawei.com"
<shameerali.kolothum.thodi@huawei.com>,
"lulu@redhat.com" <lulu@redhat.com>,
"suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>,
"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-kselftest@vger.kernel.org"
<linux-kselftest@vger.kernel.org>,
"Duan, Zhenzhong" <zhenzhong.duan@intel.com>,
"joao.m.martins@oracle.com" <joao.m.martins@oracle.com>,
"Zeng, Xin" <xin.zeng@intel.com>,
"Zhao, Yan Y" <yan.y.zhao@intel.com>
Subject: Re: [PATCH v7 1/3] iommufd: Add data structure for Intel VT-d stage-1 cache invalidation
Date: Thu, 4 Jan 2024 23:38:40 -0800 [thread overview]
Message-ID: <ZZeyAC3c8LJz7nsQ@Asurada-Nvidia> (raw)
In-Reply-To: <20240104000204.GV50406@nvidia.com>
On Wed, Jan 03, 2024 at 08:02:04PM -0400, Jason Gunthorpe wrote:
> On Wed, Jan 03, 2024 at 12:18:35PM -0800, Nicolin Chen wrote:
> > > The driver would have to create it and there would be some driver
> > > specific enclosing struct to go with it
> > >
> > > Perhaps device_ids goes in the driver specific struct, I don't know.
> >
> > +struct iommufd_viommu {
> > + struct iommufd_object obj;
> > + struct iommufd_ctx *ictx;
> > + struct iommu_device *iommu_dev;
> > + struct iommufd_hwpt_paging *hwpt; /* maybe unneeded */
> > +
> > + int vmid;
> > +
> > + union iommu_driver_user_data {
> > + struct iommu_driver_user_vtd;
> > + struct iommu_driver_user_arm_smmuv3;
> > + struct iommu_driver_user_amd_viommu;
> > + };
>
> Not like that, in the usual container_of way
How about this:
// iommu.h
@@ -490,6 +490,16 @@ struct iommu_ops {
+ /* User space instance allocation and freeing by the iommu driver */
+ struct iommu_device_user *(*iommu_alloc_user)(struct iommu_device *iommu);
+ void (*iommu_free_user)(struct iommu_device_user *iommu_user);
+ int (*iommu_user_set_dev_id)(struct iommu_device_user *iommu_user,
+ struct device *dev, u64 dev_id);
+ int (*iommu_user_unset_dev_id)(struct iommu_device_user *iommu_user,
+ struct device *dev);
+ int (*iommu_cache_invalidate_usewr)(struct iommu_device_user *iommu_user,
+ struct iommu_user_data_array *array);
...
+/**
+ * struct iommu_device_user - IOMMU core representation of one IOMMU virtual
+ * instance
+ * @iommu_dev: Underlying IOMMU hardware instance
+ * @id: Virtual instance ID, e.g. a vmid
+ */
+struct iommu_device_user {
+ struct iommu_device *iommu_dev;
+ struct xarray virtual_ids;
+ u32 id;
+};
// iommufd_private.h
+struct iommufd_viommu {
+ struct iommufd_object obj;
+ struct iommufd_ctx *ictx;
+ struct iommu_device *iommu_dev;
+ struct iommu_device_user *iommu_user;
+ struct iommufd_hwpt_paging *hwpt;
+};
+
+int iommufd_viommu_alloc_ioctl(struct iommufd_ucmd *ucmd);
+void iommufd_viommu_destroy(struct iommufd_object *obj);
So iommu_alloc_user op allocates a driver private structure that
contains an iommu_device_user and returns &priv->iommu_user.
The set/unset_dev_id ops probably need a type argument if there
can be a multi-xarray case, then the virtual_ids xarray should
be moved to the driver private structure too?
Also, a 64-bit virtual id in the uAPI was suggested previously.
But xarray is limited to a 32-bit index? Should we compromise
the uAPI to 32-bit or is there an alternative for a 64-bit id
lookup?
Thanks
Nicolin
next prev parent reply other threads:[~2024-01-05 7:39 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-17 13:18 [PATCH v7 0/3] Add Intel VT-d nested translation (part 2/2) Yi Liu
2023-11-17 13:18 ` [PATCH v7 1/3] iommufd: Add data structure for Intel VT-d stage-1 cache invalidation Yi Liu
2023-11-20 8:26 ` Tian, Kevin
2023-11-20 23:04 ` Jason Gunthorpe
2023-11-21 2:54 ` Tian, Kevin
2023-11-21 12:17 ` Jason Gunthorpe
2023-11-22 2:32 ` Baolu Lu
2023-11-22 3:52 ` Yi Liu
2023-11-22 4:58 ` Tian, Kevin
2023-11-22 13:25 ` Jason Gunthorpe
2023-11-24 3:00 ` Tian, Kevin
2023-11-24 13:46 ` Jason Gunthorpe
2023-12-14 11:26 ` Yi Liu
2023-12-15 1:50 ` Tian, Kevin
2023-12-15 2:28 ` Nicolin Chen
2023-12-15 3:04 ` Tian, Kevin
2023-12-15 3:32 ` Nicolin Chen
2023-12-15 4:01 ` Yi Liu
2023-12-16 18:49 ` Nicolin Chen
2023-12-17 23:28 ` Tian, Kevin
2024-01-02 23:38 ` Jason Gunthorpe
2024-01-03 2:24 ` Yi Liu
2024-01-03 16:01 ` Jason Gunthorpe
2024-01-03 16:48 ` Nicolin Chen
2024-01-03 16:58 ` Jason Gunthorpe
2024-01-03 17:06 ` Nicolin Chen
2024-01-03 17:52 ` Jason Gunthorpe
2024-01-03 20:18 ` Nicolin Chen
2024-01-04 0:02 ` Jason Gunthorpe
2024-01-05 7:38 ` Nicolin Chen [this message]
2024-01-05 15:46 ` Jason Gunthorpe
2024-01-02 17:46 ` Jason Gunthorpe
2024-01-04 14:36 ` Jason Gunthorpe
2024-01-05 2:16 ` Tian, Kevin
2024-01-05 2:52 ` Tian, Kevin
2024-01-05 14:45 ` Jason Gunthorpe
2024-01-08 4:07 ` Tian, Kevin
2024-01-08 13:51 ` Jason Gunthorpe
2024-01-09 6:00 ` Yi Liu
2023-11-17 13:18 ` [PATCH v7 2/3] iommu/vt-d: Make iotlb flush helpers to be extern Yi Liu
2023-11-17 13:18 ` [PATCH v7 3/3] iommu/vt-d: Add iotlb flush for nested domain Yi Liu
2023-11-20 8:32 ` Tian, Kevin
2023-12-12 3:58 ` Yi Liu
2023-12-06 18:56 ` Jason Gunthorpe
2023-12-12 3:59 ` Yi Liu
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=ZZeyAC3c8LJz7nsQ@Asurada-Nvidia \
--to=nicolinc@nvidia.com \
--cc=alex.williamson@redhat.com \
--cc=baolu.lu@linux.intel.com \
--cc=chao.p.peng@linux.intel.com \
--cc=cohuck@redhat.com \
--cc=eric.auger@redhat.com \
--cc=iommu@lists.linux.dev \
--cc=jasowang@redhat.com \
--cc=jgg@nvidia.com \
--cc=joao.m.martins@oracle.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=lulu@redhat.com \
--cc=mjrosato@linux.ibm.com \
--cc=peterx@redhat.com \
--cc=robin.murphy@arm.com \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=suravee.suthikulpanit@amd.com \
--cc=xin.zeng@intel.com \
--cc=yan.y.zhao@intel.com \
--cc=yi.l.liu@intel.com \
--cc=yi.y.sun@linux.intel.com \
--cc=zhenzhong.duan@intel.com \
/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.