Linux IOMMU Development
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Baolu Lu <baolu.lu@linux.intel.com>,
	Vasant Hegde <vasant.hegde@amd.com>,
	Joerg Roedel <joro@8bytes.org>, Jason Gunthorpe <jgg@ziepe.ca>,
	"iommu@lists.linux.dev" <iommu@lists.linux.dev>
Cc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
	Will Deacon <will@kernel.org>
Subject: Re: [RFC] iommu_ops->domain_alloc_paging() enhancement to support AMD IOMMU driver
Date: Fri, 28 Jun 2024 14:06:49 +0100	[thread overview]
Message-ID: <903594d3-00c3-42f8-8003-eef30f110510@arm.com> (raw)
In-Reply-To: <ece72a5e-e4fa-4fe9-9d03-ad31d7a4b212@linux.intel.com>

On 28/06/2024 1:23 pm, Baolu Lu wrote:
> On 2024/6/28 14:43, Vasant Hegde wrote:
>> We are working on adding domain_alloc_paging() support in AMD driver 
>> and came
>> across below issue.
>>
>> BACKGROUND:
>> ============
>> - AMD IOMMU HW has two different page tables : V1 (host page table) 
>> and V2
>> (guest page table). Only V2 page table supports PASID and PRI features.
>>
>> - With V2 page table we have an aliasing issue. Hence we added
>> per-device-domain-id when domain is configured with v2 page table. See 
>> upstream
>> commit 87a6f1f22c97 ("iommu/amd: Introduce per-device domain ID to fix 
>> potential
>> TLB aliasing issue")
>>
>>
>>
>> PROBLEM :
>> =========
>> With iommu_ops->domain_alloc_paging(dev) API AMD driver will chose 
>> best page
>> table based on device capabilities (V2 for PASID capable device and V1 
>> page
>> table for rest of the devices).
>>
>> But we would like to continue enforcing V1 page table for UNMANAGED 
>> domain. As
>> in terms of IOMMU caching, it performs better than V2 page table.
>>
>> Also while adding SVA in AMD driver Jason mentioned that we should 
>> support PASID
>> with UNMANAGED domain. As I understand currently we don't have this 
>> feature in
>> upstream but we would like to support it in future. Keeping this use 
>> case also
>> in mind, we came up with below two options :
>>
>>    1 - Pass domain type : domain_alloc_paging(dev, type)
>>     When we add PASID with UNMANAGED domain we need a way to 
>> differentiate the
>> domain 'type' (See below attach sample code)
> 
> The domain type is not enough for the iommu driver to differentiate
> between device or PASID. For example, a domain of type UNMANAGED could
> be attached to either a device or a PASID. Furthermore, SVA domain is
> not a paging domain.
> 
>>    2 - Introduce new flag for domain_alloc_paging()
>>      Something like :
>>      #define DOMAIN_FLAG_UNMANAGED    0x01
>>      #define DOMAIN_FLAG_UNMANAGED_SVA    0x02
>>
>>      domain_alloc_paging(dev, flag)
>>      For now we will have 'DOMAIN_PAGING_UNMANAGED'.
> 
> Add an allocation flag seems to work. It doesn't indicate any type of
> domain. Instead, it indicates the required iommu feature.
> 
> Something like
> 
> #define DOMAIN_ALLOC_FLAG_PASID        0x1
> 
> means the allocated domain requires PASID to support on both device and
> IOMMU. If the hardware lacks this support, it should return failure.

Yeah, we could do with something sufficiently general, as we'll also 
have a need for passing pagetable-format options through to drivers to 
be able to replace iommu_set_pgtable_quirks().

Thanks,
Robin.

  reply	other threads:[~2024-06-28 13:06 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-28  6:43 [RFC] iommu_ops->domain_alloc_paging() enhancement to support AMD IOMMU driver Vasant Hegde
2024-06-28 12:23 ` Baolu Lu
2024-06-28 13:06   ` Robin Murphy [this message]
2024-06-28 17:08     ` Vasant Hegde
2024-06-28 17:58       ` Robin Murphy
2024-07-01 10:28         ` Vasant Hegde
2024-06-28 14:50   ` Vasant Hegde
2024-06-28 15:34     ` Jason Gunthorpe
2024-06-28 13:03 ` Jason Gunthorpe
2024-06-28 17:49   ` Vasant Hegde
2024-06-28 18:04     ` Jason Gunthorpe
2024-07-01 10:48       ` Vasant Hegde
2024-07-01 17:26         ` Jason Gunthorpe
2024-07-03  5:42           ` Vasant Hegde
2024-07-03  6:57             ` Yi Liu
2024-07-09 18:23               ` Jason Gunthorpe
2024-07-10  4:17                 ` Yi Liu
2024-07-11 23:49                   ` Jason Gunthorpe
2024-07-12 13:40                     ` Robin Murphy
2024-07-12 13:53                       ` Jason Gunthorpe
2024-07-12 15:12                         ` Robin Murphy
2024-07-12 15:19                           ` Jason Gunthorpe
2024-07-15  8:46                       ` Yi Liu
2024-07-11 10:15               ` Vasant Hegde
2024-07-11 13:56                 ` Yi Liu
2024-07-12  1:39                   ` Baolu Lu
2024-07-12  2:43                     ` Yi Liu
2024-07-15 10:39                   ` Vasant Hegde
2024-07-16  7:43                     ` Yi Liu
2024-07-16 13:41                       ` Jason Gunthorpe

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=903594d3-00c3-42f8-8003-eef30f110510@arm.com \
    --to=robin.murphy@arm.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@ziepe.ca \
    --cc=joro@8bytes.org \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=vasant.hegde@amd.com \
    --cc=will@kernel.org \
    /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