Re: [PATCH v13 07/15] iommu/smmuv3: Allow stage 1 invalidation with unmanaged ASIDs
Hi Shameer, On 12/3/20 7:42 PM, Shameerali Kolothum Thodi wrote: > Hi Eric, > >> -Original Message- >> From: kvmarm-boun...@lists.cs.columbia.edu >> [mailto:kvmarm-boun...@lists.cs.columbia.edu] On Behalf Of Auger Eric >> Sent: 01 December 2020 13:59 >> To: wangxingang >> Cc: Xieyingtai ; jean-phili...@linaro.org; >> k...@vger.kernel.org; m...@kernel.org; j...@8bytes.org; w...@kernel.org; >> iommu@lists.linux-foundation.org; linux-ker...@vger.kernel.org; >> vivek.gau...@arm.com; alex.william...@redhat.com; >> zhangfei@linaro.org; robin.mur...@arm.com; >> kvm...@lists.cs.columbia.edu; eric.auger....@gmail.com >> Subject: Re: [PATCH v13 07/15] iommu/smmuv3: Allow stage 1 invalidation with >> unmanaged ASIDs >> >> Hi Xingang, >> >> On 12/1/20 2:33 PM, Xingang Wang wrote: >>> Hi Eric >>> >>> On Wed, 18 Nov 2020 12:21:43, Eric Auger wrote: >>>> @@ -1710,7 +1710,11 @@ static void arm_smmu_tlb_inv_context(void >> *cookie) >>>> * insertion to guarantee those are observed before the TLBI. Do be >>>> * careful, 007. >>>> */ >>>> - if (smmu_domain->stage == ARM_SMMU_DOMAIN_S1) { >>>> + if (ext_asid >= 0) { /* guest stage 1 invalidation */ >>>> + cmd.opcode = CMDQ_OP_TLBI_NH_ASID; >>>> + cmd.tlbi.asid = ext_asid; >>>> + cmd.tlbi.vmid = smmu_domain->s2_cfg.vmid; >>>> + } else if (smmu_domain->stage == ARM_SMMU_DOMAIN_S1) { >>> >>> Found a problem here, the cmd for guest stage 1 invalidation is built, >>> but it is not delivered to smmu. >>> >> >> Thank you for the report. I will fix that soon. With that fixed, have >> you been able to run vSVA on top of the series. Do you need other stuff >> to be fixed at SMMU level? > > I am seeing another issue with this series. This is when you have the vSMMU > in non-strict mode(iommu.strict=0). Any network pass-through dev with iperf > run > will be enough to reproduce the issue. It may randomly stop/hang. > > It looks like the .flush_iotlb_all from guest is not propagated down to the > host > correctly. I have a temp hack to fix this in Qemu wherein CMDQ_OP_TLBI_NH_ASID > will result in a CACHE_INVALIDATE with IOMMU_INV_GRANU_PASID flag and archid > set. Thank you for the analysis. Indeed the NH_ASID was not properly handled as asid info was not passed down. I fixed domain invalidation and added asid based invalidation. Thanks Eric > > Please take a look and let me know. > > As I am going to respin soon, please let me >> know what is the best branch to rebase to alleviate your integration. > > Please find the latest kernel and Qemu branch with vSVA support added here, > > https://github.com/hisilicon/kernel-dev/tree/5.10-rc4-2stage-v13-vsva > https://github.com/hisilicon/qemu/tree/v5.2.0-rc1-2stage-rfcv7-vsva > > I have done some basic minimum vSVA tests on a HiSilicon D06 board with > a zip dev that supports STALL. All looks good so far apart from the issues > that have been already reported/discussed. > > The kernel branch is actually a rebase of sva/uacce related patches from a > Linaro branch here, > > https://github.com/Linaro/linux-kernel-uadk/tree/uacce-devel-5.10 > > I think going forward it will be good(if possible) to respin your series on > top of > a sva branch with STALL/PRI support added. > > Hi Jean/zhangfei, > Is it possible to have a branch with minimum required SVA/UACCE related > patches > that are already public and can be a "stable" candidate for future respin of > Eric's series? > Please share your thoughts. > > Thanks, > Shameer > >> Best Regards >> >> Eric >> >> ___ >> kvmarm mailing list >> kvm...@lists.cs.columbia.edu >> https://lists.cs.columbia.edu/mailman/listinfo/kvmarm > ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v13 07/15] iommu/smmuv3: Allow stage 1 invalidation with unmanaged ASIDs
Hi Jean, On 1/14/21 6:33 PM, Jean-Philippe Brucker wrote: > Hi Eric, > > On Thu, Jan 14, 2021 at 05:58:27PM +0100, Auger Eric wrote: The uacce-devel branches from > https://github.com/Linaro/linux-kernel-uadk do provide this at the moment > (they track the latest sva/zip-devel branch > https://jpbrucker.net/git/linux/ which is roughly based on mainline.) >> As I plan to respin shortly, please could you confirm the best branch to >> rebase on still is that one (uacce-devel from the linux-kernel-uadk git >> repo). Is it up to date? Commits seem to be quite old there. > > Right I meant the uacce-devel-X branches. The uacce-devel-5.11 branch > currently has the latest patches OK thanks! Eric > > Thanks, > Jean > ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v13 07/15] iommu/smmuv3: Allow stage 1 invalidation with unmanaged ASIDs
Hi Eric, On Thu, Jan 14, 2021 at 05:58:27PM +0100, Auger Eric wrote: > >> The uacce-devel branches from > >>> https://github.com/Linaro/linux-kernel-uadk do provide this at the moment > >>> (they track the latest sva/zip-devel branch > >>> https://jpbrucker.net/git/linux/ which is roughly based on mainline.) > As I plan to respin shortly, please could you confirm the best branch to > rebase on still is that one (uacce-devel from the linux-kernel-uadk git > repo). Is it up to date? Commits seem to be quite old there. Right I meant the uacce-devel-X branches. The uacce-devel-5.11 branch currently has the latest patches Thanks, Jean ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH v13 07/15] iommu/smmuv3: Allow stage 1 invalidation with unmanaged ASIDs
Hi Eric, > -Original Message- > From: Auger Eric [mailto:eric.au...@redhat.com] > Sent: 14 January 2021 16:58 > To: Shameerali Kolothum Thodi ; > Jean-Philippe Brucker > Cc: Xieyingtai ; alex.william...@redhat.com; > wangxingang ; k...@vger.kernel.org; > m...@kernel.org; linux-ker...@vger.kernel.org; vivek.gau...@arm.com; > iommu@lists.linux-foundation.org; qubingbing ; > Zengtao (B) ; zhangfei@linaro.org; > eric.auger@gmail.com; w...@kernel.org; kvm...@lists.cs.columbia.edu; > robin.mur...@arm.com > Subject: Re: [PATCH v13 07/15] iommu/smmuv3: Allow stage 1 invalidation with > unmanaged ASIDs > > Hi Shameer, Jean-Philippe, > > On 12/4/20 11:23 AM, Auger Eric wrote: > > Hi Shameer, Jean-Philippe, > > > > On 12/4/20 11:20 AM, Shameerali Kolothum Thodi wrote: > >> Hi Jean, > >> > >>> -Original Message- > >>> From: Jean-Philippe Brucker [mailto:jean-phili...@linaro.org] > >>> Sent: 04 December 2020 09:54 > >>> To: Shameerali Kolothum Thodi > > >>> Cc: Auger Eric ; wangxingang > >>> ; Xieyingtai ; > >>> k...@vger.kernel.org; m...@kernel.org; j...@8bytes.org; > w...@kernel.org; > >>> iommu@lists.linux-foundation.org; linux-ker...@vger.kernel.org; > >>> vivek.gau...@arm.com; alex.william...@redhat.com; > >>> zhangfei@linaro.org; robin.mur...@arm.com; > >>> kvm...@lists.cs.columbia.edu; eric.auger@gmail.com; Zengtao (B) > >>> ; qubingbing > >>> Subject: Re: [PATCH v13 07/15] iommu/smmuv3: Allow stage 1 invalidation > with > >>> unmanaged ASIDs > >>> > >>> Hi Shameer, > >>> > >>> On Thu, Dec 03, 2020 at 06:42:57PM +, Shameerali Kolothum Thodi > wrote: > >>>> Hi Jean/zhangfei, > >>>> Is it possible to have a branch with minimum required SVA/UACCE related > >>> patches > >>>> that are already public and can be a "stable" candidate for future respin > of > >>> Eric's series? > >>>> Please share your thoughts. > >>> > >>> By "stable" you mean a fixed branch with the latest SVA/UACCE patches > >>> based on mainline? > >> > >> Yes. > >> > >> The uacce-devel branches from > >>> https://github.com/Linaro/linux-kernel-uadk do provide this at the moment > >>> (they track the latest sva/zip-devel branch > >>> https://jpbrucker.net/git/linux/ which is roughly based on mainline.) > As I plan to respin shortly, please could you confirm the best branch to > rebase on still is that one (uacce-devel from the linux-kernel-uadk git > repo). Is it up to date? Commits seem to be quite old there. I think it is the uacce-devel-5.11 branch, but will wait for Jean or Zhangfei to confirm. Thanks, Shameer > Thanks > > Eric > >> > >> Thanks. > >> > >> Hi Eric, > >> > >> Could you please take a look at the above branches and see whether it make > sense > >> to rebase on top of either of those? > >> > >> From vSVA point of view, it will be less rebase hassle if we can do that. > > > > Sure. I will rebase on top of this ;-) > > > > Thanks > > > > Eric > >> > >> Thanks, > >> Shameer > >> > >>> Thanks, > >>> Jean > >> > > > > ___ > > iommu mailing list > > iommu@lists.linux-foundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/iommu > > ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v13 07/15] iommu/smmuv3: Allow stage 1 invalidation with unmanaged ASIDs
Hi Shameer, Jean-Philippe, On 12/4/20 11:23 AM, Auger Eric wrote: > Hi Shameer, Jean-Philippe, > > On 12/4/20 11:20 AM, Shameerali Kolothum Thodi wrote: >> Hi Jean, >> >>> -Original Message- >>> From: Jean-Philippe Brucker [mailto:jean-phili...@linaro.org] >>> Sent: 04 December 2020 09:54 >>> To: Shameerali Kolothum Thodi >>> Cc: Auger Eric ; wangxingang >>> ; Xieyingtai ; >>> k...@vger.kernel.org; m...@kernel.org; j...@8bytes.org; w...@kernel.org; >>> iommu@lists.linux-foundation.org; linux-ker...@vger.kernel.org; >>> vivek.gau...@arm.com; alex.william...@redhat.com; >>> zhangfei@linaro.org; robin.mur...@arm.com; >>> kvm...@lists.cs.columbia.edu; eric.auger....@gmail.com; Zengtao (B) >>> ; qubingbing >>> Subject: Re: [PATCH v13 07/15] iommu/smmuv3: Allow stage 1 invalidation with >>> unmanaged ASIDs >>> >>> Hi Shameer, >>> >>> On Thu, Dec 03, 2020 at 06:42:57PM +, Shameerali Kolothum Thodi wrote: >>>> Hi Jean/zhangfei, >>>> Is it possible to have a branch with minimum required SVA/UACCE related >>> patches >>>> that are already public and can be a "stable" candidate for future respin >>>> of >>> Eric's series? >>>> Please share your thoughts. >>> >>> By "stable" you mean a fixed branch with the latest SVA/UACCE patches >>> based on mainline? >> >> Yes. >> >> The uacce-devel branches from >>> https://github.com/Linaro/linux-kernel-uadk do provide this at the moment >>> (they track the latest sva/zip-devel branch >>> https://jpbrucker.net/git/linux/ which is roughly based on mainline.) As I plan to respin shortly, please could you confirm the best branch to rebase on still is that one (uacce-devel from the linux-kernel-uadk git repo). Is it up to date? Commits seem to be quite old there. Thanks Eric >> >> Thanks. >> >> Hi Eric, >> >> Could you please take a look at the above branches and see whether it make >> sense >> to rebase on top of either of those? >> >> From vSVA point of view, it will be less rebase hassle if we can do that. > > Sure. I will rebase on top of this ;-) > > Thanks > > Eric >> >> Thanks, >> Shameer >> >>> Thanks, >>> Jean >> > > ___ > iommu mailing list > iommu@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/iommu > ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v13 07/15] iommu/smmuv3: Allow stage 1 invalidation with unmanaged ASIDs
Hi Shameer, Jean-Philippe, On 12/4/20 11:20 AM, Shameerali Kolothum Thodi wrote: > Hi Jean, > >> -Original Message- >> From: Jean-Philippe Brucker [mailto:jean-phili...@linaro.org] >> Sent: 04 December 2020 09:54 >> To: Shameerali Kolothum Thodi >> Cc: Auger Eric ; wangxingang >> ; Xieyingtai ; >> k...@vger.kernel.org; m...@kernel.org; j...@8bytes.org; w...@kernel.org; >> iommu@lists.linux-foundation.org; linux-ker...@vger.kernel.org; >> vivek.gau...@arm.com; alex.william...@redhat.com; >> zhangfei@linaro.org; robin.mur...@arm.com; >> kvm...@lists.cs.columbia.edu; eric.auger....@gmail.com; Zengtao (B) >> ; qubingbing >> Subject: Re: [PATCH v13 07/15] iommu/smmuv3: Allow stage 1 invalidation with >> unmanaged ASIDs >> >> Hi Shameer, >> >> On Thu, Dec 03, 2020 at 06:42:57PM +, Shameerali Kolothum Thodi wrote: >>> Hi Jean/zhangfei, >>> Is it possible to have a branch with minimum required SVA/UACCE related >> patches >>> that are already public and can be a "stable" candidate for future respin of >> Eric's series? >>> Please share your thoughts. >> >> By "stable" you mean a fixed branch with the latest SVA/UACCE patches >> based on mainline? > > Yes. > > The uacce-devel branches from >> https://github.com/Linaro/linux-kernel-uadk do provide this at the moment >> (they track the latest sva/zip-devel branch >> https://jpbrucker.net/git/linux/ which is roughly based on mainline.) > > Thanks. > > Hi Eric, > > Could you please take a look at the above branches and see whether it make > sense > to rebase on top of either of those? > > From vSVA point of view, it will be less rebase hassle if we can do that. Sure. I will rebase on top of this ;-) Thanks Eric > > Thanks, > Shameer > >> Thanks, >> Jean > ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v13 07/15] iommu/smmuv3: Allow stage 1 invalidation with unmanaged ASIDs
Hi Shameer, On Thu, Dec 03, 2020 at 06:42:57PM +, Shameerali Kolothum Thodi wrote: > Hi Jean/zhangfei, > Is it possible to have a branch with minimum required SVA/UACCE related > patches > that are already public and can be a "stable" candidate for future respin of > Eric's series? > Please share your thoughts. By "stable" you mean a fixed branch with the latest SVA/UACCE patches based on mainline? The uacce-devel branches from https://github.com/Linaro/linux-kernel-uadk do provide this at the moment (they track the latest sva/zip-devel branch https://jpbrucker.net/git/linux/ which is roughly based on mainline.) Thanks, Jean ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH v13 07/15] iommu/smmuv3: Allow stage 1 invalidation with unmanaged ASIDs
Hi Eric, > -Original Message- > From: kvmarm-boun...@lists.cs.columbia.edu > [mailto:kvmarm-boun...@lists.cs.columbia.edu] On Behalf Of Auger Eric > Sent: 01 December 2020 13:59 > To: wangxingang > Cc: Xieyingtai ; jean-phili...@linaro.org; > k...@vger.kernel.org; m...@kernel.org; j...@8bytes.org; w...@kernel.org; > iommu@lists.linux-foundation.org; linux-ker...@vger.kernel.org; > vivek.gau...@arm.com; alex.william...@redhat.com; > zhangfei@linaro.org; robin.mur...@arm.com; > kvm...@lists.cs.columbia.edu; eric.auger....@gmail.com > Subject: Re: [PATCH v13 07/15] iommu/smmuv3: Allow stage 1 invalidation with > unmanaged ASIDs > > Hi Xingang, > > On 12/1/20 2:33 PM, Xingang Wang wrote: > > Hi Eric > > > > On Wed, 18 Nov 2020 12:21:43, Eric Auger wrote: > >> @@ -1710,7 +1710,11 @@ static void arm_smmu_tlb_inv_context(void > *cookie) > >> * insertion to guarantee those are observed before the TLBI. Do be > >> * careful, 007. > >> */ > >> - if (smmu_domain->stage == ARM_SMMU_DOMAIN_S1) { > >> + if (ext_asid >= 0) { /* guest stage 1 invalidation */ > >> + cmd.opcode = CMDQ_OP_TLBI_NH_ASID; > >> + cmd.tlbi.asid = ext_asid; > >> + cmd.tlbi.vmid = smmu_domain->s2_cfg.vmid; > >> + } else if (smmu_domain->stage == ARM_SMMU_DOMAIN_S1) { > > > > Found a problem here, the cmd for guest stage 1 invalidation is built, > > but it is not delivered to smmu. > > > > Thank you for the report. I will fix that soon. With that fixed, have > you been able to run vSVA on top of the series. Do you need other stuff > to be fixed at SMMU level? I am seeing another issue with this series. This is when you have the vSMMU in non-strict mode(iommu.strict=0). Any network pass-through dev with iperf run will be enough to reproduce the issue. It may randomly stop/hang. It looks like the .flush_iotlb_all from guest is not propagated down to the host correctly. I have a temp hack to fix this in Qemu wherein CMDQ_OP_TLBI_NH_ASID will result in a CACHE_INVALIDATE with IOMMU_INV_GRANU_PASID flag and archid set. Please take a look and let me know. As I am going to respin soon, please let me > know what is the best branch to rebase to alleviate your integration. Please find the latest kernel and Qemu branch with vSVA support added here, https://github.com/hisilicon/kernel-dev/tree/5.10-rc4-2stage-v13-vsva https://github.com/hisilicon/qemu/tree/v5.2.0-rc1-2stage-rfcv7-vsva I have done some basic minimum vSVA tests on a HiSilicon D06 board with a zip dev that supports STALL. All looks good so far apart from the issues that have been already reported/discussed. The kernel branch is actually a rebase of sva/uacce related patches from a Linaro branch here, https://github.com/Linaro/linux-kernel-uadk/tree/uacce-devel-5.10 I think going forward it will be good(if possible) to respin your series on top of a sva branch with STALL/PRI support added. Hi Jean/zhangfei, Is it possible to have a branch with minimum required SVA/UACCE related patches that are already public and can be a "stable" candidate for future respin of Eric's series? Please share your thoughts. Thanks, Shameer > Best Regards > > Eric > > ___ > kvmarm mailing list > kvm...@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/kvmarm ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v13 07/15] iommu/smmuv3: Allow stage 1 invalidation with unmanaged ASIDs
Thanks for your reply. We are testing vSVA, and will let you know if other problems are found. On 2020/12/1 21:58, Auger Eric wrote: Hi Xingang, On 12/1/20 2:33 PM, Xingang Wang wrote: Hi Eric On Wed, 18 Nov 2020 12:21:43, Eric Auger wrote: @@ -1710,7 +1710,11 @@ static void arm_smmu_tlb_inv_context(void *cookie) * insertion to guarantee those are observed before the TLBI. Do be * careful, 007. */ - if (smmu_domain->stage == ARM_SMMU_DOMAIN_S1) { + if (ext_asid >= 0) { /* guest stage 1 invalidation */ + cmd.opcode = CMDQ_OP_TLBI_NH_ASID; + cmd.tlbi.asid = ext_asid; + cmd.tlbi.vmid = smmu_domain->s2_cfg.vmid; + } else if (smmu_domain->stage == ARM_SMMU_DOMAIN_S1) { Found a problem here, the cmd for guest stage 1 invalidation is built, but it is not delivered to smmu. Thank you for the report. I will fix that soon. With that fixed, have you been able to run vSVA on top of the series. Do you need other stuff to be fixed at SMMU level? As I am going to respin soon, please let me know what is the best branch to rebase to alleviate your integration. Best Regards Eric . ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v13 07/15] iommu/smmuv3: Allow stage 1 invalidation with unmanaged ASIDs
Hi Eric On Wed, 18 Nov 2020 12:21:43, Eric Auger wrote: >@@ -1710,7 +1710,11 @@ static void arm_smmu_tlb_inv_context(void *cookie) >* insertion to guarantee those are observed before the TLBI. Do be >* careful, 007. >*/ >- if (smmu_domain->stage == ARM_SMMU_DOMAIN_S1) { >+ if (ext_asid >= 0) { /* guest stage 1 invalidation */ >+ cmd.opcode = CMDQ_OP_TLBI_NH_ASID; >+ cmd.tlbi.asid = ext_asid; >+ cmd.tlbi.vmid = smmu_domain->s2_cfg.vmid; >+ } else if (smmu_domain->stage == ARM_SMMU_DOMAIN_S1) { Found a problem here, the cmd for guest stage 1 invalidation is built, but it is not delivered to smmu. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v13 07/15] iommu/smmuv3: Allow stage 1 invalidation with unmanaged ASIDs
Hi Eric On Wed, 18 Nov 2020 12:21:43, Eric Auger wrote: >@@ -1710,7 +1710,11 @@ static void arm_smmu_tlb_inv_context(void *cookie) > * insertion to guarantee those are observed before the TLBI. Do be > * careful, 007. > */ >- if (smmu_domain->stage == ARM_SMMU_DOMAIN_S1) { >+ if (ext_asid >= 0) { /* guest stage 1 invalidation */ >+ cmd.opcode = CMDQ_OP_TLBI_NH_ASID; >+ cmd.tlbi.asid= ext_asid; >+ cmd.tlbi.vmid = smmu_domain->s2_cfg.vmid; >+ } else if (smmu_domain->stage == ARM_SMMU_DOMAIN_S1) { Found a problem here, the cmd for guest stage 1 invalidation is built, but it is not delivered to smmu. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v13 07/15] iommu/smmuv3: Allow stage 1 invalidation with unmanaged ASIDs
Hi Xingang, On 12/1/20 2:33 PM, Xingang Wang wrote: > Hi Eric > > On Wed, 18 Nov 2020 12:21:43, Eric Auger wrote: >> @@ -1710,7 +1710,11 @@ static void arm_smmu_tlb_inv_context(void *cookie) >> * insertion to guarantee those are observed before the TLBI. Do be >> * careful, 007. >> */ >> -if (smmu_domain->stage == ARM_SMMU_DOMAIN_S1) { >> +if (ext_asid >= 0) { /* guest stage 1 invalidation */ >> +cmd.opcode = CMDQ_OP_TLBI_NH_ASID; >> +cmd.tlbi.asid = ext_asid; >> +cmd.tlbi.vmid = smmu_domain->s2_cfg.vmid; >> +} else if (smmu_domain->stage == ARM_SMMU_DOMAIN_S1) { > > Found a problem here, the cmd for guest stage 1 invalidation is built, > but it is not delivered to smmu. > Thank you for the report. I will fix that soon. With that fixed, have you been able to run vSVA on top of the series. Do you need other stuff to be fixed at SMMU level? As I am going to respin soon, please let me know what is the best branch to rebase to alleviate your integration. Best Regards Eric ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v13 07/15] iommu/smmuv3: Allow stage 1 invalidation with unmanaged ASIDs
With nested stage support, soon we will need to invalidate S1 contexts and ranges tagged with an unmanaged asid, this latter being managed by the guest. So let's introduce 2 helpers that allow to invalidate with externally managed ASIDs Signed-off-by: Eric Auger --- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 35 + 1 file changed, 29 insertions(+), 6 deletions(-) diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c index 805acdc18a3a..fdecc9f17b36 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c @@ -1697,9 +1697,9 @@ static int arm_smmu_atc_inv_domain(struct arm_smmu_domain *smmu_domain, } /* IO_PGTABLE API */ -static void arm_smmu_tlb_inv_context(void *cookie) +static void __arm_smmu_tlb_inv_context(struct arm_smmu_domain *smmu_domain, + int ext_asid) { - struct arm_smmu_domain *smmu_domain = cookie; struct arm_smmu_device *smmu = smmu_domain->smmu; struct arm_smmu_cmdq_ent cmd; @@ -1710,7 +1710,11 @@ static void arm_smmu_tlb_inv_context(void *cookie) * insertion to guarantee those are observed before the TLBI. Do be * careful, 007. */ - if (smmu_domain->stage == ARM_SMMU_DOMAIN_S1) { + if (ext_asid >= 0) { /* guest stage 1 invalidation */ + cmd.opcode = CMDQ_OP_TLBI_NH_ASID; + cmd.tlbi.asid = ext_asid; + cmd.tlbi.vmid = smmu_domain->s2_cfg.vmid; + } else if (smmu_domain->stage == ARM_SMMU_DOMAIN_S1) { arm_smmu_tlb_inv_asid(smmu, smmu_domain->s1_cfg.cd.asid); } else { cmd.opcode = CMDQ_OP_TLBI_S12_VMALL; @@ -1721,9 +1725,17 @@ static void arm_smmu_tlb_inv_context(void *cookie) arm_smmu_atc_inv_domain(smmu_domain, 0, 0, 0); } -static void arm_smmu_tlb_inv_range(unsigned long iova, size_t size, +static void arm_smmu_tlb_inv_context(void *cookie) +{ + struct arm_smmu_domain *smmu_domain = cookie; + + __arm_smmu_tlb_inv_context(smmu_domain, -1); +} + +static void __arm_smmu_tlb_inv_range(unsigned long iova, size_t size, size_t granule, bool leaf, - struct arm_smmu_domain *smmu_domain) + struct arm_smmu_domain *smmu_domain, + int ext_asid) { struct arm_smmu_device *smmu = smmu_domain->smmu; unsigned long start = iova, end = iova + size, num_pages = 0, tg = 0; @@ -1738,7 +1750,11 @@ static void arm_smmu_tlb_inv_range(unsigned long iova, size_t size, if (!size) return; - if (smmu_domain->stage == ARM_SMMU_DOMAIN_S1) { + if (ext_asid >= 0) { /* guest stage 1 invalidation */ + cmd.opcode = CMDQ_OP_TLBI_NH_VA; + cmd.tlbi.asid = ext_asid; + cmd.tlbi.vmid = smmu_domain->s2_cfg.vmid; + } else if (smmu_domain->stage == ARM_SMMU_DOMAIN_S1) { cmd.opcode = CMDQ_OP_TLBI_NH_VA; cmd.tlbi.asid = smmu_domain->s1_cfg.cd.asid; } else { @@ -1798,6 +1814,13 @@ static void arm_smmu_tlb_inv_range(unsigned long iova, size_t size, arm_smmu_atc_inv_domain(smmu_domain, 0, start, size); } +static void arm_smmu_tlb_inv_range(unsigned long iova, size_t size, + size_t granule, bool leaf, + struct arm_smmu_domain *smmu_domain) +{ + __arm_smmu_tlb_inv_range(iova, size, granule, leaf, smmu_domain, -1); +} + static void arm_smmu_tlb_inv_page_nosync(struct iommu_iotlb_gather *gather, unsigned long iova, size_t granule, void *cookie) -- 2.21.3 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu