On 06.07.2022 05:39, osstest service owner wrote: > flight 171511 xen-unstable-smoke real [real] > flight 171517 xen-unstable-smoke real-retest [real] > http://logs.test-lab.xenproject.org/osstest/logs/171511/ > http://logs.test-lab.xenproject.org/osstest/logs/171517/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. > 171486
Looking at what's under test, I guess ... > commit 8d410ac2c178e1dd1001cadddbe9ca75a9738c95 > Author: Demi Marie Obenour <[email protected]> > 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 <[email protected]> > Reviewed-by: Jan Beulich <[email protected]> ... 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. But I guess we'll want to wait for the bi-sector to give us a more solid indication ... Jan
