[Xen-devel] [ovmf baseline-only test] 68310: all pass

[Platform Team regression test user <citrix-osstest@xxxxxxxxxxxxxx>]

This run is configured for baseline tests only.

flight 68310 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68310/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 32ea56f0a65b80324e3e651432bdf496a6fc55b7
baseline version:
 ovmf                 7c6075e2546dd818b7b87090a983429b1942796a

Last test of basis    68309  2017-01-03 10:17:45 Z    0 days
Testing same since    68310  2017-01-03 15:17:10 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  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 32ea56f0a65b80324e3e651432bdf496a6fc55b7
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Wed Nov 30 20:31:18 2016 +0100

    Vlv2TbltDevicePkg/BootScriptSaveDxe: save 64-bit LoopTimes
    
    The BootScriptMemPoll() helper function does the following:
    
    - pop LoopTimes from the variable argument list as UINT64, then truncate
      it to UINTN,
    
    - pass the truncated value to S3BootScriptSaveMemPoll() as last argument.
    
    The truncation to UINTN is now superfluous, thanks to the patch titled
    "MdePkg, MdeModulePkg: S3BootScriptSaveMemPoll(): accept 64-bit
    LoopTimes".
    
    Cc: David Wei <david.wei@xxxxxxxxx>
    Cc: Mang Guo <mang.guo@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: "Yao, Jiewen" <jiewen.yao@xxxxxxxxx>
    Reviewed-by: Michael Kinney <michael.d.kinney@xxxxxxxxx>

commit 387ccad8f6f3acbae80bbeb816c944dec672aa66
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Wed Nov 30 20:19:06 2016 +0100

    MdeModulePkg: S3SaveStateDxe, SmmS3SaveState: save 64-bit LoopTimes
    
    The BootScriptWriteMemPoll() helper function in both drivers does the
    following:
    
    - pop Delay from the variable argument list as UINT64, then truncate it to
      UINTN,
    
    - divide Delay by 10, using DivU64x32Remainder(), then store the quotient
      in LoopTimes (also UINTN),
    
    - pass LoopTimes to S3BootScriptSaveMemPoll() as last argument.
    
    The truncation to UINTN is superfluous and wrong in this logic (not to
    mention incompatible with the PI spec); it prevents callers from
    specifying Delays longer than 0xFFFF_FFFF * 100ns (approximately 429
    seconds == 7 minutes 9 seconds) on Ia32. In particular it prevents callers
    from specifying an infinite timeout (for example, 0xFFFF_FFFF_FFFF_FFFF *
    100ns, approximately 58494 years).
    
    Change the type of Delay and LoopTimes to UINT64. Keep the same logic,
    just remove the truncations. The resultant LoopTimes values can be safely
    passed to S3BootScriptSaveMemPoll() thanks to the previous patch.
    
    Cc: Feng Tian <feng.tian@xxxxxxxxx>
    Cc: Star Zeng <star.zeng@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: "Yao, Jiewen" <jiewen.yao@xxxxxxxxx>
    Reviewed-by: Michael Kinney <michael.d.kinney@xxxxxxxxx>

commit 63042a718887693a07e6575fc8c8f58cdd0933cc
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Wed Nov 30 20:07:50 2016 +0100

    MdePkg, MdeModulePkg: S3BootScriptSaveMemPoll(): accept 64-bit LoopTimes
    
    The BaseNull instance of S3BootScriptLib obviously doesn't care about the
    type of the S3BootScriptSaveMemPoll() function's LoopTimes parameter; this
    lib instance doesn't do anything with the parameters received in
    S3BootScriptSaveMemPoll().
    
    The PiDxe instance saves the LoopTimes parameter in
    EFI_BOOT_SCRIPT_MEM_POLL.LoopTimes. This target field already has UINT64
    type. Furthermore, the BootScriptExecuteMemPoll() function in the same
    library instance already uses a local UINT64 variable called LoopTimes to
    count up to EFI_BOOT_SCRIPT_MEM_POLL.LoopTimes. This means that the the
    UINTN type for S3BootScriptSaveMemPoll()'s LoopTimes parameter is an
    unnecessary restriction.
    
    The callers of S3BootScriptSaveMemPoll() will be updated in the next
    patches, functionally. At this stage, they will continue to compile, since
    UINT64 parameters can accept UINTN arguments.
    
    Cc: Feng Tian <feng.tian@xxxxxxxxx>
    Cc: Liming Gao <liming.gao@xxxxxxxxx>
    Cc: Michael D Kinney <michael.d.kinney@xxxxxxxxx>
    Cc: Star Zeng <star.zeng@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: "Yao, Jiewen" <jiewen.yao@xxxxxxxxx>
    Reviewed-by: Michael Kinney <michael.d.kinney@xxxxxxxxx>

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