diff mbox series

[RFC,4/6] iommufd: Introduce data struct for AMD nested domain allocation

Message ID 20231212160139.174229-5-suravee.suthikulpanit@amd.com
State New
Headers
Series iommu/amd: Introduce hardware info reporting and nested translation support |

Commit Message

Suravee Suthikulpanit Dec. 12, 2023, 4:01 p.m. UTC 
  Introduce IOMMU_HWPT_DATA_AMD_V2 data type for AMD IOMMU v2 page table,
which is used for stage-1 in nested translation. The data structure
contains information necessary for setting up the AMD HW-vIOMMU support.

Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
---
 include/uapi/linux/iommufd.h | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

Comments

Jason Gunthorpe Dec. 13, 2023, 2:03 p.m. UTC | #1 
On Tue, Dec 12, 2023 at 10:01:37AM -0600, Suravee Suthikulpanit wrote:
> Introduce IOMMU_HWPT_DATA_AMD_V2 data type for AMD IOMMU v2 page table,
> which is used for stage-1 in nested translation. The data structure
> contains information necessary for setting up the AMD HW-vIOMMU support.
> 
> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
> ---
>  include/uapi/linux/iommufd.h | 23 +++++++++++++++++++++++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/include/uapi/linux/iommufd.h b/include/uapi/linux/iommufd.h
> index bf4a1f8ab748..e2240d430dd1 100644
> --- a/include/uapi/linux/iommufd.h
> +++ b/include/uapi/linux/iommufd.h
> @@ -389,14 +389,37 @@ struct iommu_hwpt_vtd_s1 {
>  	__u32 __reserved;
>  };
>  
> +/**
> + * struct iommu_hwpt_amd_v2 - AMD IOMMU specific user-managed
> + *                            v2 I/O page table data
> + * @gcr3: GCR3 guest physical ddress
> + * @gid: Guest ID
> + * @iommu_id: IOMMU host device ID
> + * @gdev_id: Guest device ID
> + * @gdom_id: Guest domain ID
> + * @glx: GCR3 table levels
> + * @guest_paging_mode: Guest v2 page table paging mode
> + */
> +struct iommu_hwpt_amd_v2 {
> +	__aligned_u64 gcr3;
> +	__u32 gid;
> +	__u32 iommu_id;
> +	__u16 gdev_id;
> +	__u16 gdom_id;
> +	__u16 glx;
> +	__u16 guest_paging_mode;

Add explicit padding please

Also, I'm pretty sure that most of these IDs cannot be here.

These are Ok:

	__aligned_u64 gcr3; // table top pointer
	__u16 gdom_id;      // virtual cache tag
        __u16 glx;          // configuration of radix
        __u16 guest_paging_mode; // configuration of radix

These are confusing, probably incorrect.

 +	__u32 gid;
 +	__u32 iommu_id;
 +	__u16 gdev_id;

iommu_id is the RID of the IOMMU, so definately not. The iommu
instance to work on is specifed by the generic dev_id which becomes a
struct device * in the driver callback. Access the target iommu
instance via dev_iommu_priv_get()/etc

The translation of gdev_id to pdev_dev needs to be connected to some
future viommu object, so this shouldn't be part of this series, and
will eventually be provided through some new viommu object API - see
my long outline email

The viommu object should hold the GID. I'm not sure you need a GID
right now (can you just issue invalidation on the physical side?), but
if you do need GID to bridge until the viommu is ready it should
probably be allocated by and stored in the nesting parent.

Jason
Tian, Kevin Dec. 15, 2023, 7:38 a.m. UTC | #2 
> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: Wednesday, December 13, 2023 10:04 PM
> 
> The viommu object should hold the GID. I'm not sure you need a GID
> right now (can you just issue invalidation on the physical side?), but
> if you do need GID to bridge until the viommu is ready it should
> probably be allocated by and stored in the nesting parent.
> 

and how is GID different from existing Domain ID of nesting parent?
Suravee Suthikulpanit Jan. 5, 2024, 1:39 p.m. UTC | #3 
Hi Jason

On 12/13/2023 9:03 PM, Jason Gunthorpe wrote:
> On Tue, Dec 12, 2023 at 10:01:37AM -0600, Suravee Suthikulpanit wrote:
>> Introduce IOMMU_HWPT_DATA_AMD_V2 data type for AMD IOMMU v2 page table,
>> which is used for stage-1 in nested translation. The data structure
>> contains information necessary for setting up the AMD HW-vIOMMU support.
>>
>> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
>> ---
>>   include/uapi/linux/iommufd.h | 23 +++++++++++++++++++++++
>>   1 file changed, 23 insertions(+)
>>
>> diff --git a/include/uapi/linux/iommufd.h b/include/uapi/linux/iommufd.h
>> index bf4a1f8ab748..e2240d430dd1 100644
>> --- a/include/uapi/linux/iommufd.h
>> +++ b/include/uapi/linux/iommufd.h
>> @@ -389,14 +389,37 @@ struct iommu_hwpt_vtd_s1 {
>>   	__u32 __reserved;
>>   };
>>   
>> +/**
>> + * struct iommu_hwpt_amd_v2 - AMD IOMMU specific user-managed
>> + *                            v2 I/O page table data
>> + * @gcr3: GCR3 guest physical ddress
>> + * @gid: Guest ID
>> + * @iommu_id: IOMMU host device ID
>> + * @gdev_id: Guest device ID
>> + * @gdom_id: Guest domain ID
>> + * @glx: GCR3 table levels
>> + * @guest_paging_mode: Guest v2 page table paging mode
>> + */
>> +struct iommu_hwpt_amd_v2 {
>> +	__aligned_u64 gcr3;
>> +	__u32 gid;
>> +	__u32 iommu_id;
>> +	__u16 gdev_id;
>> +	__u16 gdom_id;
>> +	__u16 glx;
>> +	__u16 guest_paging_mode;
> 
> Add explicit padding please

OK

> Also, I'm pretty sure that most of these IDs cannot be here.
> 
> These are Ok:
> 
> 	__aligned_u64 gcr3; // table top pointer
> 	__u16 gdom_id;      // virtual cache tag
>          __u16 glx;          // configuration of radix
>          __u16 guest_paging_mode; // configuration of radix
> 
> These are confusing, probably incorrect.
> 
>   +	__u32 gid;
>   +	__u32 iommu_id;
>   +	__u16 gdev_id;

> iommu_id is the RID of the IOMMU, so definately not. The iommu
> instance to work on is specifed by the generic dev_id which becomes a
> struct device * in the driver callback. Access the target iommu
> instance via dev_iommu_priv_get()/etc
>
> The translation of gdev_id to pdev_dev needs to be connected to some
> future viommu object, so this shouldn't be part of this series, and
> will eventually be provided through some new viommu object API - see
> my long outline email

Got it.

> The viommu object should hold the GID. I'm not sure you need a GID
> right now (can you just issue invalidation on the physical side?), but
> if you do need GID to bridge until the viommu is ready it should
> probably be allocated by and stored in the nesting parent.

Currently, the GID is needed when setting up domain ID mapping table 
(and device ID mapping table in future series), which will be moved to 
when attaching domain to a device. By that time, we should already have 
GID information already stored in other struct (e.g. struct 
iommu_dev_data). So it should be alright to get rid of GID from the 
struct iommu_hwpt_amd_v2.

Thanks,
Suravee
diff mbox series

Patch

diff --git a/include/uapi/linux/iommufd.h b/include/uapi/linux/iommufd.h
index bf4a1f8ab748..e2240d430dd1 100644
--- a/include/uapi/linux/iommufd.h
+++ b/include/uapi/linux/iommufd.h
@@ -389,14 +389,37 @@  struct iommu_hwpt_vtd_s1 {
 	__u32 __reserved;
 };
 
+/**
+ * struct iommu_hwpt_amd_v2 - AMD IOMMU specific user-managed
+ *                            v2 I/O page table data
+ * @gcr3: GCR3 guest physical ddress
+ * @gid: Guest ID
+ * @iommu_id: IOMMU host device ID
+ * @gdev_id: Guest device ID
+ * @gdom_id: Guest domain ID
+ * @glx: GCR3 table levels
+ * @guest_paging_mode: Guest v2 page table paging mode
+ */
+struct iommu_hwpt_amd_v2 {
+	__aligned_u64 gcr3;
+	__u32 gid;
+	__u32 iommu_id;
+	__u16 gdev_id;
+	__u16 gdom_id;
+	__u16 glx;
+	__u16 guest_paging_mode;
+};
+
 /**
  * enum iommu_hwpt_data_type - IOMMU HWPT Data Type
  * @IOMMU_HWPT_DATA_NONE: no data
  * @IOMMU_HWPT_DATA_VTD_S1: Intel VT-d stage-1 page table
+ * @IOMMU_HWPT_DATA_AMD_V2: AMD IOMMUv2 page table
  */
 enum iommu_hwpt_data_type {
 	IOMMU_HWPT_DATA_NONE,
 	IOMMU_HWPT_DATA_VTD_S1,
+	IOMMU_HWPT_DATA_AMD_V2,
 };
 
 /**