linux-kernel - Re: [PATCH v7 13/13] Documentation: userspace-api: iommufd: Update vIOMMU

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: <f0c45d5b-b8cd-4f75-a9d7-21808f18583d@intel.com>
Date: Tue, 12 Nov 2024 21:15:02 +0800
From: Yi Liu <yi.l.liu@...el.com>
To: Nicolin Chen <nicolinc@...dia.com>, <jgg@...dia.com>,
	<kevin.tian@...el.com>, <corbet@....net>
CC: <joro@...tes.org>, <suravee.suthikulpanit@....com>, <will@...nel.org>,
	<robin.murphy@....com>, <dwmw2@...radead.org>, <shuah@...nel.org>,
	<iommu@...ts.linux.dev>, <linux-doc@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <linux-kselftest@...r.kernel.org>,
	<baolu.lu@...ux.intel.com>, <eric.auger@...hat.com>,
	<jean-philippe@...aro.org>, <mdf@...nel.org>, <mshavit@...gle.com>,
	<shameerali.kolothum.thodi@...wei.com>, <smostafa@...gle.com>, <aik@....com>,
	<zhangfei.gao@...aro.org>, <patches@...ts.linux.dev>
Subject: Re: [PATCH v7 13/13] Documentation: userspace-api: iommufd: Update
 vIOMMU

On 2024/11/6 04:04, Nicolin Chen wrote:
>   
>   The diagrams below show relationships between user-visible objects and kernel
> @@ -101,6 +132,28 @@ creating the objects and links::
>              |------------>|iommu_domain|<----|iommu_domain|<----|device|
>                            |____________|     |____________|     |______|
>   
> +  _______________________________________________________________________
> + |                      iommufd (with vIOMMU)                            |
> + |                                                                       |
> + |                             [5]                                       |
> + |                        _____________                                  |
> + |                       |             |                                 |
> + |      |----------------|    vIOMMU   |                                 |
> + |      |                |             |                                 |
> + |      |                |             |                                 |
> + |      |      [1]       |             |          [4]             [2]    |
> + |      |     ______     |             |     _____________     ________  |
> + |      |    |      |    |     [3]     |    |             |   |        | |
> + |      |    | IOAS |<---|(HWPT_PAGING)|<---| HWPT_NESTED |<--| DEVICE | |
> + |      |    |______|    |_____________|    |_____________|   |________| |
> + |      |        |              |                  |               |     |
> + |______|________|______________|__________________|_______________|_____|
> +        |        |              |                  |               |
> +  ______v_____   |        ______v_____       ______v_____       ___v__
> + |   struct   |  |  PFN  |  (paging)  |     |  (nested)  |     |struct|
> + |iommu_device|  |------>|iommu_domain|<----|iommu_domain|<----|device|
> + |____________|   storage|____________|     |____________|     |______|
> +
>   1. IOMMUFD_OBJ_IOAS is created via the IOMMU_IOAS_ALLOC uAPI. An iommufd can
>      hold multiple IOAS objects. IOAS is the most generic object and does not
>      expose interfaces that are specific to single IOMMU drivers. All operations
> @@ -132,7 +185,8 @@ creating the objects and links::
>        flag is set.
>   
>   4. IOMMUFD_OBJ_HWPT_NESTED can be only manually created via the IOMMU_HWPT_ALLOC
> -   uAPI, provided an hwpt_id via @pt_id to associate the new HWPT_NESTED object
> +   uAPI, provided an hwpt_id or a viommu_id of a vIOMMU object encapsulating a
> +   nesting parent HWPT_PAGING via @pt_id to associate the new HWPT_NESTED object
>      to the corresponding HWPT_PAGING object. The associating HWPT_PAGING object
>      must be a nesting parent manually allocated via the same uAPI previously with
>      an IOMMU_HWPT_ALLOC_NEST_PARENT flag, otherwise the allocation will fail. The
> @@ -149,6 +203,18 @@ creating the objects and links::
>         created via the same IOMMU_HWPT_ALLOC uAPI. The difference is at the type
>         of the object passed in via the @pt_id field of struct iommufd_hwpt_alloc.
>   
> +5. IOMMUFD_OBJ_VIOMMU can be only manually created via the IOMMU_VIOMMU_ALLOC
> +   uAPI, provided a dev_id (for the device's physical IOMMU to back the vIOMMU)
> +   and an hwpt_id (to associate the vIOMMU to a nesting parent HWPT_PAGING). The
> +   iommufd core will link the vIOMMU object to the struct iommu_device that the
> +   struct device is behind. 

It looks to be reasonable to share the viommu_obj between devices behind 
the same physical IOMMU. This design seems no enforcement for it. So it's
all up to userspace from what I got. :)

-- 
Regards,
Yi Liu