Received: by 2002:ac0:a591:0:0:0:0:0 with SMTP id m17-v6csp683706imm; Thu, 5 Jul 2018 07:14:35 -0700 (PDT) X-Google-Smtp-Source: AAOMgpctNRqmzd8Hj7xkIGkHFfTh2R4dHAVzpgo9XFfmUcY0KKnwWOKDwhtRHfzNOmGlg3EXqasP X-Received: by 2002:a62:700a:: with SMTP id l10-v6mr6515927pfc.71.1530800074928; Thu, 05 Jul 2018 07:14:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530800074; cv=none; d=google.com; s=arc-20160816; b=jLwBYhtwfLVQO0oQHw3FZPMt7L5wVtxbp/4+rdNdj426nV0mvIZSgJU7IuM1jKj8Ou q9Ar0CQdOxO3B7h5YtWrKIFEwWl+7nOk6QtnLWiNZI7wiYshs8U1Gpl/LsvEVT93CNtq vuu6gNP73DBFruFGKxl5IKMlzjVz6a7aXEmqUfr9EoJlGmxpLRC6i6Rn9k2NHEu/Z4M1 YJA12SNVSUCBx9uCC+/S2VQolaGOUwmWFDhuI16nVtbiKQswBAoyAQ3Ny/EJKg2yEQJ2 2akOwoEiNrpHHJCtCBqCzxR7kXJv721qPY0n8C8GpgIWKWu2Car8iJJv4reb9J7DpaRJ w/4w== 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=vAyo9Sb9CN5BP9I4ZHfkCjQBd7usF+zgdAehdUuKuuo=; b=oXYOy9+OFWsHNg/JfCmeQAS+yydUHCwWTC0hcR0tNhmyCQizYJAdl+Y0ZhLYmubR6x ucfFrgp4j9DNISbvq/N62B99G6q9L14kMjHUY27+DZy4DDbBs4jLK1qKcO94Xrllckt1 depzThwwwvU+0YEU31N8R0XaXoODQo+6J/EymD0Ry6tnbj7swjIuO0gW8HXrjYLOFvOb z0YzdOxvLOW28ZDfUzoxfvxP1Xr2luTwfgWqrIgn062Eq8RtaNZSR6SFF3O+8I34FdtN +1FYaTfUNT+5gxdLyu15MdM1EVUg223xs1TRopc7y+5W1FyVuNJl44RTlDjKILbYIL2P 7z3g== 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 a9-v6si5931537pgn.177.2018.07.05.07.14.19; Thu, 05 Jul 2018 07:14:34 -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 S1753656AbeGEOMy (ORCPT + 99 others); Thu, 5 Jul 2018 10:12:54 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:50486 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753411AbeGEOMw (ORCPT ); Thu, 5 Jul 2018 10:12:52 -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 3805B18A; Thu, 5 Jul 2018 07:12:52 -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 018203F5BA; Thu, 5 Jul 2018 07:12:49 -0700 (PDT) Subject: Re: [kvmtool test PATCH 22/24] kvmtool: arm64: Add support for guest physical address size To: Auger Eric , Marc Zyngier , Julien Grall , Will Deacon Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, james.morse@arm.com, cdall@kernel.org, catalin.marinas@arm.com, punit.agrawal@arm.com, qemu-devel@nongnu.org References: <1530270944-11351-1-git-send-email-suzuki.poulose@arm.com> <1530270944-11351-23-git-send-email-suzuki.poulose@arm.com> <20180704140943.GF4828@arm.com> <8c9bb3cd-f673-17f3-656f-66b7e14fc73c@arm.com> <20180704155231.GP4828@arm.com> From: Suzuki K Poulose Message-ID: <5790744f-a8bd-3a44-8e8d-bc3e05b74ce5@arm.com> Date: Thu, 5 Jul 2018 15:12:48 +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 On 05/07/18 14:46, Auger Eric wrote: > Hi Marc, > > On 07/05/2018 03:20 PM, Marc Zyngier wrote: >> On 05/07/18 13:47, Julien Grall wrote: >>> Hi Will, >>> >>> On 04/07/18 16:52, Will Deacon wrote: >>>> On Wed, Jul 04, 2018 at 04:00:11PM +0100, Julien Grall wrote: >>>>> On 04/07/18 15:09, Will Deacon wrote: >>>>>> On Fri, Jun 29, 2018 at 12:15:42PM +0100, Suzuki K Poulose wrote: >>>>>>> Add an option to specify the physical address size used by this >>>>>>> VM. >>>>>>> >>>>>>> Signed-off-by: Suzuki K Poulose >>>>>>> --- >>>>>>> arm/aarch64/include/kvm/kvm-config-arch.h | 5 ++++- >>>>>>> arm/include/arm-common/kvm-config-arch.h | 1 + >>>>>>> 2 files changed, 5 insertions(+), 1 deletion(-) >>>>>>> >>>>>>> diff --git a/arm/aarch64/include/kvm/kvm-config-arch.h b/arm/aarch64/include/kvm/kvm-config-arch.h >>>>>>> index 04be43d..dabd22c 100644 >>>>>>> --- a/arm/aarch64/include/kvm/kvm-config-arch.h >>>>>>> +++ b/arm/aarch64/include/kvm/kvm-config-arch.h >>>>>>> @@ -8,7 +8,10 @@ >>>>>>> "Create PMUv3 device"), \ >>>>>>> OPT_U64('\0', "kaslr-seed", &(cfg)->kaslr_seed, \ >>>>>>> "Specify random seed for Kernel Address Space " \ >>>>>>> - "Layout Randomization (KASLR)"), >>>>>>> + "Layout Randomization (KASLR)"), \ >>>>>>> + OPT_INTEGER('\0', "phys-shift", &(cfg)->phys_shift, \ >>>>>>> + "Specify maximum physical address size (not " \ >>>>>>> + "the amount of memory)"), >>>>>> >>>>>> Given that this is a shift value, I think the help message could be more >>>>>> informative. Something like: >>>>>> >>>>>> "Specify maximum number of bits in a guest physical address" >>>>>> >>>>>> I think I'd actually leave out any mention of memory, because this does >>>>>> actually have an effect on the amount of addressable memory in a way that I >>>>>> don't think we want to describe in half of a usage message line :) >>>>> Is there any particular reasons to expose this option to the user? >>>>> >>>>> I have recently sent a series to allow the user to specify the position >>>>> of the RAM [1]. With that series in mind, I think the user would not really >>>>> need to specify the maximum physical shift. Instead we could automatically >>>>> find it. >>>> >>>> Marc makes a good point that it doesn't help for MMIO regions, so I'm trying >>>> to understand whether we can do something differently there and avoid >>>> sacrificing the type parameter. >>> >>> I am not sure to understand this. kvmtools knows the memory layout >>> (including MMIOs) of the guest, so couldn't it guess the maximum >>> physical shift for that? >> >> That's exactly what Will was trying to avoid, by having KVM to compute >> the size of the IPA space based on the registered memslots. We've now >> established that it doesn't work, so what we need to define is: >> >> - whether we need another ioctl(), or do we carry on piggy-backing on >> the CPU type, > kvm type I guess machine type is more appropriate, going by the existing users. >> - assuming the latter, whether we can reduce the number of bits used in >> the ioctl parameter by subtly encoding the IPA size. > Getting benefit from your Freudian slip, how should guest CPU PARange > and maximum number of bits in a guest physical address relate? > > My understanding is they are not correlated at the moment and our guest > PARange is fixed at the moment. But shouldn't they? > > On Intel there is > qemu-system-x86_64 -M pc,accel=kvm -cpu SandyBridge,phys-bits=36 > or > qemu-system-x86_64 -M pc,accel=kvm -cpu SandyBridge,host-phys-bits=true > > where phys-bits, as far as I understand has a a similar semantics as the > PARange. AFAIT, PARange tells you the maximum (I)Physcial Address that can be handled by the CPU. But your IPA limit tells you where the guest RAM is placed. So they need not be the same. e.g, on Juno, A57's have a PARange of 42 if I am not wrong (but definitely > 40), while A53's have it at 40 and the system RAM is at 40bits. So, if we were to only use the A57s on Juno, we could run a KVM instance with 42 bits IPA or anything lower. So, PARange can be inferred as the maximum limit of the CPU's capability while the IPA is where the RAM is placed for a given system. One could keep them in sync for a VM by emulating, but then nobody uses the PARange, except the KVM. The other problem with capping PARange in the VM to IPA is restricting the IPA size of a nested VM. So, I don't think this is really beneficial. Cheers Suzuki > > Thanks > > Eric >> >> Thanks, >> >> M. >>