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

[Leo Yan <leo.yan@xxxxxxxxxx>]

Hi Jan,

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.

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.  If rollback to use current method, then I am happy to
refine the patch with above idea.

Thanks,
Leo