Re: [PATCH] xen/arm: acpi: Support memory reserve configuration table

[Jan Beulich <jbeulich@xxxxxxxx>]

On 18.08.2022 10:46, Leo Yan wrote:
> On Thu, Aug 18, 2022 at 09:47:46AM +0200, Jan Beulich wrote:
>> On 18.08.2022 09:34, Leo Yan wrote:
>>> On Wed, Aug 17, 2022 at 03:17:53PM +0200, Jan Beulich wrote:
>>>> Furthermore - what if Linux decided to change their structure? Or
>>>> is there a guarantee that they won't? Generally such structures
>>>> belong in the public interface, guaranteeing forward compatibility
>>>> even if Linux decided to change / extend theirs (at which point
>>>> consuming code there would need to do translation, but maybe using
>>>> a Xen-defined struct [plus translation in Linux] right away would
>>>> be best).
>>>
>>> I saw Ard has helped to answer this question in his email.  As Ard
>>> said, the general way is to rely on Linux EFI stub to allocate the
>>> data structure for MEMRESERVE configuration table.
>>>
>>> Given Xen uses pseudo EFI booting (the ACPI table is passed via DT), in
>>> short term I don't think Xen can support Linux EFI stub, so we need to
>>> maintain this structure in Xen as well.
>>>
>>> This structure eventually will not change frequently, so I assume
>>> later we will have little effort for maintainence it.
>>
>> "Will not change frequently" isn't enough. Imo there needs to be a
>> public interface structure in Xen and translation code in Linux.
>> That's the only way the consuming code in Linux can remain (largely)
>> independent of changes to the structure in Linux (i.e. changes there
>> can be expected to be accompanied by updating of this code, perhaps
>> simply in order to keep things building).
> 
> Yes, actually Xen doesn't care about the structure definition for
> linux_efi_memreserve, it just allocates the table and finally used by
> Linux kernel.  So another way is we can simply allocate a bigger
> memory region (e.g. 64 bytes), which is sufficient than kernel's
> structure linux_efi_memreserve size (only 16 bytes), then we can
> initilize it as all zeros, and this can be helpful if later kernel
> extend the data structure.

Well, no, that's not how one would define a structure which can, in
a backwards compatible manner, be extended down the road.

> But this method is a bit arbitrary, this is why I did't write like this.
> As Julien said, I think the critical thing is to make a call to support
> EFI stub or not.

I don't see how this can be a reasonable option - we'd have to re-
implement an almost complete EFI (to cover everything one can do
via boot or runtime services). But I'm not an Arm maintainer, so my
view here is at best advisory.

Jan