[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180704155231.GP4828@arm.com>
Date: Wed, 4 Jul 2018 16:52:31 +0100
From: Will Deacon <will.deacon@....com>
To: Julien Grall <julien.grall@....com>
Cc: Suzuki K Poulose <suzuki.poulose@....com>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
kvm@...r.kernel.org, kvmarm@...ts.cs.columbia.edu,
james.morse@....com, marc.zyngier@....com, cdall@...nel.org,
eric.auger@...hat.com, catalin.marinas@....com,
punit.agrawal@....com, qemu-devel@...gnu.org
Subject: Re: [kvmtool test PATCH 22/24] kvmtool: arm64: Add support for guest
physical address size
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 <suzuki.poulose@....com>
> >>---
> >> 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.
Will
Powered by blists - more mailing lists