On Tue, Oct 04, 2022 at 10:22:13AM +0200, Jan Beulich wrote: > On 01.10.2022 02:30, Demi Marie Obenour wrote: > > On Fri, Sep 30, 2022 at 08:27:09PM +0200, Ard Biesheuvel wrote: > >> On Fri, 30 Sept 2022 at 19:12, Demi Marie Obenour wrote: > >>> On Fri, Sep 30, 2022 at 06:30:57PM +0200, Ard Biesheuvel wrote: > >>>> I know very little about Xen, but based on the context you provided in > >>>> this thread, I'd say that the best approach from the Xen side is to > >>>> convert all EfiBootServicesData regions that have configuration tables > >>>> pointing into them into EfiAcpiReclaimMemory. > >>> > >>> Should Xen convert the entire region, or should it try to reserve only > >>> the memory it needs? The latter would require it to parse the > >>> configuration tables. Is there a list of configuration tables that can > >>> legitimately be in EfiBootServicesData regions? > >>> > >> > >> Not really, no. So you would have to convert the entire region > >> /unless/ Xen knows the GUID, and therefore knows how to derive the > >> size of the table, allowing it to reserve memory more conservatively. > >> However, I doubt whether this is worth it: splitting entries implies > >> rewriting the memory map, which is a thing I'd rather avoid if I were > >> in your shoes. > > > > I actually wonder if Xen needs to reserve *all* of EfiBootServicesData. > > The reason is that some (probably buggy) firmware may store ACPI tables > > there, and Xen does not have an ACPI implementation. > > We already have the -mapbs option as a workaround in such situations. The problem is that there is no way for the user to know when it is needed. One option would be for dom0 to print a warning in the kernel log if it needs to ignore a table due to it being in EfiBootServicesData. > > From my > > perspective, a much safer approach would be to pass all of > > EfiBootServicesData memory directly to dom0, and have dom0 give Xen back > > what it doesn’t wind up using. That allows dom0’s memory reservation > > code to work properly, which it currently does not. > > As said already on a different thread: Giving memory to domains (incl > Dom0) isn't related to their original memory type (neither EFI's nor > E820's); the needed memory is taken from the general page allocator > (with one exception for initrd, to avoid unnecessary copying around of > data). Hence what you propose would end up as an (imo) awful hack in > Xen. I also don't see how this relates to "dom0’s memory reservation > code", but I'm sure you can clarify that for me. Linux has a function called efi_mem_reserve() that is used to reserve EfiBootServicesData memory that contains e.g. EFI configuration tables. This function does not work under Xen because Xen could have already clobbered the memory. efi_mem_reserve() not working is the whole reason for this thread, as it prevents EFI tables that are in EfiBootServicesData from being used under Xen. A much nicer approach would be for Xen to reserve boot services memory unconditionally, but provide a hypercall that dom0 could used to free the parts of EfiBootServicesData memory that are no longer needed. This would allow efi_mem_reserve() to work normally. -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab
Attachment:
signature.asc
Description: PGP signature
