linux-doc.vger.kernel.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, corbet@lwn.net, joro@8bytes.org,
	suravee.suthikulpanit@amd.com, will@kernel.org,
	robin.murphy@arm.com, dwmw2@infradead.org, shuah@kernel.org,
	iommu@lists.linux.dev, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
	baolu.lu@linux.intel.com, 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 v6 01/10] iommufd/viommu: Add IOMMUFD_OBJ_VDEVICE and IOMMU_VDEVICE_ALLOC ioctl
Date: Thu, 7 Nov 2024 14:50:36 -0400	[thread overview]
Message-ID: <20241107185036.GC539304@nvidia.com> (raw)
In-Reply-To: <Zyzra/E3ARtE/Yyx@Asurada-Nvidia>

On Thu, Nov 07, 2024 at 08:31:39AM -0800, Nicolin Chen wrote:
> > Is there any plan to add guest device BDFn as well, or I can add one
> > here for my TEE-IO exercise, if it is the right place? It is the same as
> > vDeviceID for AMD but I am not sure about the others, hence the
> > question. Thanks,
> 
> Generally speaking, adding vRID isn't a problem so long as there
> is a legit reason/usecase. That being said, if it is the same as
> the @virt_id for AMD, why not just pass via @virt_id v.s. adding
> a new vRID/vBDF field?

For CC I'm expecting you to add a AMD CC specific datablob to alloc
viommu that convays all the specific details that the CC world needs
to define the vPCI device. This might include vRID

It depends how you define vdeviceid - for AMD vdeviceid is the index
into the DTE table. vRID, especially if it includes a segment id may
be a larger value and should be seperate.

Jason

  reply	other threads:[~2024-11-07 18:50 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-30 21:35 [PATCH v6 00/10] iommufd: Add vIOMMU infrastructure (Part-2: vDEVICE) Nicolin Chen
2024-10-30 21:35 ` [PATCH v6 01/10] iommufd/viommu: Add IOMMUFD_OBJ_VDEVICE and IOMMU_VDEVICE_ALLOC ioctl Nicolin Chen
2024-10-31 13:29   ` Jason Gunthorpe
2024-10-31 16:56     ` Nicolin Chen
2024-10-31 17:04       ` Jason Gunthorpe
2024-10-31 18:46         ` Nicolin Chen
2024-11-07 10:11   ` Alexey Kardashevskiy
2024-11-07 16:31     ` Nicolin Chen
2024-11-07 18:50       ` Jason Gunthorpe [this message]
2024-10-30 21:35 ` [PATCH v6 02/10] iommufd/selftest: Add IOMMU_VDEVICE_ALLOC test coverage Nicolin Chen
2024-10-30 21:35 ` [PATCH v6 03/10] iommu/viommu: Add cache_invalidate to iommufd_viommu_ops Nicolin Chen
2024-10-30 21:35 ` [PATCH v6 04/10] iommufd: Allow hwpt_id to carry viommu_id for IOMMU_HWPT_INVALIDATE Nicolin Chen
2024-10-30 21:35 ` [PATCH v6 05/10] iommu: Add iommu_copy_struct_from_full_user_array helper Nicolin Chen
2024-10-31 15:33   ` Jason Gunthorpe
2024-10-30 21:35 ` [PATCH v6 06/10] iommufd/viommu: Add iommufd_viommu_find_dev helper Nicolin Chen
2024-10-31 13:30   ` Jason Gunthorpe
2024-10-30 21:35 ` [PATCH v6 07/10] iommufd/selftest: Add mock_viommu_cache_invalidate Nicolin Chen
2024-10-30 21:35 ` [PATCH v6 08/10] iommufd/selftest: Add IOMMU_TEST_OP_DEV_CHECK_CACHE test command Nicolin Chen
2024-10-31 15:34   ` Jason Gunthorpe
2024-10-30 21:35 ` [PATCH v6 09/10] iommufd/selftest: Add vIOMMU coverage for IOMMU_HWPT_INVALIDATE ioctl Nicolin Chen
2024-10-31 15:36   ` Jason Gunthorpe
2024-10-30 21:35 ` [PATCH v6 10/10] Documentation: userspace-api: iommufd: Update vDEVICE Nicolin Chen
2024-10-31  6:28 ` [PATCH v6 00/10] iommufd: Add vIOMMU infrastructure (Part-2: vDEVICE) Zhangfei Gao
2024-10-31 11:59   ` Jason Gunthorpe
2024-10-31 16:43     ` Nicolin Chen
2024-10-31 16:41   ` Nicolin Chen

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=20241107185036.GC539304@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=aik@amd.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=corbet@lwn.net \
    --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-doc@vger.kernel.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).