From: Demi Marie Obenour <demi@invisiblethingslab.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Ard Biesheuval <ardb@kernel.org>,
Xen developer discussion <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v2] Use EfiACPIReclaimMemory for ESRT
Date: Tue, 11 Oct 2022 12:52:22 -0400 [thread overview]
Message-ID: <Y0WfXttQHfFle2R7@itl-email> (raw)
In-Reply-To: <9c1731eb-44f6-41c6-cb4e-51abf0c50052@suse.com>
[-- Attachment #1: Type: text/plain, Size: 1584 bytes --]
On Tue, Oct 11, 2022 at 11:59:01AM +0200, Jan Beulich wrote:
> On 11.10.2022 05:42, Demi Marie Obenour wrote:
> > A previous patch tried to get Linux to use the ESRT under Xen if it is
> > in memory of type EfiRuntimeServicesData. However, this turns out to be
> > a bad idea. Ard Biesheuvel pointed out that EfiRuntimeServices* memory
> > winds up fragmenting both the EFI page tables and the direct map,
>
> Can this statement please be made describe Xen, not Linux? Aiui at least
> the directmap aspect doesn't apply to Xen.
Should it apply to Xen? My understanding is that Ard’s statements
regarding mismatched attributes refer to any kernel, not just Linux.
You would be in a better position to judge that, though.
> > and
> > that EfiACPIReclaimMemory is a much better choice for this purpose.
>
> I think the "better" wants explaining here, without requiring people to
> follow ...
Something like, “EfiACPIReclaimMemory is the correct type for
configuration tables that are only used by the OS.”?
> > Link: https://lists.xenproject.org/archives/html/xen-devel/2022-09/msg01365.html
>
> ... this link. Since the code change looks okay to me, I'd be okay to
> replace the description with an adjusted one while committing.
That is fine with me.
> However,
> if you expect the change to go into 4.17, you will want to resubmit
> with Henry on Cc:, so he can consider giving the now necessary release-
> ack.
Will do, with your updated commit message.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2022-10-11 16:53 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-11 3:42 [PATCH v2] Use EfiACPIReclaimMemory for ESRT Demi Marie Obenour
2022-12-07 22:42 ` [PATCH v3] " Demi Marie Obenour
2022-12-06 23:27 ` [PATCH v2] " Demi Marie Obenour
2022-10-11 9:59 ` Jan Beulich
2022-10-11 16:52 ` Demi Marie Obenour [this message]
2022-10-12 6:19 ` Jan Beulich
2022-12-07 2:44 ` Henry Wang
2022-12-07 2:52 ` Demi Marie Obenour
2022-12-07 10:11 ` Jan Beulich
2022-12-07 22:37 ` Demi Marie Obenour
2022-12-08 8:49 ` [PATCH v3] " Jan Beulich
2022-12-08 8:53 ` Henry Wang
2022-12-08 18:05 ` Julien Grall
2022-12-09 7:37 ` Henry Wang
2022-12-09 13:15 ` Demi Marie Obenour
2022-12-09 14:54 ` Henry Wang
2022-12-09 16:48 ` Demi Marie Obenour
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y0WfXttQHfFle2R7@itl-email \
--to=demi@invisiblethingslab.com \
--cc=ardb@kernel.org \
--cc=jbeulich@suse.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.