Received: by 10.192.165.156 with SMTP id m28csp463659imm; Mon, 16 Apr 2018 03:25:02 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+Xswf2fXIE0BeSME6rPJM4H22Dgod7w9y7XmmX3wG+aw9rfOeJ1+OcMd5lkloCWk09zRkV X-Received: by 10.98.141.20 with SMTP id z20mr21084676pfd.144.1523874302161; Mon, 16 Apr 2018 03:25:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523874302; cv=none; d=google.com; s=arc-20160816; b=e/j8mxFVQPxKVVvSKevPnTQFXIJsNhEZ0Ak4NQQV0HJyBWUSt9tG9s1q8+gRsKvWNi mEMWUjr+s0HtrNF6WCY0KE/3IAZtBizcyV99FTMcMI2iumY8VDufwQukmxFWK3zk10SA CCDXG+ec8NZ+WdPBUETKwUph4KnqKOF/ayDGkG8jI30vsIb2vKwXUqrmFEMuFi0t/TjC IIJroVgZImmKjpaTBwpzduBYaohYrl5Fi3dB5pWtbm8qnt6/28/KE8A1ywTfP+FBcdXt uMY8C9MAhpD5YfX61971PBlz7pbC1XZ1r9+dNO3N7nkyaMV0veuxbiQLUq19rX/6YQsW +Ieg== 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=QOtxK7guaLBsh45Mh9otwTjVyBsGbbiGu6yE6sqUmqE=; b=TlU7zAm8kbNqVKfe66PpaFKhhR2kuQMzf1EkvIm4CNyeEpYGCf/x8vM3tB8WG/kdam 8Ijcn3934CR+HN8k3tx7M1I8I9SPBeKGAn7Tg1luWlovpzuJQQk6yAo/TL/LmwDoaRhU Tu/esHLNqUPZgTc2HSZF6u1PBhaY76o1YCSjsAVmmZ3UjwG6Rh8lTIGA+Zr05G7yo2TR 6kDtCMcs85is5iGezPdKxRHOdL3IxEhfVUe44elf0+TdT8r51EKAqQw3u3bKXSPdSUU4 t/cNdri7eh6zm0F+hA/LD8UizbW1GtbPB768ntxwSOVSH+BkY6PrSEPGtFYF/1MOhHiE vO+g== 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 n65si9244800pga.90.2018.04.16.03.24.44; Mon, 16 Apr 2018 03:25:02 -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 S1754005AbeDPKXK (ORCPT + 99 others); Mon, 16 Apr 2018 06:23:10 -0400 Received: from foss.arm.com ([217.140.101.70]:57712 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753218AbeDPKXI (ORCPT ); Mon, 16 Apr 2018 06:23:08 -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 2253A15B2; Mon, 16 Apr 2018 03:23:08 -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 4EA453F25D; Mon, 16 Apr 2018 03:23:05 -0700 (PDT) Subject: Re: [PATCH v2 12/17] kvm: arm/arm64: Expose supported physical address limit for VM To: Peter Maydell Cc: arm-mail-list , lkml - Kernel Mailing List , kvmarm@lists.cs.columbia.edu, kvm-devel , Christoffer Dall , Marc Zyngier , Punit Agrawal , Will Deacon , Catalin Marinas , Paolo Bonzini , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Ard Biesheuvel , Kristina Martsenko , Mark Rutland References: <1522156531-28348-1-git-send-email-suzuki.poulose@arm.com> <1522156531-28348-13-git-send-email-suzuki.poulose@arm.com> From: Suzuki K Poulose Message-ID: Date: Mon, 16 Apr 2018 11:23:03 +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=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 On 13/04/18 14:21, Peter Maydell wrote: > On 27 March 2018 at 14:15, Suzuki K Poulose wrote: >> Expose the maximum physical address size supported by the host >> for a VM. This could be later used by the userspace to choose the >> appropriate size for a given VM. The limit is determined as the >> minimum of actual CPU limit, the kernel limit (i.e, either 48 or 52) >> and the stage2 page table support limit (which is 40bits at the moment). >> For backward compatibility, we support a minimum of 40bits. The limit >> will be lifted as we add support for the stage2 to support the host >> kernel PA limit. >> >> This value may be different from what is exposed to the VM via >> CPU ID registers. The limit only applies to the stage2 page table. >> >> Cc: Christoffer Dall >> Cc: Marc Zyngier >> Cc: Peter Maydel >> Signed-off-by: Suzuki K Poulose >> --- >> Documentation/virtual/kvm/api.txt | 14 ++++++++++++++ >> arch/arm/include/asm/kvm_mmu.h | 5 +++++ >> arch/arm64/include/asm/kvm_mmu.h | 5 +++++ >> include/uapi/linux/kvm.h | 6 ++++++ >> virt/kvm/arm/arm.c | 6 ++++++ >> 5 files changed, 36 insertions(+) >> >> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt >> index 792fa87..55908a8 100644 >> --- a/Documentation/virtual/kvm/api.txt >> +++ b/Documentation/virtual/kvm/api.txt >> @@ -3500,6 +3500,20 @@ Returns: 0 on success; -1 on error >> This ioctl can be used to unregister the guest memory region registered >> with KVM_MEMORY_ENCRYPT_REG_REGION ioctl above. >> >> +4.113 KVM_ARM_GET_MAX_VM_PHYS_SHIFT >> +Capability: basic >> +Architectures: arm, arm64 >> +Type: system ioctl >> +Parameters: none >> +Returns: log2(Maximum physical address space size) supported by the >> +hyperviosr. > > typo: "hypervisor". > Will fix it. >> + >> +This ioctl can be used to identify the maximum physical address space size >> +supported by the hypervisor. > > Is that the physical address space on the host, or the physical > address space size we present to the guest? It is the size of the address space we present to the guest. I will update the documentation to make it more clear. > >> The returned value indicates the maximum size >> +of the address that can be resolved by the stage2 translation table on >> +arm/arm64. On arm64, the value is decided based on the host kernel >> +configuration and the system wide safe value of ID_AA64MMFR0_EL1:PARange. >> +This may not match the value exposed to the VM in CPU ID registers. > > Isn't it likely to confuse the guest if we lie to it about the PA range it > sees? When would the two values differ? On a heterogeneous system, the guest could see different values of PARange on the same VCPU. So that is not safe for a guest at the moment. Ideally, we should emulate the PARange to provide the system wide safe value, which the guest can read. We don't touch the emulation of PARange in the ID registers in this set. All we do is (in the next patches) limiting the address space size provided to the guest. May be we could update PARange to the limit imposed and emulate the field. > > Do we also need a 'set' operation, so userspace can create a VM > that has a 40 bit userspace on a CPU that supports more than that, > or does it just work? It just works as before, creating a 40bit userspace, without any additional steps. All we do is, allowing to create a VM with bigger address space by specifying the size in the "type" field. The other question is, does it really matter what a guest sees in PARange and what it is provided with ? e.g, on my Juno, the A53's have 40bit and A57 has 44bit, while the system uses only 40bit. This will be true even with the new change. i.e, we don't allow a size beyond the limit supported by all the CPUs on the system. > > What's the x86 API for KVM to tell userspace about physical address > range restrictions? From a quick look, the limit comes from cpuid (leaf 0x80000008 ?). So, it could be via the existing per-VCPU get/set_cpuid{,2}() API on x86. Suzuki