Linux Kernel Selftest development
 help / color / mirror / Atom feed
From: Alexey Kardashevskiy <aik@amd.com>
To: Nicolin Chen <nicolinc@nvidia.com>,
	jgg@nvidia.com, kevin.tian@intel.com, will@kernel.org
Cc: 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 01/14] iommufd/viommu: Introduce IOMMUFD_OBJ_VDEVICE and its related struct
Date: Fri, 25 Oct 2024 18:53:01 +1100	[thread overview]
Message-ID: <11dfc0b3-9e45-4f9b-a029-714105fda9c1@amd.com> (raw)
In-Reply-To: <ec230c740b649bba1ca4d2ef054d90c79be4be28.1729555967.git.nicolinc@nvidia.com>



On 22/10/24 11:20, Nicolin Chen wrote:
> Introduce a new IOMMUFD_OBJ_VDEVICE to represent a physical device, i.e.
> iommufd_device (idev) object, against an iommufd_viommu (vIOMMU) object in
> the VM. This vDEVICE object (and its structure) holds all the information
> and attributes in a VM, regarding the device related to the vIOMMU.
> 
> As an initial patch, add a per-vIOMMU virtual ID. This can be:
>   - Virtual StreamID on a nested ARM SMMUv3, an index to a Stream Table
>   - Virtual DeviceID on a nested AMD IOMMU, an index to a Device Table
>   - Virtual ID on a nested Intel VT-D IOMMU, an index to a Context Table
> Potentially, this vDEVICE structure can hold some vData for Confidential
> Compute Architecture (CCA).
> 
> Add a pair of vdevice_alloc and vdevice_free in struct iommufd_viommu_ops
> to allow driver-level vDEVICE structure allocations.
> 
> Similar to iommufd_viommu_alloc, add an iommufd_vdevice_alloc helper, so
> IOMMU drivers can allocate core-embedded style structures.
> 
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
> ---
>   include/linux/iommufd.h | 32 ++++++++++++++++++++++++++++++++
>   1 file changed, 32 insertions(+)
> 
> diff --git a/include/linux/iommufd.h b/include/linux/iommufd.h
> index 5c13c35952d8..5d61a1d2947a 100644
> --- a/include/linux/iommufd.h
> +++ b/include/linux/iommufd.h
> @@ -31,6 +31,7 @@ enum iommufd_object_type {
>   	IOMMUFD_OBJ_ACCESS,
>   	IOMMUFD_OBJ_FAULT,
>   	IOMMUFD_OBJ_VIOMMU,
> +	IOMMUFD_OBJ_VDEVICE,
>   #ifdef CONFIG_IOMMUFD_TEST
>   	IOMMUFD_OBJ_SELFTEST,
>   #endif
> @@ -92,6 +93,14 @@ struct iommufd_viommu {
>   	unsigned int type;
>   };
>   
> +struct iommufd_vdevice {
> +	struct iommufd_object obj;
> +	struct iommufd_ctx *ictx;
> +	struct iommufd_device *idev;
> +	struct iommufd_viommu *viommu;
> +	u64 id; /* per-vIOMMU virtual ID */
> +};
> +
>   /**
>    * struct iommufd_viommu_ops - vIOMMU specific operations
>    * @free: Free all driver-specific parts of an iommufd_viommu. The memory of the
> @@ -101,12 +110,24 @@ struct iommufd_viommu {
>    *                       must be defined in include/uapi/linux/iommufd.h.
>    *                       It must fully initialize the new iommu_domain before
>    *                       returning. Upon failure, ERR_PTR must be returned.
> + * @vdevice_alloc: Allocate a driver-managed iommufd_vdevice to init some driver
> + *                 specific structure or HW procedure. Note that the core-level
> + *                 structure is filled by the iommufd core after calling this op.
> + *                 It is suggested to call iommufd_vdevice_alloc() helper for
> + *                 a bundled allocation of the core and the driver structures,
> + *                 using the ictx pointer in the given @viommu.
> + * @vdevice_free: Free a driver-managed iommufd_vdevice to de-init its structure
> + *                or HW procedure. The memory of the vdevice will be free-ed by
> + *                iommufd core.
>    */
>   struct iommufd_viommu_ops {
>   	void (*free)(struct iommufd_viommu *viommu);
>   	struct iommu_domain *(*domain_alloc_nested)(
>   		struct iommufd_viommu *viommu,
>   		const struct iommu_user_data *user_data);
> +	struct iommufd_vdevice *(*vdevice_alloc)(struct iommufd_viommu *viommu,
> +						 struct device *dev, u64 id);
> +	void (*vdevice_free)(struct iommufd_vdevice *vdev);
>   };
>   
>   #if IS_ENABLED(CONFIG_IOMMUFD)
> @@ -200,4 +221,15 @@ _iommufd_object_alloc(struct iommufd_ctx *ictx, size_t size,
>   			ret->member.ops = viommu_ops;                          \
>   		ret;                                                           \
>   	})
> +#define iommufd_vdevice_alloc(ictx, drv_struct, member)                        \
> +	({                                                                     \
> +		static_assert(                                                 \
> +			__same_type(struct iommufd_vdevice,                    \
> +				    ((struct drv_struct *)NULL)->member));     \
> +		static_assert(offsetof(struct drv_struct, member.obj) == 0);   \
> +		container_of(_iommufd_object_alloc(ictx,                       \
> +						   sizeof(struct drv_struct),  \
> +						   IOMMUFD_OBJ_VDEVICE),       \
> +			     struct drv_struct, member.obj);                   \
> +	})
>   #endif

A nit: it hurts eyes to read:

mock_vdev = iommufd_vdevice_alloc(viommu->ictx, mock_vdevice, core);

vs.

mock_vdev = iommufd_vdevice_alloc(viommu->ictx, struct mock_vdevice, core);

as for the former I go searching for a "mock_vdevice" variable and for 
the latter it is clear it is 1) a macro 2) which does some type checking.

also, it makes it impossible to pass things like typeof(..) or a type 
from typedef. Thanks,


-- 
Alexey


  parent reply	other threads:[~2024-10-25  7: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 [this message]
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

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=11dfc0b3-9e45-4f9b-a029-714105fda9c1@amd.com \
    --to=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=jgg@nvidia.com \
    --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