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 093F9C433EF for ; Wed, 22 Jun 2022 09:28:51 +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-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=cmNMUzISaBRz2G1WMEtnBWwnIsjro8AP6vyX4mLXu9g=; b=3E8ozoownVSZCx IQ81Y0DSERYCjHFAfZdHGQcuPBR2EnefMpsDfOqDb4l8Cj+2i5411J9iYsz5L+778CODSCd43oAw+ kJkc2oW+VTO2qxhfHigz2YH6f9ZDRj+rYrK215eeIV4mxONLswrh9VuZhF5xgjVGGIIQRHEw+aOK+ QEZLzYMOltlDP3HCyRz2VZrJ/cE89SkAx2YOjFKyzQ45NAVejyoqHjLKLu05JQ7VmvWgatoC1q6ri PTNNT1+KoNWTeLF1nouyWlBmePVbFe2Gw4kqKWeQsofjuqFgp9cj2P8FAuTTREaSvnVLdoCPxdJqf ZZSs87W8tcDM3a/3emtw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1o3weD-009dVT-PG; Wed, 22 Jun 2022 09:27:42 +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 1o3weA-009dTc-Dr for linux-arm-kernel@lists.infradead.org; Wed, 22 Jun 2022 09:27:40 +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 A3E1613D5; Wed, 22 Jun 2022 02:27:34 -0700 (PDT) Received: from monolith.localdoman (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 93E1B3F66F; Wed, 22 Jun 2022 02:27:32 -0700 (PDT) Date: Wed, 22 Jun 2022 10:27:59 +0100 From: Alexandru Elisei To: Suzuki K Poulose Cc: 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 Subject: Re: [PATCH v4 kvmtool 00/12] arm64: Allow the user to set RAM base address Message-ID: References: <20220616134828.129006-1-alexandru.elisei@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220622_022738_613506_DBC23051 X-CRM114-Status: GOOD ( 37.09 ) 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Suzuki, Will, On Tue, Jun 21, 2022 at 06:03:22PM +0100, Suzuki K Poulose wrote: > 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 Thank you for the review and testing! Will, do you want me to respin the series to gather all the Reviewed-by and Tested-by tags? Thanks, Alex _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel