|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [ovmf baseline-only test] 72072: all pass
This run is configured for baseline tests only. flight 72072 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/72072/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 89796c69d9fdaa9bd13d37b6b1687df5e0104ed5 baseline version: ovmf b80a4097393c90d041b299ef628e6104612a2586 Last test of basis 72070 2017-09-07 01:21:42 Z 0 days Testing same since 72072 2017-09-07 15:49:09 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> Ge Song <ge.song@xxxxxxxxxxxxxxxx> Laszlo Ersek <lersek@xxxxxxxxxx> jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass ------------------------------------------------------------ sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ------------------------------------------------------------ commit 89796c69d9fdaa9bd13d37b6b1687df5e0104ed5 Author: Ge Song <ge.song@xxxxxxxxxxxxxxxx> Date: Wed Sep 6 11:11:35 2017 +0800 OvmfPkg/SecMain: Fix stack switching to permanent memory In earlier PEI stage, temporary memory at PcdOvmfSecPeiTempRamBase is employed as stack and heap. We move them to the new room and do some relocation fixup when permanent memory becomes available. TemporaryRamMigration() is responsible for switching the stack. Before entering TemporaryRamMigration(), Ebp/Rbp is populated with the content of Esp/Rsp and used as frame pointer. After the execution of SetJump/LongJump, stack migrates to new position while the context keeps unchanged. But when TemporaryRamMigration() exits, Esp/Rsp is filled with the content of Ebp/Rbp to destroy this stack frame. The result is, stack switches back to previous temporary memory. When permanent memory becomes available, modules that have registered themselves for shadowing will be scheduled to execute. Some of them need to consume more memory(heap/stack). Contrast to temporary stack, permanent stack possesses larger space. The potential risk is overflowing the stack if stack staying in temporary memory. When it happens, system may crash during S3 resume. More detailed information: > (gdb) disassemble /r > Dump of assembler code for function TemporaryRamMigration: > 0x00000000fffcd29c <+0>: 55 push %rbp > 0x00000000fffcd29d <+1>: 48 89 e5 mov %rsp,%rbp > 0x00000000fffcd2a0 <+4>: 48 81 ec 70 01 00 00 sub > $0x170,%rsp > ... > ... > 0x00000000fffcd425 <+393>: e8 80 10 00 00 callq 0xfffce4aa > <SaveAndSetDebugTimerInterrupt> > => 0x00000000fffcd42a <+398>: b8 00 00 00 00 mov $0x0,%eax > 0x00000000fffcd42f <+403>: c9 leaveq > 0x00000000fffcd430 <+404>: c3 retq > End of assembler dump. See the description of leave(opcode: c9), from Intel 64 and IA-32 Architectures Software Developer's Manual, Volume 2A "Releases the stack frame set up by an earlier ENTER instruction. The LEAVE instruction copies the frame pointer (in the EBP register) into the stack pointer register (ESP), which releases the stack space allocated to the stack frame. The old frame pointer (the frame pointer for the calling procedure that was saved by the ENTER instruction) is then popped from the stack into the EBP register, restoring the calling procedureâ??s stack frame." To solve this, update Ebp/Rbp too when Esp/Rsp is updated Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx> Cc: Laszlo Ersek <lersek@xxxxxxxxxx> Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ge Song <ge.song@xxxxxxxxxxxxxxxx> Tested-by: Laszlo Ersek <lersek@xxxxxxxxxx> Reviewed-by: Laszlo Ersek <lersek@xxxxxxxxxx> Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx> commit a94081fb266bd71d94f4fd28d131ba82663307ae Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> Date: Tue Sep 5 19:14:41 2017 +0100 ArmPkg: add ArmCrashDumpDxe driver Even though RELEASE builds produce some diagnostics when a crash occurs, they can be rather unhelpful: Synchronous Exception at 0x0000000000000000 and sometimes, it would be useful to get a full register dump from a production machine without having to modify the firmware. This can be achieved very easily by incorporating a DEBUG build of ARM's DefaultExceptionHandlerLib into a DXE driver, and registering its DefaultExceptionHandler entry point as the synchronous exception handler, overriding the default one. If we then build this driver using the UefiDebugLibConOut DebugLib implementation, we end up with a module than can simply be loaded via the Shell on any system. Shell> load fs0:ArmCrashDumpDxe.efi As a bonus, the crash dump will also appear on the graphical display, not only on the serial port. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> Reviewed-by: Leif Lindholm <leif.lindholm@xxxxxxxxxx> _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |