Re: [xen-unstable-smoke test] 171511: regressions - FAIL

[Demi Marie Obenour <demi@xxxxxxxxxxxxxxxxxxxxxx>]

On Wed, Jul 06, 2022 at 09:02:47AM +0200, Jan Beulich wrote:
> On 06.07.2022 08:56, Demi Marie Obenour wrote:
> >>> commit 8d410ac2c178e1dd1001cadddbe9ca75a9738c95
> >>> Author: Demi Marie Obenour <demi@xxxxxxxxxxxxxxxxxxxxxx>
> >>> Date:   Tue Jul 5 13:10:46 2022 +0200
> >>>
> >>>     EFI: preserve the System Resource Table for dom0
> >>>     
> >>>     The EFI System Resource Table (ESRT) is necessary for fwupd to 
> >>> identify
> >>>     firmware updates to install.  According to the UEFI specification 
> >>> §23.4,
> >>>     the ESRT shall be stored in memory of type EfiBootServicesData.  
> >>> However,
> >>>     memory of type EfiBootServicesData is considered general-purpose 
> >>> memory
> >>>     by Xen, so the ESRT needs to be moved somewhere where Xen will not
> >>>     overwrite it.  Copy the ESRT to memory of type EfiRuntimeServicesData,
> >>>     which Xen will not reuse.  dom0 can use the ESRT if (and only if) it 
> >>> is
> >>>     in memory of type EfiRuntimeServicesData.
> >>>     
> >>>     Earlier versions of this patch reserved the memory in which the ESRT 
> >>> was
> >>>     located.  This created awkward alignment problems, and required either
> >>>     splitting the E820 table or wasting memory.  It also would have 
> >>> required
> >>>     a new platform op for dom0 to use to indicate if the ESRT is reserved.
> >>>     By copying the ESRT into EfiRuntimeServicesData memory, the E820 table
> >>>     does not need to be modified, and dom0 can just check the type of the
> >>>     memory region containing the ESRT.  The copy is only done if the ESRT 
> >>> is
> >>>     not already in EfiRuntimeServicesData memory, avoiding memory leaks on
> >>>     repeated kexec.
> >>>     
> >>>     See 
> >>> https://lore.kernel.org/xen-devel/20200818184018.GN1679@mail-itl/T/
> >>>     for details.
> >>>     
> >>>     Signed-off-by: Demi Marie Obenour <demi@xxxxxxxxxxxxxxxxxxxxxx>
> >>>     Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
> >>
> >> ... this is the most likely candidate, considering in the log all we
> >> see is:
> >>
> >> Xen 4.17-unstable (c/s Mon Jun 27 15:15:39 2022 +0200 
> >> git:61ff273322-dirty) EFI loader
> >> Jul  5 23:09:15.692859 Using configuration file 'xen.cfg'
> >> Jul  5 23:09:15.704878 vmlinuz: 0x00000083fb1ac000-0x00000083fc880a00
> >> Jul  5 23:09:15.704931 initrd.gz: 0x00000083f94b7000-0x00000083fb1ab6e8
> >> Jul  5 23:09:15.836836 xenpolicy: 0x00000083f94b4000-0x00000083f94b6a5f
> >> Jul  5 23:09:15.980866 Using bootargs from Xen configuration file.
> > 
> > This would not surprise me at all.  I was hoping that Jan would be able
> > to test this before he merged it, especially the ARM-specific stuff.
> 
> Jan (i.e. me)? I've never done any testing on Arm; all I do is build-test
> things there. Also if you suspected there might be issues, I think you
> should have arranged for someone to test this, i.e. at the very least
> indicate so in a post-commit-message remark targeted at the eventual
> committer.

I don't have access to an ARM64 machine (other than a mobile device)
myself, so I can't test anything on that platform.  I did not *expect*
there to be any issues, but I am not surprised that there are.  I should
have done a basic smoke test on x86, though.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

Attachment: signature.asc
Description: PGP signature