linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Nicolin Chen <nicolinc@nvidia.com>
Cc: Alexey Kardashevskiy <aik@amd.com>,
	kevin.tian@intel.com, will@kernel.org, joro@8bytes.org,
	suravee.suthikulpanit@amd.com, robin.murphy@arm.com,
	dwmw2@infradead.org, baolu.lu@linux.intel.com, shuah@kernel.org,
	linux-kernel@vger.kernel.org, iommu@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	linux-kselftest@vger.kernel.org, eric.auger@redhat.com,
	jean-philippe@linaro.org, mdf@kernel.org, mshavit@google.com,
	shameerali.kolothum.thodi@huawei.com, smostafa@google.com,
	yi.l.liu@intel.com, zhangfei.gao@linaro.org,
	patches@lists.linux.dev
Subject: Re: [PATCH v4 00/14] iommufd: Add vIOMMU infrastructure (Part-2: vDEVICE)
Date: Fri, 25 Oct 2024 10:29:15 -0300	[thread overview]
Message-ID: <20241025132915.GF6956@nvidia.com> (raw)
In-Reply-To: <Zxs3PYVLzmRfBf+/@Asurada-Nvidia>

On Thu, Oct 24, 2024 at 11:14:21PM -0700, Nicolin Chen wrote:
> On Fri, Oct 25, 2024 at 04:58:33PM +1100, Alexey Kardashevskiy wrote:
> > > > > > Is there any real example of a .vdevice_alloc hook, besides the
> > > > > > selftests? It is not in iommufd_viommu_p2-v4-with-rmr, hence the
> > > > > > question. I am trying to sketch something with this new machinery and
> > > > > > less guessing would be nice. Thanks,
> > > > > 
> > > > > No, I am actually dropping that one, and moving the vdevice struct
> > > > > to the private header, as there seems to be no use case:
> > > > 
> > > > Why keep it then?
> > > 
> > > We need that structure to store per-vIOMMU virtual ID. Hiding it
> > > in the core only means we need to provide another vIOMMU APIs for
> > > drivers to look up the ID, v.s. exposing it for drivers to access
> > > directly.
> > 
> > Sorry I lost you here. If we need it, then there should be an example of
> > .vdevice_alloc() somewhere but you say they is not one. How do you test
> > this, with just selftests? :) Thanks,
> 
> A vDEVICE object will be core-allocated and core-managed, while the
> vdevice_alloc is for driver-allocated purpose for which there is no
> use case (at least with this series). You can check the vdev ioctl
> in this version that has two pathways to allocate a vDEVICE object.
> 
> A vdev_id is used to index viommu's xarray for a driver to convert
> the id to a dev pointer via a vIOMMU API. Dropping .vdevice_alloc
> just means the driver only lost its direct access.

I think the point here is this has to go in stages at the present
moment the iommu drivers don't need to hook the vdevice object, so
Nicolin should take it out of this series.

I would expect CC to need to be in this path, so we should bring it
back in the CC series.

For CC I'm broadly expecting that creating the CC type vIOMMU will
call a CC implementation, and then creating a vdevice against the
vIOMMU will also call the CC implementation. The two callbacks would
ask the secure world to create the relevant VM visible objects.

Jason


      reply	other threads:[~2024-10-25 13:53 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-22  0:20 [PATCH v4 00/14] iommufd: Add vIOMMU infrastructure (Part-2: vDEVICE) Nicolin Chen
2024-10-22  0:20 ` [PATCH v4 01/14] iommufd/viommu: Introduce IOMMUFD_OBJ_VDEVICE and its related struct Nicolin Chen
2024-10-25  3:37   ` Nicolin Chen
2024-10-25  7:53   ` Alexey Kardashevskiy
2024-10-25 13:20     ` Jason Gunthorpe
2024-10-25 16:39       ` Nicolin Chen
2024-10-22  0:20 ` [PATCH v4 02/14] iommufd/viommu: Add IOMMU_VDEVICE_ALLOC ioctl Nicolin Chen
2024-10-22  3:40   ` Baolu Lu
2024-10-22  4:40     ` Nicolin Chen
2024-10-22  0:20 ` [PATCH v4 03/14] iommufd/selftest: Add IOMMU_VDEVICE_ALLOC test coverage Nicolin Chen
2024-10-22  0:20 ` [PATCH v4 04/14] iommu/viommu: Add cache_invalidate to iommufd_viommu_ops Nicolin Chen
2024-10-22  0:20 ` [PATCH v4 05/14] iommufd/hw_pagetable: Enforce cache invalidation op on vIOMMU-based hwpt_nested Nicolin Chen
2024-10-22  0:20 ` [PATCH v4 06/14] iommufd: Allow hwpt_id to carry viommu_id for IOMMU_HWPT_INVALIDATE Nicolin Chen
2024-10-22  0:20 ` [PATCH v4 07/14] iommu: Add iommu_copy_struct_from_full_user_array helper Nicolin Chen
2024-10-22  0:20 ` [PATCH v4 08/14] iommufd/viommu: Add vdev_to_dev helper Nicolin Chen
2024-10-25  3:39   ` Nicolin Chen
2024-10-22  0:20 ` [PATCH v4 09/14] iommufd/selftest: Add mock_viommu_cache_invalidate Nicolin Chen
2024-10-22  0:20 ` [PATCH v4 10/14] iommufd/selftest: Add IOMMU_TEST_OP_DEV_CHECK_CACHE test command Nicolin Chen
2024-10-22  0:20 ` [PATCH v4 11/14] iommufd/selftest: Add vIOMMU coverage for IOMMU_HWPT_INVALIDATE ioctl Nicolin Chen
2024-10-22  0:20 ` [PATCH v4 12/14] Documentation: userspace-api: iommufd: Update vDEVICE Nicolin Chen
2024-10-22  0:20 ` [PATCH v4 13/14] iommu/arm-smmu-v3: Add arm_vsmmu_cache_invalidate Nicolin Chen
2024-10-22  0:20 ` [PATCH v4 14/14] iommu/arm-smmu-v3: Allow ATS for IOMMU_DOMAIN_NESTED Nicolin Chen
2024-10-25  4:54 ` [PATCH v4 00/14] iommufd: Add vIOMMU infrastructure (Part-2: vDEVICE) Alexey Kardashevskiy
2024-10-25  4:59   ` Nicolin Chen
2024-10-25  5:32     ` Alexey Kardashevskiy
2024-10-25  5:41       ` Nicolin Chen
2024-10-25  5:58         ` Alexey Kardashevskiy
2024-10-25  6:14           ` Nicolin Chen
2024-10-25 13:29             ` Jason Gunthorpe [this message]

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=20241025132915.GF6956@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=aik@amd.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=dwmw2@infradead.org \
    --cc=eric.auger@redhat.com \
    --cc=iommu@lists.linux.dev \
    --cc=jean-philippe@linaro.org \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=mdf@kernel.org \
    --cc=mshavit@google.com \
    --cc=nicolinc@nvidia.com \
    --cc=patches@lists.linux.dev \
    --cc=robin.murphy@arm.com \
    --cc=shameerali.kolothum.thodi@huawei.com \
    --cc=shuah@kernel.org \
    --cc=smostafa@google.com \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=will@kernel.org \
    --cc=yi.l.liu@intel.com \
    --cc=zhangfei.gao@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).