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.xenproject.org (lists.xenproject.org [192.237.175.120]) (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 69760CA0FFE for ; Tue, 2 Sep 2025 14:29:07 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.1106638.1457277 (Exim 4.92) (envelope-from ) id 1utS0F-0005XT-4U; Tue, 02 Sep 2025 14:28:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1106638.1457277; Tue, 02 Sep 2025 14:28:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utS0F-0005XM-0c; Tue, 02 Sep 2025 14:28:55 +0000 Received: by outflank-mailman (input) for mailman id 1106638; Tue, 02 Sep 2025 14:28:54 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1utS0E-0005XB-7E for xen-devel@lists.xenproject.org; Tue, 02 Sep 2025 14:28:54 +0000 Received: from isis.lip6.fr (isis.lip6.fr [2001:660:3302:283c::2]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 20ff8d26-8809-11f0-8dd7-1b34d833f44b; Tue, 02 Sep 2025 16:28:44 +0200 (CEST) Received: from asim.lip6.fr (asim.lip6.fr [132.227.86.2]) by isis.lip6.fr (8.18.1/8.16.1) with ESMTPS id 582ESgw4008511 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 2 Sep 2025 16:28:42 +0200 (CEST) Received: from armandeche.soc.lip6.fr (armandeche [132.227.63.133]) by asim.lip6.fr (8.15.2/8.15.2) with ESMTP id 582ESfww029290; Tue, 2 Sep 2025 16:28:41 +0200 (MEST) Received: by armandeche.soc.lip6.fr (Postfix, from userid 20331) id 581B0107F7; Tue, 2 Sep 2025 16:28:40 +0200 (CEST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 20ff8d26-8809-11f0-8dd7-1b34d833f44b Date: Tue, 2 Sep 2025 16:28:40 +0200 From: Manuel Bouyer To: Jan Beulich Cc: Andrew Cooper , xen-devel@lists.xenproject.org, Juergen Gross Subject: Re: issue with dom0_pvh on Xen 4.20 Message-ID: References: <68988b80-f642-4fcf-a624-49ad9fdd685c@citrix.com> <957429d8-ec8c-4327-b8fc-71fe9ddb2d33@suse.com> <2ad255ea-6c5e-4e9a-a821-db7449432399@suse.com> <5953e9aa-4b56-4112-b952-7b4ff0ca2a62@suse.com> <49551fca-5059-4ca4-b551-d282d6099e36@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49551fca-5059-4ca4-b551-d282d6099e36@suse.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.4 (isis.lip6.fr [132.227.60.2]); Tue, 02 Sep 2025 16:28:42 +0200 (CEST) X-Scanned-By: MIMEDefang 3.4.1 on 132.227.60.2 On Tue, Sep 02, 2025 at 04:23:28PM +0200, Jan Beulich wrote: > >>> kernel symbol table. That seems to be no longer true with Xen 4.20 and a > >>> PVH dom0 (but probably still true in all other cases). > >>> > >>> I can deal with that, but with the new layout how do I get the end of the > >>> symbol table ? > >> > >> You'll need to handle that internally, I expect, perhaps from properties of > >> your (ELF) binary. > > > > But I don't have access to the ELF headers from the kernel binary (nor do I > > know which kernel was booted). > > > > Hum, maybe a I can hardcode this info in some const of the binary with a > > ld trick ? > > For the symbol table to be loaded, it needs to live in some loadable section. > You should be able to mark that section's end (or the end of the symbol > table in the section, in case there's more stuff there) with a symbol in the > linker script (which I assume you use). If you used the GNU toolchain, you > could also consider using the assembler's .startof. / .sizeof. operators > (producing symbols that the linker then recognizes and resolves accordingly). > > Or wait - are you perhaps using the thing we call "bsd_symtab" in our libelf? yes, that's it. I'm looking at how it's loaded right now > Then, as per the scheme in elf_load_bsdsyms(), can't you find the start of > the ELF header from the end of your kernel? At least that's how I understand > it's supposed to work. I can, but at this point I can't easily call C code, and doing it in assembly doesn't look easy :( -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --