Re: [PATCH v3 3/4] Add a new hypercall to get the ESRT

[Demi Marie Obenour <demi@xxxxxxxxxxxxxxxxxxxxxx>]

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.

Is using ebmalloc() to allocate a copy of the ESRT a reasonable option?
Is it possible that the ESRT is so large that this causes boot to fail?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

Attachment: signature.asc
Description: PGP signature