On 09/09/2020 17:00, Jan Beulich wrote:
> On 08.09.2020 17:41, Igor Druzhinin wrote:
>> Guest kernel does need to know in some cases where the tables are located
>> to treat these regions properly. One example is kexec process where
>> the first kernel needs to pass ACPI region locations to the second
>> kernel which is now a requirement in Linux after 02a3e3cdb7f12 ("x86/boot:
>> Parse SRAT table and count immovable memory regions") in order for kexec
>> transition to actually work.
>>
>> That commit introduced accesses to XSDT and SRAT while the second kernel
>> is still using kexec transition tables. The transition tables do not have
>> e820 "reserved" regions mapped where those tables are located currently
>> in a Xen guest. Instead "ACPI data" regions are mapped with the transition
>> tables that was introduced by the following commit 6bbeb276b7 ("x86/kexec:
>> Add the EFI system tables and ACPI tables to the ident map").
>>
>> Reserve 1MB (out of 16MB currently available) right after ACPI info page for
>> ACPI tables exclusively but populate this region on demand and only indicate
>> populated memory as "ACPI data" since according to ACPI spec that memory is
>> reclaimable by the guest if necessary. That is close to how we treat
>> the same ACPI data in PVH guests. 1MB should be enough for now but could be
>> later extended if required.
>>
>> Signed-off-by: Igor Druzhinin <igor.druzhi...@citrix.com>
>
> After committing this I'm now somewhat uncertain whether to queue this
> for the stable trees. Does either of you (or anyone else) have any clear
> opinion either way?
That depends on what the upstream support statement was for kexec/kdump for
stable
releases.Note that newer guests (e.g. Ubuntu 20.04) won't able to enter kdump
kernel without that.
In Citrix we'd be glad if it reaches at least stable-4.13 as we're backporting
this
functionality to our 4.13 based LTSR.
Igor
