Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp1168691pxf; Fri, 9 Apr 2021 01:33:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwCX+eVjSKeI72ixRxEyfdyXXS8g6V+dcknYO2V++6cKNqvsGWqs9MrwTOanAJyO2+wLnT9 X-Received: by 2002:a17:906:3c07:: with SMTP id h7mr15215233ejg.446.1617957201085; Fri, 09 Apr 2021 01:33:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617957201; cv=none; d=google.com; s=arc-20160816; b=bj/jbPKEBgxLKFSI1MlD+0JzzlglDZvlBozAJs8+Q1sQiE4r1skoR6r4NkqiSZBijz BIezOhW5BaKaQNYc32s6Yaiz2SbvvsPJ/fmUaht+1yr4VPyyT3J4heCC80oazPuFi9CA 9NsAjuIL0y3jKySodtb26O+p5zGnnTc2ZPRTFezevv/9F3jbWfZkyGWZ94u8iXNwe6eD W4SCAQi5lAqBQlqZxzrDRB8z8I+XKLcOeexB9jD0CywNZRqRbIPCfCUajuGr4hMR5l9W nUeBX61/LIuc5b7L7XVi9BG2whJolDFbW48MEBLdvGj5r013RV7DcgVe7BzQyG7GeVEs 0L5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=ckiaDadLI3Q36uJmnyF8zVs1VJKNRCw3jjdFa+zQU9E=; b=stsTCBgqqmhFusGXhQ5MTRX9WXIhiuv5IQmkoXjx98HtTpHP9Azhrzw3bTqeLyHwAZ 3sU9qda7dbivBZj20VJyIdxqtfWXH9aoFES+3vSvz4g0lFrucAdGbOqOWGzrV1RNvscU El7S4J/lS3vhnI579GK891W95isClc+htuY1WsQ6UgEnfmWUvi2gLrLAaXa5dnX5UAV3 y7ndSIycUsyrL5GKiGAe6+2feLPMMMRJjg41nYZDVaHMmKqz+NGgxQd4uzFuu8Se2xm6 DXSIZlA+63HmnA9+VJK/7NTAyKQzIl4QbmI4nBVKhr3M/HaDzAl+MVQHwjTNzUj9H4UV cWbg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="TctAKeQ/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d16si1697950edx.500.2021.04.09.01.32.57; Fri, 09 Apr 2021 01:33:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="TctAKeQ/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231920AbhDIIbt (ORCPT + 99 others); Fri, 9 Apr 2021 04:31:49 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:54936 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229696AbhDIIbq (ORCPT ); Fri, 9 Apr 2021 04:31:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1617957093; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ckiaDadLI3Q36uJmnyF8zVs1VJKNRCw3jjdFa+zQU9E=; b=TctAKeQ/t0+lsb8rkozNL6dUeCzb9O7mtohz6Bs4NpEvi6F18vBNEYnLmRNmU/2BSHdzhp FRMSbNItKVMTHGZjqDUirgIqy0+cwGew96bmcYB0evf/UMMwLaO/h5NuCBN+9ojgcBhB0y W+P0pmkpMnVaLI3cWu2fclf9fqLjx7c= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-130-ygGqiEGgNb-IGtXqc6wpjA-1; Fri, 09 Apr 2021 04:31:26 -0400 X-MC-Unique: ygGqiEGgNb-IGtXqc6wpjA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 8A3DB8189EE; Fri, 9 Apr 2021 08:31:23 +0000 (UTC) Received: from [10.36.114.73] (ovpn-114-73.ams2.redhat.com [10.36.114.73]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0C8C019C71; Fri, 9 Apr 2021 08:31:11 +0000 (UTC) Subject: Re: [PATCH v14 06/13] iommu/smmuv3: Allow stage 1 invalidation with unmanaged ASIDs To: Kunkun Jiang , eric.auger.pro@gmail.com, iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, will@kernel.org, maz@kernel.org, robin.murphy@arm.com, joro@8bytes.org, alex.williamson@redhat.com, tn@semihalf.com, zhukeqian1@huawei.com Cc: jacob.jun.pan@linux.intel.com, yi.l.liu@intel.com, wangxingang5@huawei.com, jean-philippe@linaro.org, zhangfei.gao@linaro.org, zhangfei.gao@gmail.com, vivek.gautam@arm.com, shameerali.kolothum.thodi@huawei.com, yuzenghui@huawei.com, nicoleotsuka@gmail.com, lushenming@huawei.com, vsethi@nvidia.com, wanghaibin.wang@huawei.com References: <20210223205634.604221-1-eric.auger@redhat.com> <20210223205634.604221-7-eric.auger@redhat.com> <901720e6-6ca5-eb9a-1f24-0ca479bcfecc@huawei.com> <0246aec2-162d-0584-3ca4-b9c304ef3c8a@redhat.com> <46f3760a-9ab5-1710-598e-38fbc1f5fb5c@huawei.com> From: Auger Eric Message-ID: <2baf96db-d7fe-e341-1b40-fab2b4c9fd92@redhat.com> Date: Fri, 9 Apr 2021 10:31:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: <46f3760a-9ab5-1710-598e-38fbc1f5fb5c@huawei.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Kunkun, On 4/9/21 6:48 AM, Kunkun Jiang wrote: > Hi Eric, > > On 2021/4/8 20:30, Auger Eric wrote: >> Hi Kunkun, >> >> On 4/1/21 2:37 PM, Kunkun Jiang wrote: >>> Hi Eric, >>> >>> On 2021/2/24 4:56, Eric Auger wrote: >>>> 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 >>>> >>>> --- >>>> >>>> v13 -> v14 >>>> - Actually send the NH_ASID command (reported by Xingang Wang) >>>> --- >>>>    drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 38 >>>> ++++++++++++++++----- >>>>    1 file changed, 29 insertions(+), 9 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 5579ec4fccc8..4c19a1114de4 100644 >>>> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c >>>> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c >>>> @@ -1843,9 +1843,9 @@ int arm_smmu_atc_inv_domain(struct >>>> arm_smmu_domain *smmu_domain, int ssid, >>>>    } >>>>      /* 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; >>>>    @@ -1856,7 +1856,13 @@ 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; >>>> +        arm_smmu_cmdq_issue_cmd(smmu, &cmd); >>>> +        arm_smmu_cmdq_issue_sync(smmu); >>>> +    } 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; >>>> @@ -1867,6 +1873,13 @@ 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_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(struct arm_smmu_cmdq_ent *cmd, >>>>                         unsigned long iova, size_t size, >>>>                         size_t granule, >>>> @@ -1926,9 +1939,10 @@ static void __arm_smmu_tlb_inv_range(struct >>>> arm_smmu_cmdq_ent *cmd, >>>>        arm_smmu_cmdq_batch_submit(smmu, &cmds); >>>>    } >>>>    >>> Here is the part of code in __arm_smmu_tlb_inv_range(): >>>>          if (smmu->features & ARM_SMMU_FEAT_RANGE_INV) { >>>>                  /* Get the leaf page size */ >>>>                  tg = __ffs(smmu_domain->domain.pgsize_bitmap); >>>> >>>>                  /* Convert page size of 12,14,16 (log2) to 1,2,3 */ >>>>                  cmd->tlbi.tg = (tg - 10) / 2; >>>> >>>>                  /* Determine what level the granule is at */ >>>>                  cmd->tlbi.ttl = 4 - ((ilog2(granule) - 3) / (tg - 3)); >>>> >>>>                  num_pages = size >> tg; >>>>          } >>> When pSMMU supports RIL, we get the leaf page size by >>> __ffs(smmu_domain-> >>> domain.pgsize_bitmap). In nested mode, it is determined by host >>> PAGE_SIZE. If >>> the host kernel and guest kernel has different translation granule (e.g. >>> host 16K, >>> guest 4K), __arm_smmu_tlb_inv_range() will issue an incorrect tlbi >>> command. >>> >>> Do you have any idea about this issue? >> I think this is the same issue as the one reported by Chenxiang >> >> https://lore.kernel.org/lkml/15938ed5-2095-e903-a290-333c299015a2@hisilicon.com/ >> >> >> In case RIL is not supported by the host, next version will use the >> smallest pSMMU supported page size, as done in __arm_smmu_tlb_inv_range >> >> Thanks >> >> Eric > I think they are different. In normal cases, when we want to invalidate the > cache of stage 1, we should use the granule size supported by vSMMU to > implement and issue an tlbi command if pSMMU supports RIL. > > But in the current __arm_smmu_tlb_inv_range(), it always uses the granule > size supported by host. > (tg = __ffs(smmu_domain->domain.pgsize_bitmap);) > > Let me explain more clearly. > Preconditions of this issue: > 1. pSMMU supports RIL > 2. host and guest use different translation granule (e.g. host 16K, > guest 4K) this is not clear to me. See below. > > Guest wants to invalidate 4K, so info->granule_size = 4K. > In __arm_smmu_tlb_inv_range(),   if pSMMU supports RIL and host 16K, > tg = 14, tlbi.tg = 2, tlbi.ttl = 4, tlbi.scale = 0, tlbi.num = -1. It is > an incorrect > tlbi command. If the guest uses 4K granule, this means the pSMMU also supports 4K granule. Otherwise the corresponding CD is invalid (TG0/TG1 field desc). So in that case isn't it valid to send a RIL invalidation with tg = 12, right? Making sure the guest uses a valid pSMMU supported granule is the QEMU job I think, this should be done at the init phase before hitting CD invalid errors for sure. Thanks Eric > > So it would be better to pass the leaf page size supported by vSMMU to > host.  Perhaps this issue and the one reported by Chenxiang can be solved > together. > > Thanks, > Kunkun Jiang >>> Best Regards, >>> Kunkun Jiang >>>> -static void arm_smmu_tlb_inv_range_domain(unsigned long iova, size_t >>>> size, >>>> -                      size_t granule, bool leaf, >>>> -                      struct arm_smmu_domain *smmu_domain) >>>> +static void >>>> +arm_smmu_tlb_inv_range_domain(unsigned long iova, size_t size, >>>> +                  size_t granule, bool leaf, int ext_asid, >>>> +                  struct arm_smmu_domain *smmu_domain) >>>>    { >>>>        struct arm_smmu_cmdq_ent cmd = { >>>>            .tlbi = { >>>> @@ -1936,7 +1950,12 @@ static void >>>> arm_smmu_tlb_inv_range_domain(unsigned long iova, size_t size, >>>>            }, >>>>        }; >>>>    -    if (smmu_domain->stage == ARM_SMMU_DOMAIN_S1) { >>>> +    if (ext_asid >= 0) {  /* guest stage 1 invalidation */ >>>> +        cmd.opcode    = smmu_domain->smmu->features & >>>> ARM_SMMU_FEAT_E2H ? >>>> +                  CMDQ_OP_TLBI_EL2_VA : 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    = smmu_domain->smmu->features & >>>> ARM_SMMU_FEAT_E2H ? >>>>                      CMDQ_OP_TLBI_EL2_VA : CMDQ_OP_TLBI_NH_VA; >>>>            cmd.tlbi.asid    = smmu_domain->s1_cfg.cd.asid; >>>> @@ -1944,6 +1963,7 @@ static void >>>> arm_smmu_tlb_inv_range_domain(unsigned long iova, size_t size, >>>>            cmd.opcode    = CMDQ_OP_TLBI_S2_IPA; >>>>            cmd.tlbi.vmid    = smmu_domain->s2_cfg.vmid; >>>>        } >>>> + >>>>        __arm_smmu_tlb_inv_range(&cmd, iova, size, granule, >>>> smmu_domain); >>>>          /* >>>> @@ -1982,7 +2002,7 @@ static void arm_smmu_tlb_inv_page_nosync(struct >>>> iommu_iotlb_gather *gather, >>>>    static void arm_smmu_tlb_inv_walk(unsigned long iova, size_t size, >>>>                      size_t granule, void *cookie) >>>>    { >>>> -    arm_smmu_tlb_inv_range_domain(iova, size, granule, false, cookie); >>>> +    arm_smmu_tlb_inv_range_domain(iova, size, granule, false, -1, >>>> cookie); >>>>    } >>>>      static const struct iommu_flush_ops arm_smmu_flush_ops = { >>>> @@ -2523,7 +2543,7 @@ static void arm_smmu_iotlb_sync(struct >>>> iommu_domain *domain, >>>>          arm_smmu_tlb_inv_range_domain(gather->start, >>>>                          gather->end - gather->start + 1, >>>> -                      gather->pgsize, true, smmu_domain); >>>> +                      gather->pgsize, true, -1, smmu_domain); >>>>    } >>>>      static phys_addr_t >>> >> . > >