All of
 help / color / mirror / Atom feed
From: Jan Beulich <>
To: Demi Marie Obenour <>
Cc: "Andrew Cooper" <>,
	"George Dunlap" <>,
	"Julien Grall" <>,
	"Stefano Stabellini" <>,
	"Wei Liu" <>,,
	"Marek Marczykowski-Górecki" <>
Subject: Re: [PATCH v3 3/4] Add a new hypercall to get the ESRT
Date: Thu, 28 Apr 2022 08:47:49 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <YmmUtiBkhEYvXHUB@itl-email>

On 27.04.2022 21:08, Demi Marie Obenour wrote:
> On Wed, Apr 27, 2022 at 10:56:34AM +0200, Jan Beulich wrote:
>> On 19.04.2022 17:49, Demi Marie Obenour wrote:
>>> This hypercall can be used to get the ESRT from the hypervisor.  It
>>> returning successfully also indicates that Xen has reserved the ESRT and
>>> it can safely be parsed by dom0.
>> I'm not convinced of the need, and I view such an addition as inconsistent
>> with the original intentions. The pointer comes from the config table,
>> which Dom0 already has access to. All a Dom0 kernel may need to know in
>> addition is whether the range was properly reserved. This could be achieved
>> by splitting the EFI memory map entry in patch 2, instead of only splitting
>> the E820 derivation, as then XEN_FW_EFI_MEM_INFO can be used to find out
>> the range's type. Another way to find out would be for Dom0 to attempt to
>> map this area as MMIO, after first checking that no part of the range is in
>> its own memory allocation. This 2nd approach may, however, not really be
>> suitable for PVH Dom0, I think.
> On further thought, I think the hypercall approach is actually better
> than reserving the ESRT.  I really do not want XEN_FW_EFI_MEM_INFO to
> return anything other than the actual firmware-provided memory
> information, and the current approach seems to require more and more
> special-casing of the ESRT, not to mention potentially wasting memory
> and splitting a potentially large memory region into two smaller ones.
> By copying the entire ESRT into memory owned by Xen, the logic becomes
> significantly simpler on both the Xen and dom0 sides.

I actually did consider the option of making a private copy when you did
send the initial version of this, but I'm not convinced this simplifies
things from a kernel perspective: They'd now need to discover the table
by some entirely different means. In Linux at least such divergence
"just for Xen" hasn't been liked in the past.

There's also the question of how to propagate the information across
kexec. But I guess that question exists even outside of Xen, with the
area living in memory which the OS is expected to recycle.

> Is using ebmalloc() to allocate a copy of the ESRT a reasonable option?

I'd suggest to try hard to avoid ebmalloc(). It ought to be possible to
make the copy before ExitBootServices(), via normal EFI allocation. If
replacing a pointer in the config table was okay(ish), this could even
be utilized to overcome the kexec problem.

> Is it possible that the ESRT is so large that this causes boot to fail?

I don't know - that's a question firmware folks would need to answer.


  reply	other threads:[~2022-04-28  6:48 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-19 15:32 [PATCH v3 0/4] EFI System Resource Table support Demi Marie Obenour
2022-04-19 15:40 ` [PATCH v3 1/4] Grab the EFI System Resource Table and check it Demi Marie Obenour
2022-04-27  8:23   ` Jan Beulich
2022-04-27  8:42   ` Jan Beulich
2022-05-30  8:47     ` Henry Wang
2022-05-30 18:22       ` Demi Marie Obenour
2022-04-27  9:00   ` Jan Beulich
2022-04-19 15:40 ` [PATCH v3 2/4] Add a dedicated memory region for the ESRT Demi Marie Obenour
2022-04-27  8:40   ` Jan Beulich
2022-04-19 15:49 ` [PATCH v3 3/4] Add a new hypercall to get " Demi Marie Obenour
2022-04-27  8:56   ` Jan Beulich
2022-04-27 19:08     ` Demi Marie Obenour
2022-04-28  6:47       ` Jan Beulich [this message]
2022-04-28 22:54         ` Demi Marie Obenour
2022-04-29  8:40           ` Jan Beulich
2022-04-29 17:06             ` Demi Marie Obenour
2022-05-02  6:24               ` Jan Beulich
2022-05-02  7:11                 ` Demi Marie Obenour
2022-05-02  7:37                   ` Jan Beulich
2022-05-02  7:42                     ` Demi Marie Obenour
2022-04-19 15:51 ` [PATCH v3 4/4] Add emacs file-local variables 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \

* 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.