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 <[email protected]>
---
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
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.
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
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
>
> .
>
Hi Eric,
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Auger Eric
> Sent: 01 December 2020 13:59
> To: wangxingang <[email protected]>
> Cc: Xieyingtai <[email protected]>; [email protected];
> [email protected]; [email protected]; [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; [email protected]
> 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
> [email protected]
> https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Hi Shameer,
On Thu, Dec 03, 2020 at 06:42:57PM +0000, 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
Hi Jean,
> -----Original Message-----
> From: Jean-Philippe Brucker [mailto:[email protected]]
> Sent: 04 December 2020 09:54
> To: Shameerali Kolothum Thodi <[email protected]>
> Cc: Auger Eric <[email protected]>; wangxingang
> <[email protected]>; Xieyingtai <[email protected]>;
> [email protected]; [email protected]; [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; [email protected]; Zengtao (B)
> <[email protected]>; qubingbing <[email protected]>
> 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 +0000, 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.
Thanks,
Shameer
> Thanks,
> Jean
Hi Shameer, Jean-Philippe,
On 12/4/20 11:20 AM, Shameerali Kolothum Thodi wrote:
> Hi Jean,
>
>> -----Original Message-----
>> From: Jean-Philippe Brucker [mailto:[email protected]]
>> Sent: 04 December 2020 09:54
>> To: Shameerali Kolothum Thodi <[email protected]>
>> Cc: Auger Eric <[email protected]>; wangxingang
>> <[email protected]>; Xieyingtai <[email protected]>;
>> [email protected]; [email protected]; [email protected]; [email protected];
>> [email protected]; [email protected];
>> [email protected]; [email protected];
>> [email protected]; [email protected];
>> [email protected]; [email protected]; Zengtao (B)
>> <[email protected]>; qubingbing <[email protected]>
>> 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 +0000, 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
>
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:[email protected]]
>>> Sent: 04 December 2020 09:54
>>> To: Shameerali Kolothum Thodi <[email protected]>
>>> Cc: Auger Eric <[email protected]>; wangxingang
>>> <[email protected]>; Xieyingtai <[email protected]>;
>>> [email protected]; [email protected]; [email protected]; [email protected];
>>> [email protected]; [email protected];
>>> [email protected]; [email protected];
>>> [email protected]; [email protected];
>>> [email protected]; [email protected]; Zengtao (B)
>>> <[email protected]>; qubingbing <[email protected]>
>>> 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 +0000, 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
> [email protected]
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
>
Hi Eric,
> -----Original Message-----
> From: Auger Eric [mailto:[email protected]]
> Sent: 14 January 2021 16:58
> To: Shameerali Kolothum Thodi <[email protected]>;
> Jean-Philippe Brucker <[email protected]>
> Cc: Xieyingtai <[email protected]>; [email protected];
> wangxingang <[email protected]>; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; qubingbing <[email protected]>;
> Zengtao (B) <[email protected]>; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]
> 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:[email protected]]
> >>> Sent: 04 December 2020 09:54
> >>> To: Shameerali Kolothum Thodi
> <[email protected]>
> >>> Cc: Auger Eric <[email protected]>; wangxingang
> >>> <[email protected]>; Xieyingtai <[email protected]>;
> >>> [email protected]; [email protected]; [email protected];
> [email protected];
> >>> [email protected]; [email protected];
> >>> [email protected]; [email protected];
> >>> [email protected]; [email protected];
> >>> [email protected]; [email protected]; Zengtao (B)
> >>> <[email protected]>; qubingbing <[email protected]>
> >>> 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 +0000, 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
> > [email protected]
> > https://lists.linuxfoundation.org/mailman/listinfo/iommu
> >
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
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
>
Hi Shameer,
On 12/3/20 7:42 PM, Shameerali Kolothum Thodi wrote:
> Hi Eric,
>
>> -----Original Message-----
>> From: [email protected]
>> [mailto:[email protected]] On Behalf Of Auger Eric
>> Sent: 01 December 2020 13:59
>> To: wangxingang <[email protected]>
>> Cc: Xieyingtai <[email protected]>; [email protected];
>> [email protected]; [email protected]; [email protected]; [email protected];
>> [email protected]; [email protected];
>> [email protected]; [email protected];
>> [email protected]; [email protected];
>> [email protected]; [email protected]
>> 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
>> [email protected]
>> https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
>