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

[Leo Yan <leo.yan@xxxxxxxxxx>]

Hi Julien,

On Thu, Aug 18, 2022 at 08:57:20AM +0100, Julien Grall wrote:
> Hi Leo,
> 
> On 18/08/2022 08: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,
> 
> I agree that using Linux EFI stub will require more effort. I would also
> need to go through the mailing list archives (or maybe Stefano remember?) to
> understand why we decided against using the EFI stub.

Yeah, seems to me using the EFI stub is the right thing to do.

I read Xen code and found Xen doesn't provide boot time callback, this
is the main reason blocked me to move forward to that way.

> > so we need to
> > maintain this structure in Xen as well.
> 
> I have looked at the commit message. IIUC, if this table is not created then
> Kexec will not work. Is there anything else that would not work?

No, AFAIK, kexec/kdump is the only customer to use the persistent
reserved memory in the Linux kernel.

I personally think this will pontentially impact other kernel
debugging modules, like ramoops, it also needs to use persistent
reserved memory when rebooting the kernel.  But now kernel code
doesn't add ramoops memory region into EFI MEMRESERVE table.

> IOW, would Linux be unusable if we don't create MEMRESERVE?

If we don't create EFI MEMRESERVE, kernel still can boot up
successfully, though it cannot add pages into the reserved memory
table and reports oops.

Without EFI MEMRESERVE, the reserved memory table cannot be passed from
the primary kernel to the secondary kernel, this is why it's important
for debugging tools.

> > This structure eventually will not change frequently, so I assume
> > later we will have little effort for maintainence it
>
> The problem is not really "maintainance" here. It is more that if Linux is
> updating the structure in a non-backward compatible way, then new
> version of Linux would not boot on older Xen.
> 
> We would have similar probable with new Xen booting older Xen because the
> hypervisor doesn't know (and should not need to know) which OS is used.

Fair point.

> In the nutshells, Xen should only use stable interface. If MEMRESERVE is
> really necessary then we should either switch to the Linux EFI stub or
> standardize MEMRESERVE.

Yeah, here I really need your (and other maintainers) opinions.  Seems
to me, support Linux EFI stub would be the best thing to do, to be
honest, this is a task which is out of my capability :)

Current approach in this patch is not perfect, it lets things to work.
So please let me know the conclusion from your side.

Thanks,
Leo