Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp534209imm; Wed, 19 Sep 2018 03:02:38 -0700 (PDT) X-Google-Smtp-Source: ANB0Vda3dBX5GSu2CH5V9EWbIc/RkW5C1wNer7KlKhWwdQyTlTd48xTYpFYuRS45X47MQxF3zwMd X-Received: by 2002:a65:4b88:: with SMTP id t8-v6mr31940730pgq.239.1537351358873; Wed, 19 Sep 2018 03:02:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537351358; cv=none; d=google.com; s=arc-20160816; b=B0l/j5WjAMI+kQQpyxQNQJclqvIM29Uyj8Ypzbn1v/9AlPSMBBJ0cBfhavFesRURFL ukMdWkO0dAJlqgO1u8+5dEU/A2tWgglnucrBlLhl07q+/T2tCOGsBI1XjsyntQLrT2Yt EaIGe39FmQEM79XBqddv5eSWagAJQPXNsXYt6Ztc/LVJ3bVUVyicp9bn5Cr0CJm+bBgL WrF71lJAs63D2eKi+0v9OS7Kyc9RXXQs+PqCiIXOf4sbqfZpeADny4QH7URJUBqjrOnZ ep4bD9izN67jZDYr6l7eGWTfqzUjHGrS/2uSxuttCvwV6ts3OqUf+XSsXPvpJvcQC4dk wqTQ== 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; bh=ZUYS63Uxt4b2uX8xw+YJMg3bvyEELcDTzLL/3dkq+Jk=; b=R4ab+XsZIecYTHM8tOF3OFsnu0CSb9ex3mG34xRlfCFIzO4XvuxlLWr7mjlPmq4I4G HjR/AvdlFSdM6z6dkhfBbBIMvC+xn3OylK9mMYLzP8kANkveJ1tWiOY1WlOUkbFuSQya 24cDUBYw9jtbW6bOawE7m4QvutmfFWWri/ioKMs2m2T5LFgf5Fyfn4XiOR+c3kvllP/e y2uJY/EqLfuzT9KkI4q+kQfGEuUFKRExZAjZxznk975eY9+thBGW+wQbSsHxxKGzBbZz oYdrqZUeGg//4inUDWITsLhCjURWCRkzsQK830+qI38Pt3S550jfKhv2+NzfWwIPAqMP R0mA== 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 f95-v6si22920491plb.373.2018.09.19.03.02.21; Wed, 19 Sep 2018 03:02:38 -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 S1731007AbeISPj1 (ORCPT + 99 others); Wed, 19 Sep 2018 11:39:27 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:57018 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728059AbeISPj0 (ORCPT ); Wed, 19 Sep 2018 11:39:26 -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 C167A7A9; Wed, 19 Sep 2018 03:02:16 -0700 (PDT) Received: from [10.37.10.80] (unknown [10.37.10.80]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A8B273F703; Wed, 19 Sep 2018 03:02:13 -0700 (PDT) Subject: Re: [PATCH v5 18/18] kvm: arm64: Allow tuning the physical address size for VM To: Peter Maydell Cc: arm-mail-list , kvmarm@lists.cs.columbia.edu, kvm-devel , Marc Zyngier , Christoffer Dall , Eric Auger , Paolo Bonzini , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Will Deacon , Catalin Marinas , James Morse , Dave P Martin , julien.grall@arm.com, lkml - Kernel Mailing List References: <20180917104144.19188-1-suzuki.poulose@arm.com> <20180917104144.19188-19-suzuki.poulose@arm.com> <218b64d5-741d-97ef-8aae-bc0a2ac3e56c@arm.com> From: Suzuki K Poulose Message-ID: Date: Wed, 19 Sep 2018 11:03:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; 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 On 09/18/2018 06:15 PM, Peter Maydell wrote: > On 18 September 2018 at 17:27, Suzuki K Poulose wrote: >> --- >> >> "On arm64, the physical address size for a VM (IPA Size limit) is limited >> to 40bits by default. The limit can be configured if the host supports the >> extension KVM_CAP_ARM_VM_IPA_SIZE. When supported, use >> KVM_VM_TYPE_ARM_IPA_SIZE(IPA_Bits) to set the size in the machine type >> identifier, where IPA_Bits is the maximum width of any physical >> address used by the VM. The IPA_Bits is encoded in bits[7-0] of the >> machine type identifier. >> >> e.g, to configure a guest to use 48bit physical address size : >> >> vm_fd = ioctl(dev_fd, KVM_CREATE_VM, KVM_VM_TYPE_ARM_IPA_SIZE(48)); >> >> The requested size (IPA_Bits) must be : >> 0 - Implies default 40bits (for backward compatibility) >> >> or >> >> N - Implies N bits, where N is a positive integer such that 32 <= N <= >> Host_IPA_Limit >> >> Host_IPA_Limit is the maximum possible value for IPA_Bits on the host and >> is dependent on the CPU capability and the kernel configuration. The limit >> can >> be retrieved using KVM_CAP_ARM_VM_IPA_SIZE of the KVM_CHECK_EXTENSION >> ioctl() at run-time. >> >> Please note that configuring the IPA size does not affect the capability >> exposed by the guest CPUs in ID_AA64MMFR0_EL1[PARange]. It only affects >> the guest to host physical address (stage2) translations setup by the host. >> " > > Thanks, this is much clearer. The only bit I'm not sure about is that > last paragraph -- if I ask for a VM with a 48 bit address space why > don't we tell the guest that that's what it has ? The point is the IPA Size is not a limit on the CPU's PA size. e.g, if this guest was a nested hypervisor with 48bit IPA, it could still support a 52bit IPA nested guest within by simply looking up the CPU PARange. The IPA size configuration here is simply a hint to the hypervisor on where the memory banks would be kept. And this certainly true on real platforms (e.g, my Juno has 42bit PARange on A57, while A53 reports 40bit, with PA max at 40bits). Suzuki