All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tina Zhang <tina.zhang@intel.com>
To: Jason Gunthorpe <jgg@ziepe.ca>, "Tian, Kevin" <kevin.tian@intel.com>
Cc: Lu Baolu <baolu.lu@linux.intel.com>,
	Michael Shavit <mshavit@google.com>,
	"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/5] Share sva domains with all devices bound to a mm
Date: Fri, 11 Aug 2023 09:12:25 +0800	[thread overview]
Message-ID: <67ca2485-8a87-f3e6-8eb9-6dfd6ebc0017@intel.com> (raw)
In-Reply-To: <ZNUQA01c8zIvHBQn@ziepe.ca>

Hi,

On 8/11/23 00:27, Jason Gunthorpe wrote:
> On Thu, Aug 10, 2023 at 07:49:11AM +0000, Tian, Kevin wrote:
>>> From: Zhang, Tina <tina.zhang@intel.com>
>>> Sent: Thursday, August 10, 2023 9:32 AM
>>>
>>> Hi,
>>>
>>> On 8/9/23 17:41, Tian, Kevin wrote:
>>>>> From: Zhang, Tina <tina.zhang@intel.com>
>>>>> Sent: Tuesday, August 8, 2023 3:50 PM
>>>>>
>>>>> A sva domain's lifetime begins with binding a device to a mm and ends
>>>>> by releasing all the bound devices from that sva domain. Technically,
>>>>> there could be more than one sva domain identified by the mm PASID for
>>>>> the use of bound devices issuing DMA transactions.
>>>>
>>>> Could you elaborate it with some concrete examples which motivate
>>>> this change?
>>> The motivation is to remove the superfluous IOTLB invalidation in
>>> current VT-d driver.
>>>
>>> Currently, in VT-d driver, due to lacking shared sva domain info, in
>>> intel_flush_svm_range(), both iotlb and dev-tlb invalidation operations
>>> are performed per-device. However, difference devices could be behind
>>> one IOMMU (e.g., four devices are behind one IOMMU) and invoking iotlb
>>> per-device gives us more iotlb invalidation than necessary (4 iotlb
>>> invalidation instead of 1). This issue may give more performance impact
>>> when in a virtual machine guest, as currently we have one virtual VT-d
>>> for in front of those virtual devices.
>>>
>>>
>>> This patch fixes this issue by attaching shared sva domain information
>>> to mm, so that it can be utilized in the mm_notifier_ops callbacks.
>>>
>>
>> that is one of the motivations. e.g. another one as Jason suggested
>> is to cleanup to decouple the common sva logic from enqcmd. Both
>> should be mentioned in next version cover letter.
> 
> I also want to purge all the de-duplication and refcounting code
> around mm's and sva_binds from the drivers. Eg see the mess this makes
> of SMMUv3.
> 
> Core code provides a single iommu_domain per-mm for SVA. Driver can
> rely on this optimization and does not need to de-duplicate.
> 
> Single domain tracks all attachments. Driver can optimize using that
> information by de-duplicating (eg ASID invalidation vs ATC
> invalidation)
> 
> After this we need to fix the domain allocation op to add a
> 'alloc_domain_sva(dev, mm_struct)' op so that the drivers can setup
> their SVA domains fully in a nice lock-safe environment.
Agree. These can be added to the to-do list.

Regards,
-Tina
> 
> Jason

  reply	other threads:[~2023-08-11  1:12 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-08  7:49 [PATCH 0/5] Share sva domains with all devices bound to a mm Tina Zhang
2023-08-08  7:49 ` [PATCH 1/5] iommu: Add mm_get_pasid() helper function Tina Zhang
2023-08-08 15:02   ` Jason Gunthorpe
2023-08-09  0:31     ` Baolu Lu
2023-08-09  9:47     ` Tian, Kevin
2023-08-09 12:31       ` Jason Gunthorpe
2023-08-08  7:49 ` [PATCH 2/5] iommu: Call helper function to get assigned pasid value Tina Zhang
2023-08-09  0:21   ` Baolu Lu
2023-08-09  9:49     ` Tian, Kevin
2023-08-09 10:58       ` Baolu Lu
2023-08-09 14:48         ` Jason Gunthorpe
2023-08-10  1:37           ` Baolu Lu
2023-08-10 16:30             ` Jason Gunthorpe
2023-08-09 12:35       ` Jason Gunthorpe
2023-08-10  7:52         ` Tian, Kevin
2023-08-10 16:36           ` Jason Gunthorpe
2023-08-11  3:18             ` Tian, Kevin
2023-08-08  7:49 ` [PATCH 3/5] mm: Add structure to keep sva information Tina Zhang
2023-08-08  7:49 ` [PATCH 4/5] iommu: Support mm PASID 1:n with sva domains Tina Zhang
2023-08-08 15:12   ` Jason Gunthorpe
2023-08-08 15:19     ` Jason Gunthorpe
2023-08-10  2:14       ` Tina Zhang
2023-08-08  7:49 ` [PATCH 5/5] mm: Deprecate pasid field Tina Zhang
2023-08-09  0:18 ` [PATCH 0/5] Share sva domains with all devices bound to a mm Baolu Lu
2023-08-09  9:44   ` Tian, Kevin
2023-08-09 10:51     ` Baolu Lu
2023-08-11  1:06       ` Tina Zhang
2023-08-09 14:46   ` Jason Gunthorpe
2023-08-10  1:23     ` Baolu Lu
2023-08-10  7:44       ` Tian, Kevin
2023-08-09  9:41 ` Tian, Kevin
2023-08-10  1:31   ` Tina Zhang
2023-08-10  7:49     ` Tian, Kevin
2023-08-10 16:27       ` Jason Gunthorpe
2023-08-11  1:12         ` Tina Zhang [this message]
2023-08-11  1:07       ` Tina Zhang

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=67ca2485-8a87-f3e6-8eb9-6dfd6ebc0017@intel.com \
    --to=tina.zhang@intel.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@ziepe.ca \
    --cc=kevin.tian@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mshavit@google.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.