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

[Bertrand Marquis <Bertrand.Marquis@xxxxxxx>]

Hi Julien,

> On 18 Aug 2022, at 08:57, Julien Grall <julien@xxxxxxx> 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.

I think the problem was that EFI also includes some functions and to have a 
proper EFI stub we would need to support those (console, mapping, disk access).
Maybe this is something we could discuss but that would require to have some 
kind of binary providing those services that we put in EL1 or at least a stub 
calling Xen for those functions.
One other solution of course is to run uboot and boot linux from this.

> 
>> 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?
> 
> IOW, would Linux be unusable if we don't create MEMRESERVE?

No it works perfectly fine.
There are some warnings and as pointed out later kexec is not useable (but is 
not supported anyway).

> 
>> 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.
> 
> 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.

As we do support kexec on arm right now I think the current status should be 
kept.
Those questions would need answering if we support kexec one day.

Cheers
Bertrand

> 
> Cheers,
> 
> -- 
> Julien Grall