> On 6 Jul 2022, at 09:05, Demi Marie Obenour <[email protected]> > wrote: > > On Wed, Jul 06, 2022 at 08:53:49AM +0100, Julien Grall wrote: >> Hi Jan, >> >> On 06/07/2022 07:44, Jan Beulich wrote: >>> 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 ... >> >> I have tested a Xen with and without this patch this morning and can EFI. I >> haven't looked into details yet why. >> >> Can we consider to revert it? > > I'm fine with reverting it for now, but I would like to know what the > bug was. Does a Xen with this patch boot okay on x86? If so, could it > be temporarily turned off on ARM until the problem can be tracked down?
I can test it with an arm64 machine, I will try it now, will let you know. Cheers, Luca > -- > Sincerely, > Demi Marie Obenour (she/her/hers) > Invisible Things Lab
