[ovmf baseline-only test] 72072: all pass

[Platform Team regression test user <citrix-osstest@xenproject.org>]

[-- Attachment #1: Type: text/plain, Size: 6220 bytes --]

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@linaro.org>
  Ge Song <ge.song@hxt-semitech.com>
  Laszlo Ersek <lersek@redhat.com>

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@hxt-semitech.com>
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@intel.com>
    Cc: Laszlo Ersek <lersek@redhat.com>
    Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Ge Song <ge.song@hxt-semitech.com>
    Tested-by: Laszlo Ersek <lersek@redhat.com>
    Reviewed-by: Laszlo Ersek <lersek@redhat.com>
    Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

commit a94081fb266bd71d94f4fd28d131ba82663307ae
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
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@linaro.org>
    Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>


[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel