From: Vasant Hegde <vasant.hegde@amd.com>
To: Yi Liu <yi.l.liu@intel.com>, Jason Gunthorpe <jgg@ziepe.ca>
Cc: iommu@lists.linux.dev, joro@8bytes.org, will@kernel.org,
robin.murphy@arm.com, suravee.suthikulpanit@amd.com,
baolu.lu@linux.intel.com, kevin.tian@intel.com
Subject: Re: [PATCH 1/5] iommu: Enhance domain allocation code to take additional flags
Date: Sat, 24 Aug 2024 20:17:45 +0530 [thread overview]
Message-ID: <8215e4d4-2077-4fca-a002-27ddbfc0ddf2@amd.com> (raw)
In-Reply-To: <0ca31cc6-1741-40d1-b8c1-20e6b4fc955a@intel.com>
Yi,
On 8/23/2024 2:28 PM, Yi Liu wrote:
> On 2024/8/22 20:44, Jason Gunthorpe wrote:
>> On Thu, Aug 22, 2024 at 07:27:39PM +0800, Yi Liu wrote:
>>> On 2024/8/22 00:31, Jason Gunthorpe wrote:
>>>
>>>>> @@ -359,11 +359,17 @@ struct iommu_vfio_ioas {
>>>>> * enforced on device attachment
>>>>> * @IOMMU_HWPT_FAULT_ID_VALID: The fault_id field of hwpt allocation
>>>>> data is
>>>>> * valid.
>>>>> + * @IOMMUFD_HWPT_ALLOC_PASID: When the domain is used on a device, with no
>>>>> + * PASID, the device will support later attaching
>>>>> + * a PASID as well. Some HW requires a specific
>>>>> + * domain format on the device to allow PASID to
>>>>> + * work.
>>>>
>>>> Maybe:
>>>>
>>>> Requests a domain that can be used with PASID. The domain can be
>>>> attached to any PASID on the device. Any domain attached to the
>>>> non-PASID part of the device must also be flaged, otherwise attaching
>>>> a PASID will blocked.
>>>>
>>>> Yi will need to add a check that IOMMUFD_HWPT_ALLOC_PASID was
>>>> specified on the RID domain while processing attach on the PASID
>>>> domain.
>>>
>>> this means if userspace wants to user pasid on a device, it should allocate
>>> hwpt with this flag, no matter the hwpt is going to be attached to RID or
>>> pasid. is it?
>>
>> Yes>>
>>> I still have a confusion. Say on AMD, is it a legitimate configuration that
>>> the RID is attached to a domain that uses V1 page table while pasid is
>>> attached to domains that use V2 page table? From architecture p.o.v., it
>>> seems allowed.
>>
>> I think that is exactly what they have been saying their design cannot
>> do.
>
> ok. I don't think Intel has this limitation. RID/PASID is free to use s1
> or s2 format page table. So such enforcement is nop on Intel platform.
>
>>
>> If you want to use PASID you must install a GCR3 table full of V2
>> tables. Doing this denies use of the V1 format for anything except a
>> NESTING_PARENT.
>
> thanks for the explanation. So if pasid is to be used, amd iommu driver
> just programs the GCR3 tables and the request without pasid would use the
> v2 page table installed at pasid#0. It does not use the
> DTE->host_page_table at all. I remember the DTE->host_page_table uses v1
> format.
Right. Only V2 page table supports PASID. So when user space requests hwpt with
PASID AMD driver will allocate V2 page table with GCR3 setup and updated DTE. So
it can handle attaching Device ID (uses PASID#0) and PASID (as GCR3 table is
already setup).
Note that when we use NESTED page table it will have both v1 (L2 / stage 2
level) and v2 page table (L1 / stage 1 level). Even in this setup V2 page table
inside guest can support PASID.
Hope this clarifies.
-Vasant
>
next prev parent reply other threads:[~2024-08-24 14:48 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-21 13:35 [PATCH 0/5] iommu: Domain allocation enhancements Vasant Hegde
2024-08-21 13:35 ` [PATCH 1/5] iommu: Enhance domain allocation code to take additional flags Vasant Hegde
2024-08-21 16:31 ` Jason Gunthorpe
2024-08-22 1:50 ` Baolu Lu
2024-08-22 12:43 ` Jason Gunthorpe
2024-08-23 2:47 ` Baolu Lu
2024-08-26 8:08 ` Tian, Kevin
2024-08-26 8:34 ` Baolu Lu
2024-08-26 8:59 ` Tian, Kevin
2024-08-26 13:51 ` Jason Gunthorpe
2024-08-26 8:47 ` Vasant Hegde
2024-08-26 13:45 ` Jason Gunthorpe
2024-08-22 11:27 ` Yi Liu
2024-08-22 12:44 ` Jason Gunthorpe
2024-08-23 8:58 ` Yi Liu
2024-08-24 14:47 ` Vasant Hegde [this message]
2024-08-28 21:52 ` Jacob Pan
2024-08-29 10:51 ` Vasant Hegde
2024-08-29 12:10 ` Jason Gunthorpe
2024-08-29 12:47 ` Vasant Hegde
2024-08-29 13:11 ` Jason Gunthorpe
2024-09-11 10:54 ` Vasant Hegde
2024-08-29 17:40 ` Jacob Pan
[not found] ` <66d0b2a1.630a0220.1dd301.daceSMTPIN_ADDED_BROKEN@mx.google.com>
2024-08-30 15:00 ` Jason Gunthorpe
2024-08-26 8:36 ` Vasant Hegde
2024-08-26 13:56 ` Jason Gunthorpe
2024-08-29 12:34 ` Vasant Hegde
2024-08-22 1:38 ` Baolu Lu
2024-08-22 12:40 ` Jason Gunthorpe
2024-08-23 2:04 ` Baolu Lu
2024-08-26 6:09 ` Vasant Hegde
2024-08-22 2:10 ` kernel test robot
2024-08-22 3:03 ` kernel test robot
2024-08-22 5:07 ` kernel test robot
2024-08-21 13:35 ` [PATCH 2/5] iommu/amd: Separate page table setup from domain allocation Vasant Hegde
2024-08-21 16:40 ` Jason Gunthorpe
2024-08-21 13:35 ` [PATCH 3/5] iommu/amd: Pass page table type to pdomain_setup_pgtable() Vasant Hegde
2024-08-21 13:35 ` [PATCH 4/5] iommu/amd: Enhance domain_alloc_user() to allocate PASID capable domain Vasant Hegde
2024-08-21 13:35 ` [PATCH 5/5] iommu/amd: Add iommu_ops->domain_alloc_paging support Vasant Hegde
2024-08-21 15:57 ` Jason Gunthorpe
2024-09-11 10:44 ` 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=8215e4d4-2077-4fca-a002-27ddbfc0ddf2@amd.com \
--to=vasant.hegde@amd.com \
--cc=baolu.lu@linux.intel.com \
--cc=iommu@lists.linux.dev \
--cc=jgg@ziepe.ca \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=robin.murphy@arm.com \
--cc=suravee.suthikulpanit@amd.com \
--cc=will@kernel.org \
--cc=yi.l.liu@intel.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