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 lists.gnu.org (lists.gnu.org [209.51.188.17]) (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 C357BC433EF for ; Thu, 6 Jan 2022 21:29:56 +0000 (UTC) Received: from localhost ([::1]:43650 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n5aKZ-0003tz-RS for qemu-devel@archiver.kernel.org; Thu, 06 Jan 2022 16:29:55 -0500 Received: from eggs.gnu.org ([209.51.188.92]:41092) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n5aHb-0007r4-Fg for qemu-devel@nongnu.org; Thu, 06 Jan 2022 16:26:51 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:37108) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n5aHV-0001XJ-Qe for qemu-devel@nongnu.org; Thu, 06 Jan 2022 16:26:47 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 4DDC8B8240E; Thu, 6 Jan 2022 21:26:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0923DC36AE3; Thu, 6 Jan 2022 21:26:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1641504397; bh=O4xI8X4Ahapcy6SScuecm/AabsQ3pVKDC7fpb6BqBfM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ftGNL2kfWkhDTXSIo3L/n3wsqKYvVeVGvVHNC29WfVkpdNBEjBGzewHy9UHSA4xcf AF27elnCSEwratleb5efXi/TmBu5MhzCrFrpRJdidXfPbeKA5QV+kvHtW6Acp+LiO7 L4zSuGkuxnCwJ/Vl1oxA0aud2HZtBFKYTFPnNlTlcAV4dG7DWFFBSIdZHlWh/kZ4WO jkgjZafVD1gG6ETkaEjVyoNBqxID+J5MkEA/T14xtzIC3pO13PKSXUfmyhelVP1qn6 uvPj8up1K+AZ7VkE2C7SWko84dTsz7lZ9fUMrR+M7IT5gOAt92S47EaYLCTCN/swp1 eXeWT0OT+RkkA== Received: from sofa.misterjones.org ([185.219.108.64] helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1n5aHL-00GRDk-5L; Thu, 06 Jan 2022 21:26:35 +0000 Date: Thu, 06 Jan 2022 21:26:34 +0000 Message-ID: <871r1kzhbp.wl-maz@kernel.org> From: Marc Zyngier To: eric.auger@redhat.com Subject: Re: [PATCH v3 3/5] hw/arm/virt: Honor highmem setting when computing the memory map In-Reply-To: References: <20211227211642.994461-1-maz@kernel.org> <20211227211642.994461-4-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: eric.auger@redhat.com, qemu-devel@nongnu.org, drjones@redhat.com, peter.maydell@linaro.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, kernel-team@android.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Received-SPF: pass client-ip=145.40.68.75; envelope-from=maz@kernel.org; helo=ams.source.kernel.org X-Spam_score_int: -24 X-Spam_score: -2.5 X-Spam_bar: -- X-Spam_report: (-2.5 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.372, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Andrew Jones , kvm@vger.kernel.org, qemu-devel@nongnu.org, kernel-team@android.com, kvmarm@lists.cs.columbia.edu Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Wed, 05 Jan 2022 09:22:39 +0000, Eric Auger wrote: > > Hi Marc, > > On 12/27/21 10:16 PM, Marc Zyngier wrote: > > Even when the VM is configured with highmem=off, the highest_gpa > > field includes devices that are above the 4GiB limit. > > Similarily, nothing seem to check that the memory is within > > the limit set by the highmem=off option. > > > > This leads to failures in virt_kvm_type() on systems that have > > a crippled IPA range, as the reported IPA space is larger than > > what it should be. > > > > Instead, honor the user-specified limit to only use the devices > > at the lowest end of the spectrum, and fail if we have memory > > crossing the 4GiB limit. > > > > Reviewed-by: Andrew Jones > > Signed-off-by: Marc Zyngier > > --- > > hw/arm/virt.c | 9 ++++++++- > > 1 file changed, 8 insertions(+), 1 deletion(-) > > > > diff --git a/hw/arm/virt.c b/hw/arm/virt.c > > index 8b600d82c1..84dd3b36fb 100644 > > --- a/hw/arm/virt.c > > +++ b/hw/arm/virt.c > > @@ -1678,6 +1678,11 @@ static void virt_set_memmap(VirtMachineState *vms) > > exit(EXIT_FAILURE); > > } > > > > + if (!vms->highmem && > > + vms->memmap[VIRT_MEM].base + ms->maxram_size > 4 * GiB) { > > + error_report("highmem=off, but memory crosses the 4GiB limit\n"); > > + exit(EXIT_FAILURE); > > The memory is composed of initial memory and device memory. > device memory is put after the initial memory but has a 1GB alignment > On top of that you have 1G page alignment per device memory slot > > so potentially the highest mem address is larger than > vms->memmap[VIRT_MEM].base + ms->maxram_size. > I would rather do the check on device_memory_base + device_memory_size Yup, that's a good point. There is also a corner case in one of the later patches where I check this limit against the PA using the rounded-up device_memory_size. This could result in returning an error if the last memory slot would still fit in the PA space, but the rounded-up quantity wouldn't. I don't think it matters much, but I'll fix it anyway. > > + } > > /* > > * We compute the base of the high IO region depending on the > > * amount of initial and device memory. The device memory start/size > > @@ -1707,7 +1712,9 @@ static void virt_set_memmap(VirtMachineState *vms) > > vms->memmap[i].size = size; > > base += size; > > } > > - vms->highest_gpa = base - 1; > > + vms->highest_gpa = (vms->highmem ? > > + base : > > + vms->memmap[VIRT_MEM].base + ms->maxram_size) - 1; > As per the previous comment this looks wrong to me if !highmem. Agreed. > If !highmem, if RAM requirements are low we still could get benefit from > REDIST2 and HIGH ECAM which could fit within the 4GB limit. But maybe we > simply don't care? I don't see how. These devices live at a minimum of 256GB, which contradicts the very meaning of !highmem being a 4GB limit. > If we don't, why don't we simply skip the extended_memmap overlay as > suggested in v2? I did not get your reply sorry. Because although this makes sense if you only care about a 32bit limit, we eventually want to check against an arbitrary PA limit and enable the individual devices that do fit in that space. In order to do that, we need to compute the base addresses for these extra devices. Also, computing 3 base addresses isn't going to be massively expensive. Thanks, M. -- Without deviation from the norm, progress is not possible.