[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240308134856.GI9179@nvidia.com>
Date: Fri, 8 Mar 2024 09:48:56 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Suravee Suthikulpanit <suravee.suthikulpanit@....com>
Cc: linux-kernel@...r.kernel.org, iommu@...ts.linux.dev, joro@...tes.org,
yi.l.liu@...el.com, kevin.tian@...el.com, nicolinc@...dia.com,
eric.auger@...hat.com, vasant.hegde@....com, jon.grimm@....com,
santosh.shukla@....com, Dhaval.Giani@....com, pandoh@...gle.com,
loganodell@...gle.com
Subject: Re: [RFCv2 PATCH 1/7] iommu/amd: Introduce struct gcr3_tbl_info.giov
On Thu, Jan 11, 2024 at 06:06:40PM -0600, Suravee Suthikulpanit wrote:
> To track DTE[GIOV] programming during IOMMU domain attach, also add logic
> to determine if the GIOV is required, and set the variable accordinglly.
>
> This is also a preparation for adding nested domain support, where the GIOV
> setting is determined by the child domain.
>
> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@....com>
> ---
> drivers/iommu/amd/amd_iommu_types.h | 1 +
> drivers/iommu/amd/iommu.c | 11 +++++++++--
> 2 files changed, 10 insertions(+), 2 deletions(-)
I really think the DTE handling needs to be cleaned up before nesting
will be easy.
Various bits of the DTE should just flow directly through from the
VM's version of the DTE, it is going to be a mess to do that in this
manner
> @@ -2067,6 +2066,14 @@ static int do_attach(struct iommu_dev_data *dev_data,
> free_gcr3_table(dev_data);
> return ret;
> }
> +
> + /*
> + * GIOV is required for PD_MODE_V2 because we need
> + * to support the case where the end-point device
> + * does not have PASID in the TLP prefix when setting
> + * up to use the v2 table.
> + */
> + dev_data->gcr3_info.giov = true;
Ie who clears this once you set it ? :(
Jason
Powered by blists - more mailing lists