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 X-Spam-Level: X-Spam-Status: No, score=-15.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D7D43C433ED for ; Mon, 19 Apr 2021 15:59:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B7D5561285 for ; Mon, 19 Apr 2021 15:59:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241742AbhDSP7g (ORCPT ); Mon, 19 Apr 2021 11:59:36 -0400 Received: from foss.arm.com ([217.140.110.172]:45400 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241684AbhDSP7e (ORCPT ); Mon, 19 Apr 2021 11:59:34 -0400 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 4C5311435; Mon, 19 Apr 2021 08:59:04 -0700 (PDT) Received: from [192.168.0.110] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8B4F73F7D7; Mon, 19 Apr 2021 08:59:03 -0700 (PDT) Subject: Re: [PATCH kvm-unit-tests 6/8] arm/arm64: setup: Consolidate memory layout assumptions From: Alexandru Elisei To: Andrew Jones Cc: kvm@vger.kernel.org, nikos.nikoleris@arm.com, andre.przywara@arm.com, eric.auger@redhat.com References: <20210407185918.371983-1-drjones@redhat.com> <20210407185918.371983-7-drjones@redhat.com> <20210415172526.msfseu2qwwb4jquc@kamzik.brq.redhat.com> <49591da9-9d78-cdd8-3587-d535c148de31@arm.com> Message-ID: <366c9a40-01a8-f358-8c34-d766310c09f2@arm.com> Date: Mon, 19 Apr 2021 16:59:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 MIME-Version: 1.0 In-Reply-To: <49591da9-9d78-cdd8-3587-d535c148de31@arm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org Hi Drew, On 4/19/21 4:56 PM, Alexandru Elisei wrote: > Hi Drew, > > On 4/15/21 6:25 PM, Andrew Jones wrote: >> On Thu, Apr 15, 2021 at 05:59:19PM +0100, Alexandru Elisei wrote: >>> Hi Drew, >>> >>> On 4/7/21 7:59 PM, Andrew Jones wrote: >>>> Keep as much memory layout assumptions as possible in init::start >>>> and a single setup function. This prepares us for calling setup() >>>> from different start functions which have been linked with different >>>> linker scripts. To do this, stacktop is only referenced from >>>> init::start, making freemem_start a parameter to setup(). We also >>>> split mem_init() into three parts, one that populates the mem regions >>>> per the DT, one that populates the mem regions per assumptions, >>>> and one that does the mem init. The concept of a primary region >>>> is dropped, but we add a sanity check for the absence of memory >>>> holes, because we don't know how to deal with them yet. >>>> >>>> Signed-off-by: Andrew Jones >>>> --- >>>> arm/cstart.S | 4 +- >>>> arm/cstart64.S | 2 + >>>> arm/flat.lds | 23 ++++++ >>>> lib/arm/asm/setup.h | 8 +-- >>>> lib/arm/mmu.c | 2 - >>>> lib/arm/setup.c | 165 ++++++++++++++++++++++++-------------------- >>>> 6 files changed, 123 insertions(+), 81 deletions(-) >>>> >>>> diff --git a/arm/cstart.S b/arm/cstart.S >>>> index 731f841695ce..14444124c43f 100644 >>>> --- a/arm/cstart.S >>>> +++ b/arm/cstart.S >>>> @@ -80,7 +80,9 @@ start: >>>> >>>> /* complete setup */ >>>> pop {r0-r1} >>>> - bl setup >>>> + mov r1, #0 >>> Doesn't that mean that for arm, the second argument to setup() will be 0 instead >>> of stacktop? >> The second argument is 64-bit, but we assume the upper 32 are zero. > I didn't realize that phys_addr_t is 64bit. > > According to ARM IHI 0042F, page 15: > > "A double-word sized type is passed in two consecutive registers (e.g., r0 and r1, > or r2 and r3). The content of the registers is as if the value had been loaded > from memory representation with a single LDM instruction." > > I think r3 should be zeroed, not r1. r2 and r3 represent the 64bit value. arm is > little endian, so the least significant 32bits will be in r2 and the most > significant bits will be in r3. I can't figure out why r3 is zero, but moving the Correction: r3 is zero because KVM zeroes the general purpose registers on vcpu reset. Thanks, Alex