From: Jason Gunthorpe <jgg@nvidia.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: "iommu@lists.linux.dev" <iommu@lists.linux.dev>,
"linux-kselftest@vger.kernel.org"
<linux-kselftest@vger.kernel.org>, Shuah Khan <shuah@kernel.org>,
Nicolin Chen <nicolinc@nvidia.com>,
"Liu, Yi L" <yi.l.liu@intel.com>
Subject: Re: [PATCH v2 6/7] iommufd/selftest: Make selftest create a more complete mock device
Date: Fri, 24 Feb 2023 10:26:36 -0400 [thread overview]
Message-ID: <Y/jJHPGLQUdcNFUJ@nvidia.com> (raw)
In-Reply-To: <BN9PR11MB527674E485D533D57A9965888CA89@BN9PR11MB5276.namprd11.prod.outlook.com>
On Fri, Feb 24, 2023 at 06:50:43AM +0000, Tian, Kevin wrote:
> > From: Jason Gunthorpe <jgg@nvidia.com>
> > Sent: Thursday, February 23, 2023 5:03 AM
> >
> > iommufd wants to use more infrastructure, like the iommu_group, that the
> > mock device does not support. Create a more complete mock device that can
> > go through the whole cycle of ownership, blocking domain, and has an
> > iommu_group.
>
> this is a nice move! Presumable with a real struct device we can further
> extend the mock device to test nested, pasid attach/alloc, etc. in the
> future.
Yes, it should all work better
> > + /*
> > + * The iommu core has no way to associate a single device with an
> > iommu
> > + * driver (heck currently it can't even support two iommu_drivers
> > + * registering). Hack it together with an open coded dev_iommu_get().
> > + * Notice that the normal notifier triggered iommu release process
> > also
> > + * does not work here because this bus is not in iommu_buses.
> > + */
> > + mdev->dev.iommu = kzalloc(sizeof(*dev_iommu), GFP_KERNEL);
> > + if (!mdev->dev.iommu) {
> > + rc = -ENOMEM;
> > + goto err_group;
> > + }
> > + mutex_init(&mdev->dev.iommu->lock);
> > + mdev->dev.iommu->iommu_dev = &mock_iommu_device;
>
> I understand how this hack works but didn't get why in this case
> dev_iommu_get() cannot be reused...
I'd have to make it an exported symbol.. It could be done, maybe it
should be done. I'm unclear how much intrustion we should create for
the selftests.
The other thought I had is that perhaps we could fix the bus binding
so that it wasn't a hard coded list in the iommu.c Eg a flag in the
bus_type or provide the list when binding the driver or
something. Then things would work perfectly. Needs Robin's series
first though as it allows multiple iommu drivers.
So.. I kind of left it like this hoping that other parts would advance
more and we can revisit it later, it is only 4 lines.
Jason
next prev parent reply other threads:[~2023-02-24 14:26 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-22 21:02 [PATCH v2 0/7] Revise the hwpt lifetime model Jason Gunthorpe
2023-02-22 21:02 ` [PATCH v2 1/7] iommufd: Assert devices_lock for iommufd_hw_pagetable_has_group() Jason Gunthorpe
2023-02-22 21:02 ` [PATCH v2 2/7] iommufd: Add iommufd_lock_obj() around the auto-domains hwpts Jason Gunthorpe
2023-02-24 6:12 ` Tian, Kevin
2023-02-22 21:02 ` [PATCH v2 3/7] iommufd: Move ioas related HWPT destruction into iommufd_hw_pagetable_destroy() Jason Gunthorpe
2023-02-24 6:25 ` Tian, Kevin
2023-02-22 21:02 ` [PATCH v2 4/7] iommufd: Move iommufd_device to iommufd_private.h Jason Gunthorpe
2023-02-24 6:27 ` Tian, Kevin
2023-02-22 21:02 ` [PATCH v2 5/7] iommufd: Make iommufd_hw_pagetable_alloc() do iopt_table_add_domain() Jason Gunthorpe
2023-02-23 9:03 ` Tian, Kevin
2023-02-23 13:07 ` Jason Gunthorpe
2023-02-24 6:35 ` Tian, Kevin
2023-02-24 17:02 ` Jason Gunthorpe
2023-02-22 21:02 ` [PATCH v2 6/7] iommufd/selftest: Make selftest create a more complete mock device Jason Gunthorpe
2023-02-24 6:50 ` Tian, Kevin
2023-02-24 14:26 ` Jason Gunthorpe [this message]
2023-02-22 21:02 ` [PATCH v2 7/7] iommufd/selftest: Add a selftest for iommufd_device_attach() with a hwpt argument Jason Gunthorpe
2023-02-24 7:02 ` Tian, Kevin
2023-02-24 18:19 ` 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=Y/jJHPGLQUdcNFUJ@nvidia.com \
--to=jgg@nvidia.com \
--cc=iommu@lists.linux.dev \
--cc=kevin.tian@intel.com \
--cc=linux-kselftest@vger.kernel.org \
--cc=nicolinc@nvidia.com \
--cc=shuah@kernel.org \
--cc=yi.l.liu@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox