From: "Suthikulpanit, Suravee" <suravee.suthikulpanit@amd.com>
To: Jason Gunthorpe <jgg@ziepe.ca>, Vasant Hegde <vasant.hegde@amd.com>
Cc: iommu@lists.linux.dev, joro@8bytes.org, wei.huang2@amd.com,
jsnitsel@redhat.com
Subject: Re: [PATCH 06/11] iommu/amd: Refactor helper function for attaching / detaching device
Date: Mon, 14 Aug 2023 22:33:08 -0700 [thread overview]
Message-ID: <57810db9-9a85-ca4e-0fc8-24dcaeb77fa3@amd.com> (raw)
In-Reply-To: <ZNbJTiolSya/3/Nu@ziepe.ca>
Jason,
On 8/11/2023 4:50 PM, Jason Gunthorpe wrote:
> On Fri, Aug 11, 2023 at 10:20:56PM +0530, Vasant Hegde wrote:
>
>> Our hardware is capable to boot with either V1 or V2 page table. By default
>> driver decides what is the best mode.
>> But if user wants he has a flexibility to choose V1 vs V2 page table. In that
>> mode we will adhere to user provided option and all devices will be put in that
>> mode.
>
> There is no valid reason for the user to override the kernel. If we do
> this for AMD we have to do it for every single driver that supports
> two formats. It makes no sense
>
> Jason
The amd_iommu=pgtbl_v2 was first introduced to enable nested IOMMU
translation w/ HW-vIOMMU support. This option is necessary for the guest
kernel since we need guest kernel to use IOMMU v2 page table for DMA-API
but the IOMMU driver is currently default to use pgtbl_v1 for DMA-API.
Currently, there is no good way to auto detect this use case.
In bare-metal environment, both pgtbl_v1 and pgtbl_v2 are supported. In
the future, we might consider migrate to use pgtbl_v2 by default.
However, there are certain concerns and restrictions w/ the use of pgtbl_v2:
* pgtbl_v2 is not supported with SNP-enabled system. SNP-enablement can
be detected with amd_iommu_snp_en, which is initialized early when the
amd_iommu_snp_enable() is called. So, IOMMU driver should be able to
automatically switch to use pgtbl_v1.
* There is an upcoming feature (e.g. TMPM :
https://www.amd.com/system/files/TechDocs/58151_0.51-PUB.pdf), which
requires devices to be setup w/ pgtbl_v1. However, the TMPM driver is
loaded after devices are probed. Therefore, this would require Linux to
boot with option amd_iommu=pgtbl_v1.
* IOMMU pgtbl_v1 and pgtbl_v2 are different from HW perspective, which
could yield different performance depending on the workload and
end-point devices. Therefore, the kernel option
amd_iommu=pgtbl_v1|pgtbl_v2 adds flexibility and give users additional
control if needed.
For SVA, we need to ensure that the iommu group is using pgtbl_v2 or in
pass-through mode (no page table setup) prior to enabling SVA for the
device. Currently, this would require the pgtbl_v2 option. However, we
could consider default to using v2 table for an IOMMU group if it
contains an PASID-capable device.
Thanks,
Suravee
next prev parent reply other threads:[~2023-08-15 5:33 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
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 [this message]
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=57810db9-9a85-ca4e-0fc8-24dcaeb77fa3@amd.com \
--to=suravee.suthikulpanit@amd.com \
--cc=iommu@lists.linux.dev \
--cc=jgg@ziepe.ca \
--cc=joro@8bytes.org \
--cc=jsnitsel@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.