Re: [PATCH v2] x86/public: move XEN_ACPI_ in a new header

[Jan Beulich <jbeulich@xxxxxxxx>]

On 30.08.2022 02:52, Henry Wang wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@xxxxxxxx>
>> Subject: Re: [PATCH v2] x86/public: move XEN_ACPI_ in a new header
>>
>> On 25.08.2022 11:48, Bertrand Marquis wrote:
>>> When Xen is compiled for x86 on an arm machine, libacpi build is failing
>>> due to a wrong include path:
>>> - arch-x86/xen.h includes xen.h
>>> - xen.h includes arch-arm.h (as __i386__ and __x86_64__ are not defined
>>> but arm ones are).
>>>
>>> To solve this issue move XEN_ACPI_ definitions in a new header
>>> guest-acpi.h that can be included cleanly by mk_dsdt.c.
>>> Inside this header, only protect the definitions using ifdef
>>> __XEN_TOOLS__ as the defines are not used anywhere in the hypervisor
>> and
>>> are not expected to be.
>>>
>>> Previous users needing any of the XEN_ACPI_ definitions will now need to
>>> include arch-x86/guest-acpi.h instead of arch-x86/xen.h
>>>
>>> Fixes: d6ac8e22c7c5 ("acpi/x86: define ACPI IO registers for PVH guests")
>>> Signed-off-by: Bertrand Marquis <bertrand.marquis@xxxxxxx>
>>
>> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
>>
>>> For the release manager:
>>> - risk: very low, the definitions moved are only used in mk_dsdt and
>>> external users would just have to include the new header.
>>> - advantage: we can now compile xen for x86 on arm build machines
>>
>> I'll give it a little for Henry to possibly release-ack this, but since
>> strictly speaking this is a bug fix, I think it could also go in without
>> (as long as not actually objected to, of course).
> 
> Thanks for informing. Yeah definitely no problem from my side, so:
> 
> Acked-by: Henry Wang <Henry.Wang@xxxxxxx> # For the 4.17 release

I've translated this to Release-acked-by: (as was used for earlier releases).

Jan