On 18.08.2020 14:47, Roger Pau Monné wrote: > On Tue, Aug 18, 2020 at 02:01:35PM +0200, Marek Marczykowski-Górecki wrote: >> On Mon, Aug 17, 2020 at 11:00:13AM +0200, Roger Pau Monné wrote: >>> On Sun, Aug 16, 2020 at 02:19:49AM +0200, Marek Marczykowski-Górecki wrote: >>>> In case of Xen PV dom0, Xen passes along info about system tables (see >>>> arch/x86/xen/efi.c), but not the memory map from EFI. >>> >>> I think that's because the memory map returned by >>> XENMEM_machine_memory_map is in e820 form, and doesn't contain the >>> required information about the EFI regions due to the translation done >>> by efi_arch_process_memory_map in Xen? >> >> Yes, I think so. >> >>>> This makes sense >>>> as it is Xen responsible for managing physical memory address space. >>>> In this case, it doesn't make sense to condition using ESRT table on >>>> availability of EFI memory map, as it isn't Linux kernel responsible for >>>> it. >>> >>> PV dom0 is kind of special in that regard as it can create mappings to >>> (almost) any MMIO regions, and hence can change it's memory map >>> substantially. >> >> Do you mean PV dom0 should receive full EFI memory map? Jan already >> objected this as it would be a layering violation. > > dom0 is already capable of getting the native e820 memory map using > XENMEM_machine_memory_map, I'm not sure why allowing to return the > memory map in EFI form would be any different (or a layering > violation in the PV dom0 case). The EFI memory map exposes more information than the E820 one, and this extra information should remain private to Xen if at all possible. I actually think that exposing the raw E820 map was a layering violation, too. Instead hypercalls should have been added for the specific legitimate uses that Dom0 may have for the memmap. Jan
