Received: by 10.223.176.5 with SMTP id f5csp1782229wra; Thu, 8 Feb 2018 03:26:31 -0800 (PST) X-Google-Smtp-Source: AH8x224/F8ZiuIncD1HM5/i3U11iPOAvIsjQago+pUbH8e98H6wXlV3tsm+kkP/hd3QOsnwZ7e7Q X-Received: by 10.99.124.2 with SMTP id x2mr289103pgc.184.1518089190840; Thu, 08 Feb 2018 03:26:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518089190; cv=none; d=google.com; s=arc-20160816; b=OioFR84dsj5+Zl0PfDEqoSMveIPY0NWwzvjPA6Cye42XxF4UOZZtGfGIEKiQnU2a4r rlGQGm/9UWMk94t6lMy2pQMdxJMipPxK6Wk3KeuGTE3NNlLUtAJf/qj9IMoR/5Dstb83 fJfpt2Zh3gW5ZqIc/dX0ODio1Y/qtfb/xn52PlfZOHgoiImM+wiaOHclpkLhdxRCWmzr tLG3010dpOms1jVWtrSNFaLLXGq0IjK686uz/iEnMboA5N4gG10yoYbHP9+TxpvOkU5S vzEbl5q4cMdkKsq12Hbv0s8tJgY5+LEThbHe4WqDBOt3SpvHnyJbYp47gevbHDgBt+vG wdGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=5A9Fqbkt1Y4ih7tgCspgGmQLWtb9m7wAuPwXoCrXQq0=; b=JPH/9s6EGiYUFPr+UaCIVCNQ4hqeG/jsYoNow2qLhZxbsvAhjk/dxn037cesks9CuH eLeCCtZtID0HSdGCFcejX2/FXeZ9vyjIGgwFbFerQYqorCaUBFxg9u8ObZD1dRQtfjjE DSoyOmmih2Lfi9BJ+MSNV2UoMRJ4rJ5r6s3HOADMoN+Ut1iXyjtKEo4KmY40v4jCHpWW qd/Mjkvs+f+8z7EAa+9V0Y8vLQ0kjkZqgMT0rB737yKDAsiXfYTVE9sieNscVPSyiyju +oSwHyuB5/93DbiIibiI5TDv5XD7h2MWecRd4L9orowAiYJCk9DH6rvB+L1+8S0FNxsH jTzA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y9si11462pge.265.2018.02.08.03.26.16; Thu, 08 Feb 2018 03:26:30 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752191AbeBHLZi (ORCPT + 99 others); Thu, 8 Feb 2018 06:25:38 -0500 Received: from foss.arm.com ([217.140.101.70]:33350 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751066AbeBHLZh (ORCPT ); Thu, 8 Feb 2018 06:25:37 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id DBEAC80D; Thu, 8 Feb 2018 03:25:36 -0800 (PST) Received: from edgewater-inn.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id AA1A53F24D; Thu, 8 Feb 2018 03:25:36 -0800 (PST) Received: by edgewater-inn.cambridge.arm.com (Postfix, from userid 1000) id 602661AE334A; Thu, 8 Feb 2018 11:25:41 +0000 (GMT) Date: Thu, 8 Feb 2018 11:25:41 +0000 From: Will Deacon To: Christoffer Dall Cc: Suzuki K Poulose , linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, marc.zyngier@arm.com, linux-kernel@vger.kernel.org, kristina.martsenko@arm.com, peter.maydell@linaro.org, pbonzini@redhat.com, rkrcmar@redhat.com, ard.biesheuvel@linaro.org, mark.rutland@arm.com, catalin.marinas@arm.com Subject: Re: [PATCH 00/16] kvm: arm64: Support for dynamic IPA size Message-ID: <20180208112540.GA17775@arm.com> References: <20180109190414.4017-1-suzuki.poulose@arm.com> <20180208111844.GN29286@cbox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180208111844.GN29286@cbox> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org I can comment on one part here: On Thu, Feb 08, 2018 at 12:18:44PM +0100, Christoffer Dall wrote: > Wasn't this also the decision taken for IOMMU page table allocation, and > why was that the right approach for the IOMMU but not for KVM stage 2 > page tables? Is there room for reuse of the IOMMU page table allocation > logic in KVM as well? There were a few reasons we did this for IOMMU page tables: * Ability to use different page size/VA bits/levels from the CPU * Ability to support different page table formats (e.g. short descriptor) * Ability to determine page table attributes at runtime * Requirement to map/unmap in atomic context * Ability to cope with non-coherent page table walkers * Ability to create both stage-1 and stage-2 mappings * Easier to hook in our own TLB invalidation routines * Support for lockless concurrent map/unmap within confines of the DMA API usage Will