mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Kunkun Jiang <jiangkunkun@huawei.com>
To: Robin Murphy <robin.murphy@arm.com>,
	Will Deacon <will@kernel.org>,
	"Linux IOMMU" <iommu@lists.linux-foundation.org>,
	open list <linux-kernel@vger.kernel.org>
Cc: <wanghaibin.wang@huawei.com>, Zenghui Yu <yuzenghui@huawei.com>,
	"Keqian Zhu" <zhukeqian1@huawei.com>
Subject: Re: [question] Assign multiple devices from different SMMUs to a arm_smmu_domain
Date: Wed, 8 Sep 2021 13:06:46 +0800	[thread overview]
Message-ID: <d788d448-f2f2-1cb5-440c-d59dbdd27eab@huawei.com> (raw)
In-Reply-To: <202f32cd-8036-563e-028b-781b999766be@arm.com>

On 2021/9/7 17:43, Robin Murphy wrote:
> On 2021-09-07 08:41, Kunkun Jiang wrote:
>> Hi all,
>>
>> I am working on VFIO DMA dirty pages tracking based on ARM SMMU HTTU,
>> and have done a lot of testing.In the test, I found a problem that 
>> greatly affects
>> performance of VFIO DMA dirty pages tracking.
>>
>> According to the current arm-smmu-v3 driver, multiple VFIO pass-through
>> device comes from different SMMUs will be assigned to different
>> arm_smmu_domain. It will create page table for each arm_smmu_domain,
>> even though these page tables are exactly the same. Bacause dirty pages
>> tracking needs to traverse the page table, multiple page tables will 
>> make
>> performance worse.
>>
>> I learned the ARM SMMUv3 spec and had some exchanges with my colleagues
>> who work on SMMU hardware. I did not find the restriction that multiple
>> SMMUs cannot share the same page table. We migth be able to do this like
>> x86 IOMMU. If I have missed something, please point it out.
>
> Sure, it's not impossible, there are just a lot of fiddly 
> considerations, mostly around how to handle SMMU instances with 
> different capabilities. We haven't had a strong need to support this 
> case so far, so we've simply been avoiding all that complexity.
Yes, there's a lot to consider here. I'll try to analyze it carefully. 
We can discuss
some of the difficulties in the future. From the perspective of 
improving the
performance of VFIO DMA dirty pages tracking, it is worth supporting 
this feature.

Thanks,
Kunkun Jiang
>
> Robin.
>
>> Looking forward to your suggestions.😁
>>
>> Thanks,
>> Kunkun Jiang
>>
> .



      reply	other threads:[~2021-09-08  5:07 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-07  7:41 Kunkun Jiang
2021-09-07  9:43 ` Robin Murphy
2021-09-08  5:06   ` Kunkun Jiang [this message]

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=d788d448-f2f2-1cb5-440c-d59dbdd27eab@huawei.com \
    --to=jiangkunkun@huawei.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=wanghaibin.wang@huawei.com \
    --cc=will@kernel.org \
    --cc=yuzenghui@huawei.com \
    --cc=zhukeqian1@huawei.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

all inboxes | Powered by JetHome®