On Thu, Oct 06, 2022 at 10:58:43AM +0200, Jan Beulich wrote: > On 06.10.2022 10:53, Roger Pau Monné wrote: > > On Thu, Oct 06, 2022 at 10:40:56AM +0200, Jan Beulich wrote: > >> efi_init_memory() in both relevant places is treating EFI_MEMORY_RUNTIME > >> higher priority than the type of the range. To avoid accessing memory at > >> runtime which was re-used for other purposes, make > >> efi_arch_process_memory_map() follow suit. While on x86 in theory the > >> same would apply to EfiACPIReclaimMemory, we don't actually "reclaim" > >> E820_ACPI memory there (and it would be a bug if the Dom0 kernel tried > >> to do so, bypassing Xen's memory management), hence that type's handling > > > > Strictly speaking I don't think dom0 needs to bypass Xen's memory > > management, just overwriting the page would be bad enough for runtime > > services to not work correctly I would think. > > Then how about: > > "While on x86 in theory the same would apply to EfiACPIReclaimMemory, we don't > actually "reclaim" or clobber E820_ACPI memory there (and it would be a bug > if > the Dom0 kernel tried to reclaim the range, bypassing Xen's memory > management, > plus it would be at least bogus if it clobbered that space), hence that > type's > handling can be left alone." > > I didn't think the clobbering aspect needed pointing out, as the same applies > to all other memory which Dom0 is able to access beyond its actual allocation.
I think it makes it clear that just clobbering it from dom0 could cause issues to runtime services. I guess it can be extrapolated that clobbering is also bad if reclaiming is. Thanks, Roger.
