lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ee9d46f2-5953-4ca4-adac-c3e35c9001a3@linux.intel.com>
Date: Sun, 27 Apr 2025 14:23:54 +0800
From: Baolu Lu <baolu.lu@...ux.intel.com>
To: Nicolin Chen <nicolinc@...dia.com>, jgg@...dia.com, kevin.tian@...el.com,
 corbet@....net, will@...nel.org
Cc: bagasdotme@...il.com, robin.murphy@....com, joro@...tes.org,
 thierry.reding@...il.com, vdumpa@...dia.com, jonathanh@...dia.com,
 shuah@...nel.org, jsnitsel@...hat.com, nathan@...nel.org,
 peterz@...radead.org, yi.l.liu@...el.com, mshavit@...gle.com,
 praan@...gle.com, zhangzekun11@...wei.com, iommu@...ts.linux.dev,
 linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-tegra@...r.kernel.org,
 linux-kselftest@...r.kernel.org, patches@...ts.linux.dev, mochs@...dia.com,
 alok.a.tiwari@...cle.com, vasant.hegde@....com
Subject: Re: [PATCH v2 01/22] iommufd/viommu: Add driver-allocated vDEVICE
 support

On 4/26/25 13:57, Nicolin Chen wrote:
> @@ -120,6 +128,13 @@ struct iommufd_viommu {
>    *                    array->entry_num to report the number of handled requests.
>    *                    The data structure of the array entry must be defined in
>    *                    include/uapi/linux/iommufd.h
> + * @vdevice_alloc: Allocate a vDEVICE object and init its driver-level structure
> + *                 or HW procedure. Note that the core-level structure is filled
> + *                 by the iommufd core after calling this op. @virt_id carries a
> + *                 per-vIOMMU virtual ID for the driver to initialize its HW.

I'm wondering whether the 'per-vIOMMU virtual ID' is intended to be
generic for other features that might require a vdevice. I'm also not
sure where this virtual ID originates when I read it here. Could it
potentially come from the KVM instance? If so, how about retrieving it
directly from a struct kvm pointer? My understanding is that vIOMMU in
IOMMUFD acts as a handle to KVM, so perhaps we should maintain a
reference to the kvm pointer within the iommufd_viommu structure?

> + * @vdevice_destroy: Clean up all driver-specific parts of an iommufd_vdevice.
> + *                   The memory of the vDEVICE will be free-ed by iommufd core
> + *                   after calling this op
>    */
>   struct iommufd_viommu_ops {
>   	void (*destroy)(struct iommufd_viommu *viommu);
> @@ -128,6 +143,10 @@ struct iommufd_viommu_ops {
>   		const struct iommu_user_data *user_data);
>   	int (*cache_invalidate)(struct iommufd_viommu *viommu,
>   				struct iommu_user_data_array *array);
> +	struct iommufd_vdevice *(*vdevice_alloc)(struct iommufd_viommu *viommu,
> +						 struct device *dev,
> +						 u64 virt_id);
> +	void (*vdevice_destroy)(struct iommufd_vdevice *vdev);
>   };

Thanks,
baolu

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ