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 AB9D4106F311 for ; Thu, 26 Mar 2026 10:00:45 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.1263615.1555491 (Exim 4.92) (envelope-from ) id 1w5hVs-0007gJ-CM; Thu, 26 Mar 2026 10:00:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1263615.1555491; Thu, 26 Mar 2026 10:00:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w5hVs-0007gC-9F; Thu, 26 Mar 2026 10:00:28 +0000 Received: by outflank-mailman (input) for mailman id 1263615; Thu, 26 Mar 2026 10:00:26 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w5hVq-0007fz-BP for xen-devel@lists.xenproject.org; Thu, 26 Mar 2026 10:00:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1w5hVp-00HXcd-N5 for xen-devel@lists.xenproject.org; Thu, 26 Mar 2026 11:00:25 +0100 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 69c503b5-5cb7-0a2a0a5109dd-0a2a4509e056-22 for ; Thu, 26 Mar 2026 11:00:25 +0100 Received: from [103.168.172.144] (helo=fout-a1-smtp.messagingengine.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.55.2) (envelope-from ) id 69c503b8-e484-0a2a45090019-67a8ac90df93-3 for ; Thu, 26 Mar 2026 11:00:25 +0100 Received: from phl-compute-12.internal (phl-compute-12.internal [10.202.2.52]) by mailfout.phl.internal (Postfix) with ESMTP id 3C58CEC021F; Thu, 26 Mar 2026 06:00:24 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-12.internal (MEProxy); Thu, 26 Mar 2026 06:00:24 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 26 Mar 2026 06:00:22 -0400 (EDT) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=fm1 header.d=invisiblethingslab.com header.i="@invisiblethingslab.com" header.h="Cc:Content-Type:Date:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To"; dkim=pass header.s=fm1 header.d=messagingengine.com header.i="@messagingengine.com" header.h="Cc:Content-Type:Date:Feedback-ID:From:In-Reply-To:Message-ID:MIME-Version:References:Subject:To:X-ME-Proxy:X-ME-Sender" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= invisiblethingslab.com; h=cc:cc:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1774519224; x=1774605624; bh=G+BqfjFs7RUwpGnKgULXJ4doTq7FLor4WHwBKTxbRiM=; b= dVsQm/ZmE047HeCY2PFAJ2HggCm+e1upz0C+OvwIuQosrqmhAenx/caKbzsyOSrH /iLEuzsrx/szXmHkpl7gRTMt7zOHM3qjmdcul5jbs5eNoFLITlCucJAHqFx25YPT AzHffUOaaC9hEUlXAkA+9PZ8eAePZRNdEJm28u2+DOONlvX+zHg5I+RcGp9sskYK X21P64MXZX1uwyaXZieSuFiu5wS+gQpmQ5wAjEtBDs8NFwtZ9kCr1Ag1fEUjtBF/ VtnxbnaXYpSnNqaXawK/1SWyvvCDij41aYJL5EK1ESqkjrru422mMl1UlXI2NQu3 5uLMVyoRc/U7bBsoy8EdxA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1774519224; x=1774605624; bh=G+BqfjFs7RUwpGnKgULXJ4doTq7FLor4WHw BKTxbRiM=; b=uI8MHRU3+8oWU4E+AUKsfxbhOEEQwdZJP05Yo+e0IOF5vIr3ogv 978yCaYMnpQzcaHR27qEzJbKYo99Mvox0k+GZPorefeagW2mtAi6i7OJrVC/Viu8 k79BvJ4mUYOxXI4+mMxNRdK+eEyduDRCZCEatBnB+d822PXH2tmjr3X+PUhSvLP4 2IlQIcpf1UY/Ne0LxoDgGvYgkzE+TeZIDk/r0V3CFCtijVCQrbKNRNt+he+qlqYO 3n3/hjmbJMPyMbl0zEfzINp//xq1fM7aqL0cFjMGbQo9Z27LglgyX6KOxxYnAw56 zu6PtsJRY1Je0roEdjXWjXI8X+0X2Vbt/uQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgdefvdejtdekucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvfevuffkfhggtggujgesghdtreertddtjeenucfhrhhomhepofgrrhgvkhcu ofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvih hsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepgfduleet feevhfefheeiteeliefhjefhleduveetteekveettddvgeeuteefjedunecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehi nhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohepjedpmh houggvpehsmhhtphhouhhtpdhrtghpthhtohepjhgsvghulhhitghhsehsuhhsvgdrtgho mhdprhgtphhtthhopehsohhumhihrghjhihothhishgrrhhkrghrvdefsehgmhgrihhlrd gtohhmpdhrtghpthhtoheprghnughrvgifrdgtohhophgvrhefsegtihhtrhhigidrtgho mhdprhgtphhtthhopeguphhsmhhithhhsegrphgvrhhtuhhsshholhhuthhiohhnshdrtg homhdprhgtphhtthhopehrohhgvghrrdhprghusegtihhtrhhigidrtghomhdprhgtphht thhopehsrghrkhgrrhhsohhumhihrghjhihothhivdefsehgmhgrihhlrdgtohhmpdhrtg hpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhg X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Thu, 26 Mar 2026 11:00:21 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Jan Beulich Cc: Soumyajyotii Ssarkar , Andrew Cooper , "Daniel P . Smith" , Roger Pau =?utf-8?B?TW9ubsOp?= , sarkarsoumyajyoti23@gmail.com, xen-devel@lists.xenproject.org Subject: Re: [PATCH v5 2/3] x86/acpi: Integrate BGRT preservation with status reporting Message-ID: References: <20260324123312.11076-1-soumyajyotisarkar23@gmail.com> <20260324123312.11076-3-soumyajyotisarkar23@gmail.com> <751e1d3e-d95a-4129-8baa-450a53d15efa@suse.com> <5e121a98-fcd1-4d20-aa6c-a02af7f7eef4@suse.com> <11c0a822-afc7-4e3d-b6f5-ef8e32bd2f0f@suse.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dx68d3efQTV8AtnN" Content-Disposition: inline In-Reply-To: <11c0a822-afc7-4e3d-b6f5-ef8e32bd2f0f@suse.com> X-purgate-ID: tlsNG-bad1c0/1774519225-5BEA2A73-C5489B02/0/0 X-purgate-type: clean X-purgate-size: 5411 --dx68d3efQTV8AtnN Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Mar 2026 11:00:21 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Jan Beulich Cc: Soumyajyotii Ssarkar , Andrew Cooper , "Daniel P . Smith" , Roger Pau =?utf-8?B?TW9ubsOp?= , sarkarsoumyajyoti23@gmail.com, xen-devel@lists.xenproject.org Subject: Re: [PATCH v5 2/3] x86/acpi: Integrate BGRT preservation with status reporting On Thu, Mar 26, 2026 at 09:45:43AM +0100, Jan Beulich wrote: > On 25.03.2026 16:57, Marek Marczykowski-G=C3=B3recki wrote: > > On Wed, Mar 25, 2026 at 04:44:15PM +0100, Jan Beulich wrote: > >> On 25.03.2026 16:32, Marek Marczykowski-G=C3=B3recki wrote: > >>> On Wed, Mar 25, 2026 at 04:16:25PM +0100, Jan Beulich wrote: > >>>> On 24.03.2026 13:33, Soumyajyotii Ssarkar wrote: > >>>>> @@ -327,6 +328,11 @@ static int __init cf_check acpi_parse_hpet(str= uct acpi_table_header *table) > >>>>> return 0; > >>>>> } > >>>>> > >>>>> +/* > >>>>> + * Invalidate BGRT if image is in conventional RAM (preservation f= ailed). > >>>>> + * If preservation succeeded, image is in EfiACPIReclaimMemory, wh= ich > >>>>> + * won't match RAM_TYPE_CONVENTIONAL check, so table remains valid. > >>>>> + */ > >>>>> static int __init cf_check acpi_invalidate_bgrt(struct acpi_table_= header *table) > >>>>> { > >>>>> struct acpi_table_bgrt *bgrt_tbl =3D > >>>>> @@ -754,5 +760,7 @@ int __init acpi_boot_init(void) > >>>>> > >>>>> acpi_table_parse(ACPI_SIG_BGRT, acpi_invalidate_bgrt); > >>>>> > >>>>> + efi_bgrt_status_info(); > >>>>> + > >>>>> return 0; > >>>>> } > >>>> > >>>> Does this really need doing from here? If you called it ... > >>>> > >>>>> --- a/xen/common/efi/boot.c > >>>>> +++ b/xen/common/efi/boot.c > >>>>> @@ -1911,6 +1911,22 @@ static bool __init cf_check rt_range_valid(u= nsigned long smfn, unsigned long emf > >>>>> return true; > >>>>> } > >>>>> > >>>>> +void __init efi_bgrt_status_info(void) > >>>>> +{ > >>>>> + if ( !efi_enabled(EFI_BOOT) ) > >>>>> + return; > >>>>> + > >>>>> + if ( bgrt_info.preserved ) > >>>>> + { > >>>>> + printk(XENLOG_INFO "EFI: BGRT image preserved: %lu KB\n", > >>>>> + bgrt_info.size / 1024); > >>>>> + printk(XENLOG_INFO "EFI: BGRT relocated from %p to %p\n", > >>>>> + bgrt_info.old_addr, bgrt_info.new_addr); > >>>>> + } > >>>>> + else if ( bgrt_info.failure_reason[0] ) > >>>>> + printk(XENLOG_WARNING "EFI: BGRT preservation failed: %s\n= ", > >>>>> + bgrt_info.failure_reason); > >>>>> +} > >>>>> > >>>>> void __init efi_init_memory(void) > >>>>> { > >>>> > >>>> ... out of this function, it could be static and no stub (misplaced = in > >>>> the earlier patch) would be needed either. > >>> > >>> It was here before, and I complained about it, because it printed the > >>> invalidation reason way later than the actual invalidation. > >> > >> Sadly now I complain about this call out of acpi_boot_init(). What's w= rong > >> with logging the BGRT stuff together with the memory map? > >=20 > > If you try to diagnose what went wrong with BGRT, that's not very > > intuitive to find - for example on my system it's 32 messages later. >=20 > Simply grep the log for BGRT? >=20 > > It's even worse if system happens to crash between those two points. >=20 > Hmm, perhaps. >=20 > > IMO it makes sense to log reason for BGRT invalidation together with > > the actual invalidation (message). I would be okay with moving it before > > the actual invalidation, but I don't think there is a place like this in > > xen/common/efi/boot.c (at a point where normal printk can be used alrea= dy). >=20 > I guess what you really mean is printk() output actually going out (i.e. > not just to the ring buffer). >=20 > While still requiring the function to be extern (and there to be a stub), > how about adding the call much earlier in __start_xen, in here: >=20 > else if ( efi_enabled(EFI_BOOT) ) > memmap_type =3D "EFI"; >=20 > ? Or alternatively anywhere between setting system_state to SYS_STATE_boot > and the call to acpi_boot_init()? Or re-using the other EFI_BOOT check th= at > we have in __start_xen()? Yes, either of those would be okay for me. I just want to avoid potentially loosing important piece of information that Xen already has at the point of invalidating BGRT. --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --dx68d3efQTV8AtnN Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmnFA7UACgkQ24/THMrX 1yy/dAf/UKsDeaJ0wWwIYWflDcH97jvCoWbPaEgUsDgMdxN3xVMR1DUR57JJlllV TcOG9Av9DBpmgVaZTifd7opmRBQOwdw4hCaD0INkeyTgVZmh/VJa0IKBtoqc9ksO zp3BEdumZ1Ux2zuiPLeQZvWhWdRYD9YAV3BfZZl2yCFp3RpU8iJTuDPR8m3SAF29 T+qlyQmc2VnSpuwOYE/i2dCgIsyy4E146Vgz9+CLpw/SPLbLfceBI/aKYQMUs9v9 DQI/IdjkhdPozEplvdF4hUd91ijqgZuH3eai/5QBT6yfqzJ1oD/iCmmb75Aypcuj 5jLj28139jDzV5LvM6R1RfCHVg/WrQ== =s2dV -----END PGP SIGNATURE----- --dx68d3efQTV8AtnN--