Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp642173pxf; Thu, 18 Mar 2021 08:30:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz315cK0LFr6kiljO6k2PCJNSFcu3BW0Lo6fRp2dmAOsh7pRDaDINTfC+0eW1NBESrjRU84 X-Received: by 2002:a17:906:b316:: with SMTP id n22mr40317325ejz.249.1616081428850; Thu, 18 Mar 2021 08:30:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616081428; cv=none; d=google.com; s=arc-20160816; b=wGDDUOPtgyBMqG6s8MylWJY1XMdzBlN/Nu6R5cif1bkabinPBzOxQbD6OMfE8f4lvu 8Pys98OrO++Eb70RV6W3VgviINvrjaBAN/fF6zo1F3a36dRFZIUKjBm6l5JdTF6LGBWJ i2Hr5T8l8b0WqPXhDSwdKDxCjZKARNAvW4HFDbISVP793Hk8JBW40++GbTQhDFD7wDsA SQ3tcIp9LhGLu3EDG7G6b92TkwZm+yZ7xS0pekcllN8gQwAjaFKML3dCGyg7tv9iT1V0 pRpQIiwDCgLjWJlK6ff8x7obg+ZdwJ7bHnwhZKhc0G1YkxT6euHx/xbaCMzuCQ20LamD 53cA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=rK2GPPEgc63bxqQ3vD6pHAZpeeEL/LOYymEcLnZqsp4=; b=HoTGzr88CrZH0K+gZag3QxEPsHt30ddKTrPtZbPMAZ1Yft6TopgFtF/LuteW6xFQNJ 06QVgZ/dY2/uqngYZmIPZzz9xY+sxT9eEv07tArirY1p2drUOp3JDH5ocdoC7853rIVz Gt0yf6MNy3iwVTD/K8futQZrNBJQ6r82Cx4amEy2wTuMu6XmNLtrOHD+nE3I1Ro9sPti uGL4N9YAE/b28PFDVcjXLUZ/EhY6TdEbddbVi+j5OrkGGMYs+UmWAgXE50aWaBNkXQ1t XeGHVfgdIUQXtV6SLyxbq7+/UrWrwgvmNR5gi+WeD7TK1A0X6n3eXRlaBaQ5B2ozLNkq 5GOg== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=8bytes.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j5si1871516edy.408.2021.03.18.08.30.06; Thu, 18 Mar 2021 08:30:28 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=8bytes.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232051AbhCRP2S (ORCPT + 99 others); Thu, 18 Mar 2021 11:28:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39096 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230374AbhCRP2P (ORCPT ); Thu, 18 Mar 2021 11:28:15 -0400 Received: from theia.8bytes.org (8bytes.org [IPv6:2a01:238:4383:600:38bc:a715:4b6d:a889]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 09EFDC06174A for ; Thu, 18 Mar 2021 08:28:15 -0700 (PDT) Received: by theia.8bytes.org (Postfix, from userid 1000) id 52FFE2DA; Thu, 18 Mar 2021 16:28:12 +0100 (CET) Date: Thu, 18 Mar 2021 16:28:10 +0100 From: Joerg Roedel To: Suravee Suthikulpanit Cc: linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, Jon.Grimm@amd.com, Wei.Huang2@amd.com Subject: Re: [RFC PATCH 4/7] iommu/amd: Initial support for AMD IOMMU v2 page table Message-ID: References: <20210312090411.6030-1-suravee.suthikulpanit@amd.com> <20210312090411.6030-5-suravee.suthikulpanit@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210312090411.6030-5-suravee.suthikulpanit@amd.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Suravee, On Fri, Mar 12, 2021 at 03:04:08AM -0600, Suravee Suthikulpanit wrote: > @@ -503,6 +504,7 @@ struct amd_io_pgtable { > int mode; > u64 *root; > atomic64_t pt_root; /* pgtable root and pgtable mode */ > + struct mm_struct v2_mm; > }; A whole mm_struct is a bit too much when all we really need is an 8-byte page-table root pointer. > +static pte_t *fetch_pte(struct amd_io_pgtable *pgtable, > + unsigned long iova, > + unsigned long *page_size) > +{ > + int level; > + pte_t *ptep; > + > + ptep = lookup_address_in_mm(&pgtable->v2_mm, iova, &level); > + if (!ptep || pte_none(*ptep) || (level == PG_LEVEL_NONE)) > + return NULL; So you are re-using the in-kernel page-table building code. That safes some lines of code, but has several problems: 1) When you boot a kernel with this code on a machine with 5-level paging, the IOMMU code will build a 5-level page-table too, breaking IOMMU mappings. 2) You need a whole mm_struct per domain, which is big. 3) The existing macros for CPU page-tables require locking. For IOMMU page-tables this is not really necessary and might cause scalability issues. Overall I think you should write your own code to build a 4-level page-table and use cmpxchg64 to avoid the need for locking. Then things will not break when such a kernel is suddenly booted on a machine which as 5-level paging enabled. Regards, Joerg