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 1CF02C83038 for ; Tue, 1 Jul 2025 14:42:22 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1uWcBC-0006fz-TC; Tue, 01 Jul 2025 10:41:52 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uWcAv-0006H5-QQ; Tue, 01 Jul 2025 10:41:33 -0400 Received: from [185.176.79.56] (helo=frasgout.his.huawei.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uWcAs-0006sh-Cj; Tue, 01 Jul 2025 10:41:33 -0400 Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4bWm0x4y7Bz6L52Z; Tue, 1 Jul 2025 22:40:49 +0800 (CST) Received: from frapeml500008.china.huawei.com (unknown [7.182.85.71]) by mail.maildlp.com (Postfix) with ESMTPS id 962CE14027A; Tue, 1 Jul 2025 22:41:12 +0800 (CST) Received: from localhost (10.203.177.66) by frapeml500008.china.huawei.com (7.182.85.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Tue, 1 Jul 2025 16:41:11 +0200 Date: Tue, 1 Jul 2025 15:41:10 +0100 To: Eric Auger CC: , Fan Ni , Peter Maydell , , Zhijian Li , Itaru Kitayama , , , , "Yuquan Wang" , Philippe =?ISO-8859-1?Q?Mathieu-Dau?= =?ISO-8859-1?Q?d=E9?= , Alex =?ISO-8859-1?Q?Benn=E9e?= Subject: Re: [PATCH qemu v16 3/5] hw/arm/virt: Basic CXL enablement on pci_expander_bridge instances pxb-cxl Message-ID: <20250701154110.00007675@huawei.com> In-Reply-To: <4ceea721-b633-499e-9fcd-735990ee0704@redhat.com> References: <20250625161926.549812-1-Jonathan.Cameron@huawei.com> <20250625161926.549812-4-Jonathan.Cameron@huawei.com> <4ceea721-b633-499e-9fcd-735990ee0704@redhat.com> X-Mailer: Claws Mail 4.3.0 (GTK 3.24.42; x86_64-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.203.177.66] X-ClientProxiedBy: lhrpeml100012.china.huawei.com (7.191.174.184) To frapeml500008.china.huawei.com (7.182.85.71) X-Host-Lookup-Failed: Reverse DNS lookup failed for 185.176.79.56 (deferred) Received-SPF: pass client-ip=185.176.79.56; envelope-from=jonathan.cameron@huawei.com; helo=frasgout.his.huawei.com X-Spam_score_int: -33 X-Spam_score: -3.4 X-Spam_bar: --- X-Spam_report: (-3.4 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, RDNS_NONE=0.793, 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: , Reply-to: Jonathan Cameron From: Jonathan Cameron via Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org On Tue, 1 Jul 2025 15:26:26 +0200 Eric Auger wrote: > Hi Jonathan, > > On 6/25/25 6:19 PM, Jonathan Cameron via wrote: > > Code based on i386/pc enablement. > > The memory layout places space for 16 host bridge register regions after > > the GIC_REDIST2 in the extended memmap. This is a hole in the current > > map so adding them here has no impact on placement of other memory regions > > (tested with enough CPUs for GIC_REDIST2 to be in use.) > > Doesn't it depend on the init RAM size setting. > if the init RAM top + REDIST2 aligns to a 256MB boundary (size of the > PCI ECAM) aren't you likely to have no hole? Hi Eric, Is that possible? I think the device_memory_base being force to align to a 1 GiB means that never happens. That seems to occur even if there is no device_memory. device_memory_base = ROUND_UP(vms->memmap[VIRT_MEM].base + ms->ram_size, GiB); device_memory_size = ms->maxram_size - ms->ram_size + ms->ram_slots * GiB; /* Base address of the high IO region */ memtop = base = device_memory_base + ROUND_UP(device_memory_size, GiB); //So here we are GiB aligned. ... if (base < vms->memmap[VIRT_MEM].base + LEGACY_RAMLIMIT_BYTES) { base = vms->memmap[VIRT_MEM].base + LEGACY_RAMLIMIT_BYTES; } //That's 256 GiB in or leave it alone as more than that but GiB aligned. /* We know for sure that at least the memory fits in the PA space */ vms->highest_gpa = memtop - 1; virt_set_high_memmap(vms, base, pa_bits); So I think I'm fine. I should call out that REDIST2 is GiB aligned though in this patch description. > > > > > > The CFMWs are placed above the extended memmap. Note the confusing > > existing variable highest_gpa is the highest_gpa that has been allocated > > at a particular point in setting up the memory map. > what kind of improvement would you foresee wrt highest_gpa? This was mostly a response to Peter expressed that he was expecting highest_gpa to reflect the limit, not the highest yet seen. I'm not sure how to resolve that without having awkward naming like highest_gpa_sofar. There are existing comments where it is updated so I'm not thinking we need to change anything for this. Thanks for taking a look, Jonathan