From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 78079C433EF for ; Tue, 21 Jun 2022 17:04:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:To:Subject:MIME-Version: Date:Message-ID:Reply-To:Cc:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=FmMDeAfpTbAlzgVVR/+/PmWuKPYiIcZaKT1vTxvX+vA=; b=lIg4r2Qv0drOEbd/MvEk3jQHSY BAPpczBQwIArbd/wE5fJ9o/Hx5+AXXVWgT2tMzKK4O8HRr0VMASZmMVUkqi4rs723xXw80s9Lvy4j dLS68hKewdXexiAd6A4XDHta7Dyss8sDmBcNPiVodQRK1dhDJeqcwbuqAY40u8uIHwhDvxz8KDmZd G6TPFeOl4rad7840phnnk+UpH6YOUKM5utysq9xVMhaOKay9XWlNX4IEY0aehqleDf80rsB3JXkM6 ZynWigo2cW5DJt/vjHUKcihNOig/MiFTYvvet0C9QVvShIsgRc5IVY+nq+jR1YKBKFUKdN1RZvh2S ecGP6CIQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1o3hHv-006UTy-Hj; Tue, 21 Jun 2022 17:03:39 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1o3hHr-006UT3-Dv for linux-arm-kernel@lists.infradead.org; Tue, 21 Jun 2022 17:03:37 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A835A165C; Tue, 21 Jun 2022 10:03:30 -0700 (PDT) Received: from [10.57.84.82] (unknown [10.57.84.82]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 61A923F792; Tue, 21 Jun 2022 10:03:26 -0700 (PDT) Message-ID: Date: Tue, 21 Jun 2022 18:03:22 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [PATCH v4 kvmtool 00/12] arm64: Allow the user to set RAM base address To: Alexandru Elisei , will@kernel.org, julien.thierry.kdev@gmail.com, maz@kernel.org, julien@xen.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, james.morse@arm.com, andre.przywara@arm.com References: <20220616134828.129006-1-alexandru.elisei@arm.com> From: Suzuki K Poulose In-Reply-To: <20220616134828.129006-1-alexandru.elisei@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220621_100335_614260_310F8162 X-CRM114-Status: GOOD ( 30.92 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 16/06/2022 14:48, Alexandru Elisei wrote: > The series can be found at [1]. It is loosely based on the patches that > allow the user to define the VM memory layout (RAM + MMIO) [2]. I've > cherry-picked a handful of patches from that series, the rest I wrote from > scratch since there have been several changes to the way guest memory is > handled. I've chosen to focus on specifying the RAM layout with only one > RAM bank and leave the rest for a later series because this was relatively > easy to accomplish, while still being very useful. > > What this series does: for arm64, the user can now specify the base address > for RAM: > > $ ./lkvm run -m1G@2G .. # Equivalent to ./lkvm run -m1024 > > The memory units are B (bytes), K (kilobytes), M (megabytes), G > (gigabytes), T (terrabytes), P (petabytes). Lowercase is also valid. > > Want to put RAM at the top of the physical address range? Easy: > > $ ./lkvm run -m2G@1022G .. # Assumes the maximum is 40 bits of IPA > > There one limitation on the RAM base address: it must not overlap with the > MMIO range that kvmtool uses for arm/arm64, which lives below 2GB. > > Why this is useful, in my opinion: > > 1. Testing how a payload handles different memory layouts without the need > to hack kvmtool or find the hardware that implements the desired layout. > > 2. It can serve as a development tool for adding support for larger PA > ranges for Linux and KVM (currently capped at 48 bits for 4k/16k pages), or > other payloads. > > Summary of the series > ====================== > > * The series starts with refactoring how kvm->cfg.ram_size is validated > and used, followed by several cleanups in the arm and arm64 code. > > * Then patch #8 ("builtin_run: Allow standard size specifiers for memory") > introduced the ability to specify the measurement unit for memory. I > believe that typing the equivalent of 2TB in megabytes isn't appealing > for anyone. > > * More cleanups in the arm/arm64 code follow, which are needed for patch > #12 ("arm64: Allow the user to specify the RAM base address"). This is > where the ability to specify the RAM base address is introduced. > > Testing > ======= > > Same testing as before: > > - Build tested each patch for all architectures. > > - Ran an x86 kernel with and without setting the amount of RAM using the > memory specifiers; tested that setting the RAM address results in an > error. > > - Ran an arm64 kernel without setting the size, with setting the size and > with setting the size and address; tried different addresses (2G, 3G, > 256G); also tested that going below 2G or above the maximum IPA correctly > results in an error. > > - Ran all arm64 kvm-unit-test tests with similar combinations of memory > size and address (instead of 256G I used 128G, as that's where I/O lives > for qemu and kvm-unit-tests maps that unconditionally as I/O). > > - Ran all 32bit arm tests on an arm64 host with various combinations of > memory size and address (base address at 2G and 2.5G only due to a > limitation in the way the tests are set up). I have tested this series on arm64 Fast model, with memory placed from 32bit to 48bit IPA and it works well. For the series: Reviewed-and-Tested-by: Suzuki K Poulose _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel