[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 1/3] common: introduce "brk" allocator
- To: Jan Beulich <jbeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- From: Jason Andryuk <jason.andryuk@xxxxxxx>
- Date: Thu, 29 Oct 2026 20:02:43 -0400
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0)
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=IGZqTsZQRonp6yDXZ074c5A5YvMS6rkOgc+QQ3a5fRU=; b=eeymBwviZvr/JQdZDxDn5190z0JYFnrmr2d29fKap26zqfoLYXGGZZob6e46BcV4gTLTL+XVeIqPs4VNTD3l1eIyxX/UEOl+WNXERI3iqAW5diyE+D6+JS6Z/+tzSiKXQy48hlw2f2KFQX28Z5pzhbDahqZ27tFhw50bDQKnBtaO53S448sR5jGli1om3jhk888tLF9sGdUI7HOSGtdG/uTC/O7eH1as2hOqzJk8bw1imfckMZzwt6YYkGodMVkmSlXhMTGE6y4njDjIQ03aWcsK39SYoDIRCVat/6nJcY2/yl4477zYjoSwTYZFoFV53NvxXr7Xmyf1wsLRVSON8Q==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=CzDJf3aLrHWKAmR9wzNlY0NYfIcRzIa5hse4+tI0TrYuGB3zeCi1eL4aAiDz5pk82cm22nmr5kFYXr3YW96z981bIaXk5NbifJ4aw2McErYNb1ZWfEcytPhuPGTIAWk8OARU8vzn6bI6OasLPC7ORAOyyKQYAiuBe9xulS9JYJPVWy+X9gB0WCVRGFZ6Ljt9k28biTJX39G34p+J5eqEoGk8invsOxACafFrSo+uTiEYiGz3ByxvxPN/O92t1OOCk2zk3lhCsC/G8xD8nHbhm3ekvb7zrPbJRq05YwYQId6xJ4lla6kZkQay2Ic0XrsYh4W92CfCVgjM4+Qgz/GsHw==
- Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
- Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Roger Pau Monné <roger@xxxxxxxxxxxxxx>, Teddy Astie <teddy.astie@xxxxxxxxxx>
- Delivery-date: Fri, 30 Oct 2026 00:03:17 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 2026-10-14 09:01, Jan Beulich wrote:
... to replace (on x86) ebmalloc(), and then to find further use(s) to
allow recovering memory which is needed very early (and hence needs
setting up statically), but may not fully be used (or not be used at all).
Note that unlike free_ebmalloc_unused_mem(), brk_free_unused() (once
other code is converted) will be able to free part of the BRK space even
in the xen.efi case on x86. That would happen if BRK space extends across
a 2Mb boundary, and actual use stops before that boundary.
Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
---
Changing setup.c's reserve_e820_ram() uses would be cumbersome when done
right here. That'll be done when ebmalloc() is replaced, and hence
what's there can also simply be replaced.
When linking xen.efi, GNU ld prior to 2.46 produces a base relocation for
the reference to __subsystem__, which is wrong (that's an absolute symbol,
after all). That does no harm for our purposes, though.
--- /dev/null
+++ b/xen/arch/x86/include/asm/brk.h
@@ -0,0 +1,23 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+#ifndef X86_BRK_H
+#define X86_BRK_H
+
+static inline unsigned long brk_adjust_start(unsigned long start)
+{
+ unsigned int subsys;
+
+ /*
+ * Only xen.efi will have the symbol __subsystem__ available, and it'll
+ * be non-zero (10) there. In ELF the symbol will be undefined, and
+ * hence zero will be loaded into the register.
+ */
+ asm ( ".weak __subsystem__; mov $__subsystem__, %0" : "=r" (subsys) );
This seems like an indirect way of determining if xen.efi is running.
Your comment explains this, so it's ok. It seems to me that an
alternative would be to add an explicit symbol to the xen.efi linking
instead of this implicit one. Though that would just be replacing
__subsystem__ with something else, so maybe it's not worth it.
Reviewed-by: Jason Andryuk <jason.andryuk@xxxxxxx>
Regards,
Jason
|
