Re: [PATCH v2] hvmloader: flip "ACPI data" to "ACPI NVS" type for ACPI table region

[Jan Beulich <jbeulich@xxxxxxxx>]

On 16.10.2020 15:48, Igor Druzhinin wrote:
> On 16/10/2020 14:34, Sander Eikelenboom wrote:
>> On 16/10/2020 08:34, Jan Beulich wrote:
>>> On 16.10.2020 02:39, Igor Druzhinin wrote:
>>>> ACPI specification contains statements describing memory marked with 
>>>> regular
>>>> "ACPI data" type as reclaimable by the guest. Although the guest shouldn't
>>>> really do it if it wants kexec or similar functionality to work, there
>>>> could still be ambiguities in treating these regions as potentially regular
>>>> RAM.
>>>>
>>>> One such example is SeaBIOS which currently reports "ACPI data" regions as
>>>> RAM to the guest in its e801 call. Which it might have the right to do as 
>>>> any
>>>> user of this is expected to be ACPI unaware. But a QEMU bootloader later 
>>>> seems
>>>> to ignore that fact and is instead using e801 to find a place for initrd 
>>>> which
>>>> causes the tables to be erased. While arguably QEMU bootloader or SeaBIOS 
>>>> need
>>>> to be fixed / improved here, that is just one example of the potential 
>>>> problems
>>>> from using a reclaimable memory type.
>>>>
>>>> Flip the type to "ACPI NVS" which doesn't have this ambiguity in it and is
>>>> described by the spec as non-reclaimable (so cannot ever be treated like 
>>>> RAM).
>>>>
>>>> Signed-off-by: Igor Druzhinin <igor.druzhinin@xxxxxxxxxx>
>>>
>>> Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
>>>
>>>
>>
>> I don't see any stable and or fixes tags, but I assume this will go to
>> the stable trees (which have (a backport of)
>> 8efa46516c5f4cf185c8df179812c185d3c27eb6 in their staging branches) ?

Yes, I intend to queue this up, as I did the backport of the
earlier one.

> Yes, this should go to the stable branches as well. I don't usually see Fixes:
> tag being used on xen-devel (not sure if it's intentional or simply not
> customary).

Go look again - there's an increasing amount of use of it.

> It's also questionable whether it's a fix or a workaround for an
> issue with compatibility.

Indeed - it is for this reason that I didn't ask for such a
tag to be added here.

Jan