Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp1057566imm; Tue, 3 Jul 2018 04:56:16 -0700 (PDT) X-Google-Smtp-Source: AAOMgpeoKmU0FVo2XIjjKrnMAjGzhJw7AtQ0Ba/T1cBBw4KyKBiHHP5APGXdjoBSTHUnfKTZEcTm X-Received: by 2002:a62:5984:: with SMTP id k4-v6mr14853300pfj.116.1530618976481; Tue, 03 Jul 2018 04:56:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530618976; cv=none; d=google.com; s=arc-20160816; b=NbzLYejxFhAZmS4RkNJQ+JSIfYPUf4f6irYoemTaPnNPWaNI0BSFUAxcA87R5oPiQg keNBuzboqfxy7DqSJTup+kXUNuLr95famf4KEr06avT77CzeLb2eeQulrtXgASD1kpi6 +LjCcAKK/9iHObOEWkNac2C46WssXNEPR0ufLNNjMuxg9e6W84zZ5U3u/YxVUqCMErUl dxhgyOavDM1/gqtJpaTun3JaVS2Duglqb9+4kLXfYrAzB74B72c6ki/Ldtzf0Y/MMcWl +0CNkmw9Qb0ZrZEBprD+UTWtKUyZmK4k24T2iCixpnrV4CbDQtZxQJc+wAaLVoRBSkQp 64Ow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=VwfxR4GyXN5bfJ+4az2GvLwN+DCCwGLTy2KFe0TNAG0=; b=cWr7wCoKhNzsYFtprSrujS/haT62O84kBWFwJYrwxyxstucwOd3HOWOMvcS7giQvCx MdVlm9yydVJHscPR8s00i7G1WfyNiEZpAyt2Rn1Hms+IwGm3RMkFLVhvLnno47eJgUvr IfZmlRq+BCR042+55roBC5jnVANaewNpL/UZZglfivG+YR3qGzlHAYh4I4NQxMQEBBcK 3J/7qKaULhn2D8J1Dxmbk+0ZkzapEZKWH8KeWYEN0IbEwb/58ITE2OAuM1676elRHwOy 5x1oSbHMEotkuy8DTNqoAfMToxMjrgeegYNCUiDilMUMJbEP9oEuXZYhedJPJi9CCbEN W2ug== 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 r12-v6si863530pgv.285.2018.07.03.04.56.02; Tue, 03 Jul 2018 04:56:16 -0700 (PDT) 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 S1752964AbeGCLyc (ORCPT + 99 others); Tue, 3 Jul 2018 07:54:32 -0400 Received: from foss.arm.com ([217.140.101.70]:48102 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752067AbeGCLya (ORCPT ); Tue, 3 Jul 2018 07:54:30 -0400 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 7353C80D; Tue, 3 Jul 2018 04:54:30 -0700 (PDT) Received: from [10.1.206.73] (en101.cambridge.arm.com [10.1.206.73]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 46F083F5BA; Tue, 3 Jul 2018 04:54:28 -0700 (PDT) Subject: Re: [PATCH v3 10/20] kvm: arm64: Dynamic configuration of VTTBR mask To: Auger Eric , linux-arm-kernel@lists.infradead.org Cc: cdall@kernel.org, kvm@vger.kernel.org, marc.zyngier@arm.com, catalin.marinas@arm.com, punit.agrawal@arm.com, will.deacon@arm.com, linux-kernel@vger.kernel.org, qemu-devel@nongnu.org, julien.grall@arm.com, james.morse@arm.com, kvmarm@lists.cs.columbia.edu References: <1530270944-11351-1-git-send-email-suzuki.poulose@arm.com> <1530270944-11351-11-git-send-email-suzuki.poulose@arm.com> From: Suzuki K Poulose Message-ID: Date: Tue, 3 Jul 2018 12:54:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Eric, On 02/07/18 15:41, Auger Eric wrote: > Hi Suzuki, > > On 06/29/2018 01:15 PM, Suzuki K Poulose wrote: >> On arm64 VTTBR_EL2:BADDR holds the base address for the stage2 >> translation table. The Arm ARM mandates that the bits BADDR[x-1:0] >> should be 0, where 'x' is defined for a given IPA Size and the >> number of levels for a translation granule size. It is defined >> using some magical constants. This patch is a reverse engineered >> implementation to calculate the 'x' at runtime for a given ipa and >> number of page table levels. See patch for more details. >> >> Cc: Marc Zyngier >> Cc: Christoffer Dall >> Signed-off-by: Suzuki K Poulose >> --- >> Changes since V2: >> - Part 1 of spilt from VTCR & VTTBR dynamic configuration >> --- >> arch/arm64/include/asm/kvm_arm.h | 60 +++++++++++++++++++++++++++++++++++++--- >> arch/arm64/include/asm/kvm_mmu.h | 25 ++++++++++++++++- >> 2 files changed, 80 insertions(+), 5 deletions(-) >> >> diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h >> index 3dffd38..c557f45 100644 >> --- a/arch/arm64/include/asm/kvm_arm.h >> +++ b/arch/arm64/include/asm/kvm_arm.h >> @@ -140,8 +140,6 @@ >> * Note that when using 4K pages, we concatenate two first level page tables >> * together. With 16K pages, we concatenate 16 first level page tables. >> * >> - * The magic numbers used for VTTBR_X in this patch can be found in Tables >> - * D4-23 and D4-25 in ARM DDI 0487A.b. > Isn't it a pretty old reference? Could you refer to C.a? Sure, I will update the references everywhere. >> + * >> + * The algorithm defines the expectations on the BaseAddress (for the page >> + * table) bits resolved at each level based on the page size, entry level >> + * and T0SZ. The variable "x" in the algorithm also affects the VTTBR:BADDR >> + * for stage2 page table. >> + * >> + * The value of "x" is calculated as : >> + * x = Magic_N - T0SZ >> + * >> + * where Magic_N is an integer depending on the page size and the entry >> + * level of the page table as below: >> + * >> + * -------------------------------------------- >> + * | Entry level | 4K 16K 64K | >> + * -------------------------------------------- >> + * | Level: 0 (4 levels) | 28 | - | - | >> + * -------------------------------------------- >> + * | Level: 1 (3 levels) | 37 | 31 | 25 | >> + * -------------------------------------------- >> + * | Level: 2 (2 levels) | 46 | 42 | 38 | >> + * -------------------------------------------- >> + * | Level: 3 (1 level) | - | 53 | 51 | >> + * -------------------------------------------- > I understand entry level = Lookup level in the table. Entry level => The level at which we start the page table walk for a given address (This is in line with the ARM ARM). So, Entry_level = (4 - Number_of_Page_table_levels) > But you may want to compute x for BaseAddress matching lookup level 2 > with number of levels = 4. No, the BaseAddress is only calcualted for the "Entry_level". So the above case doesn't exist at all. > So shouldn't you s/Number of levels/4 - entry_level? Ok, I now understood what you are referring to [0] > for BADDR we want the BaseAddr of the initial lookup level so > effectively the entry level we are interested in is 4 - number of levels > and we don't care or d) condition. At least this is my understanding ;-) > If correct you may slightly reword the explanation? >> + * >> + * We have a magic formula for the Magic_N below. >> + * >> + * Magic_N(PAGE_SIZE, Entry_Level) = 64 - ((PAGE_SHIFT - 3) * Number of levels) [0] ^^^ >> + * >> + * where number of levels = (4 - Entry_Level). ^^^ Doesn't this help make it clear ? Using the expansion makes it a bit more unreadable below. >> >> +/* >> + * Get the magic number 'x' for VTTBR:BADDR of this KVM instance. >> + * With v8.2 LVA extensions, 'x' should be a minimum of 6 with >> + * 52bit IPS. > Link to the spec? Sure, will add it. Thanks for the patience to review :-) Cheers Suzuki