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
next prev parent 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