From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6839FEB64DD for ; Thu, 13 Jul 2023 08:40:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234166AbjGMIkb (ORCPT ); Thu, 13 Jul 2023 04:40:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46270 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232830AbjGMIkM (ORCPT ); Thu, 13 Jul 2023 04:40:12 -0400 Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2BD4844A1 for ; Thu, 13 Jul 2023 01:35:33 -0700 (PDT) Received: by mail-qt1-x835.google.com with SMTP id d75a77b69052e-40371070eb7so177821cf.1 for ; Thu, 13 Jul 2023 01:35:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1689237332; x=1691829332; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=CUiEY1fSBTwYVk97ONcADqRi9c3ar1khFfmJ+HnVmuI=; b=gyanBDz/w9wX5l7O7NXT48CRH/6WxciJmda5d9B2FPcbw0+Gq46F1tkWLT74J78W/X mVGSg1kDkkO4CaFX1TK16spI+QMaC/5ySbVBT/E46wzmRpLFQPAEmyblcP5hEZxqaPbJ /6aqM6jyOSVYK/J9EDxvU3NQFqRWjiyXnqL5gF6Mn59jAuO5M2o/L5oDi3f2DnNmQMVZ 7aFhnT7eeLSbohY7HpBsfSR+1L+/QZ5Tn+Ap2hDLgYTBz6wKpbu0XeAonfxXt4Pk5UHo jUnEwrpN3PRA9rCxxZq1vo7nAfaECJBfSrti5GFE8rWa76KI2+hjdfuBzV0xeJpHQRry BzsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689237332; x=1691829332; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=CUiEY1fSBTwYVk97ONcADqRi9c3ar1khFfmJ+HnVmuI=; b=AZYgj8VyfHgEMQWWc6jEnQO6ZR+ab14qmInBbVIgPqVGGBS6NXybPAFsm/j/VL3a7j zoVIuIee71LhgQis9/eKwXx2o+TnjJwcYFfTh8mtHSC40YChevzQnqmJ2zAseR2bM1sO DQfj5CubbZlO4LWMtYLFd3/kwKmwxYULzYSj53Te455W5w5w56Kn5vKioyGV/99bQpNU Cpcgc0JPRuRI/cLg2/dQg6qEkKjntBo6uHrbnrnaFmO9Sosl7V2B8I7oQBGuXgf2fllD h6G00ZnVVnw82Nv+t2lU9Wmem6iUzVYmwqWfs0p+GqImbNmqMcFLk1vfQ8Xonct0iyD7 RmYQ== X-Gm-Message-State: ABy/qLaBMbeBdExfS8RV/gEW81tZdrsf0UuBO7Il/aR2u1Gnku8kBrHw eajcYa/NfFyt6x3xi4Hyp7XCZD6xMvrJs0bbKMze2g== X-Google-Smtp-Source: APBJJlE8ZmsIj2Hzla7BztX6LrHSwBFzu2OcKKW8iqQh5D4S5j3zr68JLR331RxxDu7qRE6yXsUYFC+y34hqT56X5Qk= X-Received: by 2002:a05:622a:245:b0:3fa:3c8f:3435 with SMTP id c5-20020a05622a024500b003fa3c8f3435mr435860qtx.27.1689237332162; Thu, 13 Jul 2023 01:35:32 -0700 (PDT) MIME-Version: 1.0 References: <20230621063825.268890-1-mshavit@google.com> <20230621063825.268890-3-mshavit@google.com> In-Reply-To: From: Michael Shavit Date: Thu, 13 Jul 2023 16:34:56 +0800 Message-ID: Subject: Re: [PATCH v4 02/13] iommu/arm-smmu-v3: Add smmu_s1_cfg to smmu_master To: Nicolin Chen Cc: Will Deacon , Robin Murphy , Joerg Roedel , jean-philippe@linaro.org, jgg@nvidia.com, baolu.lu@linux.intel.com, linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 13, 2023 at 9:22=E2=80=AFAM Nicolin Chen = wrote: > > > Except for Nested domains, arm_smmu_master will own the STEs that are > > inserted into the arm_smmu_device's STE table. > > I think that the master still owns an STE when attached to a > nested domain. Though an IOMMU_DOMAIN_NESTED iommu_domain is > an opaque object to the STE in the guest, the host still has > a real STE for the nested configuration somewhere -- and it's > likely still to be owned by the master that's attached to the > opaque NESTED iommu_domain in the host kernel. > I am a bit confused by this naming. If only master would own > an s1_cfg, perhaps we can just make it "s1_cfg" and drop the > s1_cfg pointer in the next patch. Could be that the naming is causing some confusion. This owned_s1_cfg is very different from the s1_cfg set-up by Nested domains in your patch series. It's better to think of it as the default s1_cfg used for DMA/SVA/UNMANAGED domains. Because stage 1 domains represent a single page table, it doesn't make sense for them to own an entire CD table. In contrast, nested domains map an entire CD table and it therefore makes sense for them to own the s1_cfg representing that table. Would renaming this as default_s1_cfg make more sense?