Linux IOMMU Development
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@ziepe.ca>
To: Vasant Hegde <vasant.hegde@amd.com>
Cc: iommu@lists.linux.dev, joro@8bytes.org,
	suravee.suthikulpanit@amd.com, wei.huang2@amd.com,
	jsnitsel@redhat.com
Subject: Re: [PATCH 04/11] iommu/amd: Use protection_domain.flags to check page table mode
Date: Tue, 8 Aug 2023 12:35:50 -0300	[thread overview]
Message-ID: <ZNJg1mUd+WXBDVaD@ziepe.ca> (raw)
In-Reply-To: <20230808100232.5977-5-vasant.hegde@amd.com>

On Tue, Aug 08, 2023 at 10:02:25AM +0000, Vasant Hegde wrote:
> Page table mode (v1, v2 or pt) is per domain property. Recently we have
> enhanced protection_domain.pd_mode to track per domain page table mode.
> Use that variable to check the page table mode instead of global
> 'amd_iommu_pgtable' in {map/unmap}_pages path.
> 
> Signed-off-by: Vasant Hegde <vasant.hegde@amd.com>
> ---
>  drivers/iommu/amd/iommu.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

This is OK, but IMHO, it is much better to provide different ops for
the v1/v2 page table map/unmap functions since they don't really share
any code.

eg having a function pointer that does nothing other than call another
function pointer:

	struct io_pgtable_ops *ops = &domain->iop.iop.ops;
	if (ops->map_pages) {
		ret = ops->map_pages(ops, iova, paddr, pgsize,
				     pgcount, prot, gfp, mapped);
	}

Is quite inefficient these days. If you start with a map_pages_v2
domain op then you can just directly call iommu_v2_map_pages().

We did alot of work on the core side to enable this.

Jason

  reply	other threads:[~2023-08-08 15:35 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-08 10:02 [PATCH 00/11] iommu/amd: SVA support (part 2) - refactor support for GCR3 table Vasant Hegde
2023-08-08 10:02 ` [PATCH 01/11] iommu/amd: Rename helper function rlookup_amd_iommu() Vasant Hegde
2023-08-08 15:28   ` Jason Gunthorpe
2023-08-10 23:06     ` Suthikulpanit, Suravee
2023-08-11 13:06       ` Jason Gunthorpe
2023-08-08 10:02 ` [PATCH 02/11] iommu/amd: Introduce struct protection_domain.pd_mode Vasant Hegde
2023-08-08 15:30   ` Jason Gunthorpe
2023-08-11 10:04     ` Vasant Hegde
2023-08-11 13:21       ` Jason Gunthorpe
2023-08-08 10:02 ` [PATCH 03/11] iommu/amd: Introduce per-device GCR3 table Vasant Hegde
2023-08-08 15:32   ` Jason Gunthorpe
2023-08-10 23:31     ` Suthikulpanit, Suravee
2023-08-08 10:02 ` [PATCH 04/11] iommu/amd: Use protection_domain.flags to check page table mode Vasant Hegde
2023-08-08 15:35   ` Jason Gunthorpe [this message]
2023-08-11 10:10     ` Vasant Hegde
2023-08-08 10:02 ` [PATCH 05/11] iommu/amd: Refactor helper function for setting / clearing GCR3 Vasant Hegde
2023-08-08 10:02 ` [PATCH 06/11] iommu/amd: Refactor helper function for attaching / detaching device Vasant Hegde
2023-08-08 15:39   ` Jason Gunthorpe
2023-08-11 10:07     ` Vasant Hegde
2023-08-11 13:20       ` Jason Gunthorpe
2023-08-11 16:50         ` Vasant Hegde
2023-08-11 23:50           ` Jason Gunthorpe
2023-08-15  4:19             ` Tian, Kevin
2023-08-15  5:33             ` Suthikulpanit, Suravee
2023-08-15 11:42               ` Jason Gunthorpe
2023-08-08 10:02 ` [PATCH 07/11] iommu/amd: Refactor protection_domain helper functions Vasant Hegde
2023-08-08 10:02 ` [PATCH 08/11] iommu/amd: Refactor GCR3 table " Vasant Hegde
2023-08-08 10:02 ` [PATCH 09/11] iommu/amd: Introduce helper functions for AMD IOMMU v2 driver Vasant Hegde
2023-08-08 15:49   ` Jason Gunthorpe
2023-08-11  1:34     ` Suthikulpanit, Suravee
2023-08-11 13:17       ` Jason Gunthorpe
2023-08-11 16:51         ` Suthikulpanit, Suravee
2023-08-08 10:02 ` [PATCH 10/11] iommu/amd/iommu_v2: Add support to switch default domain to SVA mode Vasant Hegde
2023-08-08 15:51   ` Jason Gunthorpe
2023-08-08 10:02 ` [PATCH 11/11] iommu/amd: Remove unused GCR3 table parameters from struct protection_domain Vasant Hegde

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=ZNJg1mUd+WXBDVaD@ziepe.ca \
    --to=jgg@ziepe.ca \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=jsnitsel@redhat.com \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=vasant.hegde@amd.com \
    --cc=wei.huang2@amd.com \
    /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