Received: by 2002:ac0:a591:0:0:0:0:0 with SMTP id m17-v6csp592724imm; Thu, 5 Jul 2018 05:49:15 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcDdpalwAdzUBMVV1NTgjNg0X0wNSNY5pDh1vY6fDSLkvpTt2rYyb5+vcWBaaczy6fq5tLx X-Received: by 2002:a63:455c:: with SMTP id u28-v6mr5533447pgk.210.1530794955246; Thu, 05 Jul 2018 05:49:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530794955; cv=none; d=google.com; s=arc-20160816; b=AWPMuPeIrD3zWxLrx6YSP7qcz0FlxcU+htEyN6gUprakUXWzffigzB7frlxVyJPWAr 7GRoD8WSB4sc8BRwRJ4DCKfBUwudxctkix1kw+tWlnmUtnMxskDb1Y2L9YWznwmMrsdM xV1ICgvUgkrh4N9U1ASy2KukHsVY58x73FDli7oL3NWYLfat6qny9GE/zzVy2kkM+n1r ubY8jQg5UhiQMMPpFlF0ZqSDxSMhSor9Nva3dsv9k2C7+k7lj3k8ppbc0o0lg+Vjm9Q0 o0NPjJRvaRqsEgx4sO8NgcQC2h2c88yDrZNThkxvGpYnND9/GI2m79zUE3SxD1c6bmns 9lMQ== 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=F8hw/orNpKxqtthSVwqVIi44W/LVmYdnrruWArX6HKg=; b=HXJdZ6QwjEU1MrxNqdj8BJ0Jlw8hdYmDV/4vDfrmS9efVqCbPE+FbOTR8HY5IvDk2p mxqba6DnIbHzbfn7TLcdJv1whiuq1fIcdPqDLU1hLkHQctLdph5Efiwkt0aNKZTn5Nqu e7xsGZt8kGyui9pTIYfWfvYfHYRgq8ExpccQHFTOX8M5+6GG3ZrhGMQKLE7tBU5pvg/V 6IHz+vx0u+d9C8chR4+btHCFDGcAYpQXL35pOggQtFUTBvZRnqGzVG6VgvoL9uSjRwJP 2xPTvhOgDBPI5Wv4OW/9YmofGCMOgNdeAeGBoVif0AJAvgWIkPoAuV7+jeMscinCvmFf KtBg== 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 s3-v6si5874315plb.394.2018.07.05.05.49.01; Thu, 05 Jul 2018 05:49:15 -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 S1754135AbeGEMrb (ORCPT + 99 others); Thu, 5 Jul 2018 08:47:31 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:49182 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753886AbeGEMra (ORCPT ); Thu, 5 Jul 2018 08:47: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 D80E518A; Thu, 5 Jul 2018 05:47:29 -0700 (PDT) Received: from [10.1.206.53] (e108454-lin.cambridge.arm.com [10.1.206.53]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id AD7053F2EA; Thu, 5 Jul 2018 05:47:27 -0700 (PDT) Subject: Re: [kvmtool test PATCH 22/24] kvmtool: arm64: Add support for guest physical address size To: Will Deacon Cc: Suzuki K Poulose , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, james.morse@arm.com, marc.zyngier@arm.com, cdall@kernel.org, eric.auger@redhat.com, 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: Julien Grall Message-ID: Date: Thu, 5 Jul 2018 13:47:26 +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: <20180704155231.GP4828@arm.com> 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 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? Cheers, -- Julien Grall