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 DE144E936EC for ; Wed, 4 Oct 2023 22:38:02 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.612773.952854 (Exim 4.92) (envelope-from ) id 1qoAUs-0006wj-Lr; Wed, 04 Oct 2023 22:37:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 612773.952854; Wed, 04 Oct 2023 22:37:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qoAUs-0006wc-IG; Wed, 04 Oct 2023 22:37:38 +0000 Received: by outflank-mailman (input) for mailman id 612773; Wed, 04 Oct 2023 22:37:37 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qoAUr-0006wW-SW for xen-devel@lists.xenproject.org; Wed, 04 Oct 2023 22:37:37 +0000 Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.4]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 9d37b5e3-6306-11ee-98d3-6d05b1d4d9a1; Thu, 05 Oct 2023 00:37:36 +0200 (CEST) Received: from m5p.com (mailhost.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:f7]) by mailhost.m5p.com (8.17.1/8.15.2) with ESMTPS id 394Mb0AT001768 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 4 Oct 2023 18:37:06 -0400 (EDT) (envelope-from ehem@m5p.com) Received: (from ehem@localhost) by m5p.com (8.17.1/8.15.2/Submit) id 394Mb03i001767; Wed, 4 Oct 2023 15:37:00 -0700 (PDT) (envelope-from ehem) 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: 9d37b5e3-6306-11ee-98d3-6d05b1d4d9a1 Date: Wed, 4 Oct 2023 15:37:00 -0700 From: Elliott Mitchell To: Stefano Stabellini Cc: Julien Grall , Roger Pau =?iso-8859-1?Q?Monn=E9?= , xen-devel@lists.xenproject.org, Bertrand Marquis , Volodymyr Babchuk , Oleksandr Tyshchenko Subject: Re: Issue with shared information page on Xen/ARM 4.17 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Wed, Oct 04, 2023 at 03:21:04PM -0700, Stefano Stabellini wrote: > On Wed, 4 Oct 2023, Elliott Mitchell wrote: > > On Wed, Oct 04, 2023 at 03:39:16PM +0200, Roger Pau Monné wrote: > > > On Wed, Oct 04, 2023 at 02:03:43PM +0100, Julien Grall wrote: > > > > > > > > On 04/10/2023 13:53, Roger Pau Monné wrote: > > > > > > > > > > When using UEFI there's RAM that will always be in-use by the > > > > > firmware, as runtime services cannot be shut down, and hence the > > > > > firmware must already have a way to remove/reserve such region(s) on > > > > > the memory map. > > > > > > > > Can either you or Elliott confirm if EDK2 reserve the region? > > > > > > I will defer to Elliott to check for arm. I would be quite surprised > > > if it doesn't on x86, or else we would get a myriad of bug reports > > > about guests randomly crashing when using edk2. > > > > When I had originally looked I thought there was no problem as > > `OvmfPkg/XenPlatformPei/Xen.c`: > > CalibrateLapicTimer() > > MapSharedInfoPage(SharedInfo) > > ... > > UnmapXenPage(SharedInfo) > > > > Later using `find * -type f -print0 | xargs -0 grep -eXENMAPSPACE_shared_info` > > `OvmfPkg/XenBusDxe/XenBusDxe.c`: > > XenGetSharedInfoPage() > > // using reserved page because the page is not released when Linux is > > // starting because of the add_to_physmap. QEMU might try to access the > > // page, and fail because it have no right to do so (segv). > > > > Looks like this second case leaks the shared information page. > > Originally I thought there was no problem as I'd only found the first > > instance. Appears this second instance is the problem. > > I understand this second case is *not* unmapping the SharedInfo page, > but is it reserving it somehow? For instance marking it as reserved in > the EFI memory map? Notice the "//" comment which I carefully grabbed? // using reserved page because the page is not released when Linux is // starting because of the add_to_physmap. QEMU might try to access the // page, and fail because it have no right to do so (segv). So the page shouldn't be touched by anyone, but it does end up wasted. Likely ExitBootServices() should clear the mapping. -- (\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/) \BS ( | ehem+sigmsg@m5p.com PGP 87145445 | ) / \_CS\ | _____ -O #include O- _____ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445