[ovmf baseline-only test] 68080: all pass

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

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 b43dd22981b71dd78dd4cc04d55dc23d81c3bafb
baseline version:
 ovmf                 01dd077315c6759c94af9af4232f8318db13cf8d

Last test of basis    68075  2016-11-21 16:49:08 Z    1 days
Testing same since    68080  2016-11-22 11:49:41 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Jeff Fan <jeff.fan@intel.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 b43dd22981b71dd78dd4cc04d55dc23d81c3bafb
Author: Laszlo Ersek <lersek@redhat.com>
Date:   Thu Nov 17 21:13:29 2016 +0100

    UefiCpuPkg/PiSmmCpuDxeSmm: dynamic PcdCpuSmmApSyncTimeout, PcdCpuSmmSyncMode
    
    Move the declaration of these PCDs from the
    
      [PcdsFixedAtBuild, PcdsPatchableInModule]
    
    section of "UefiCpuPkg/UefiCpuPkg.dec" to the
    
      [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]
    
    section. Their types, default values, and token values remain unchanged.
    
    Only UefiCpuPkg/PiSmmCpuDxeSmm consumes these PCDs, specifically on the
    call stack of its entry point function, and it turns them into static or
    dynamically allocated data in SMRAM:
    
      PiCpuSmmEntry()                            [PiSmmCpuDxeSmm.c]
        InitializeSmmTimer()                     [SyncTimer.c]
          PcdCpuSmmApSyncTimeout
          -> mTimeoutTicker
        InitializeMpServiceData()                [MpService.c]
          InitializeMpSyncData()                 [MpService.c]
            PcdCpuSmmSyncMode
            -> mSmmMpSyncData->EffectiveSyncMode
    
    However, there's another call path to fetching "PcdCpuSmmSyncMode", namely
    
      SmmInitHandler()                           [PiSmmCpuDxeSmm.c]
        InitializeMpSyncData()                   [MpService.c]
          PcdCpuSmmSyncMode
          -> mSmmMpSyncData->EffectiveSyncMode
    
    and this path is exercised during S3 resume (as stated by the comment in
    SmmInitHandler() too, "Initialize private data during S3 resume").
    
    While we can call the PCD protocol (via PcdLib) for fetching dynamic PCDs
    in the entry point function, we cannot do that at S3 resume. Therefore
    pre-fetch PcdCpuSmmSyncMode into a new global variable (which lives in
    SMRAM) in InitializeMpServiceData(), just before calling
    InitializeMpSyncData(). This way InitializeMpSyncData() can retrieve the
    stashed PCD value from SMRAM, regardless of the boot mode.
    
    Cc: Jeff Fan <jeff.fan@intel.com>
    Cc: Jordan Justen <jordan.l.justen@intel.com>
    Cc: Michael Kinney <michael.d.kinney@intel.com>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=230
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Laszlo Ersek <lersek@redhat.com>
    Reviewed-by: Jeff Fan <jeff.fan@intel.com>

commit eaae7b33b1cf6b9f21db1636f219c2b6a8d88afd
Author: Jeff Fan <jeff.fan@intel.com>
Date:   Fri Nov 18 10:46:43 2016 +0800

    MdeModulePkg/PiSmmCore: Cache CommunicationBuffer info before using it
    
    gSmmCorePrivate->CommunicationBuffer and gSmmCorePrivate->BufferSize locate at
    runtime memory region. That means they could be modified by non-SMM code during
    runtime.
    
    We should cache them into SMM local variables before we verify them. After
    verification, we should use the cached ones directly instead of the ones in
    gSmmCorePrivate.
    
    Cc: Jiewen Yao <jiewen.yao@intel.com>
    Cc: Feng Tian <feng.tian@intel.com>
    Cc: Michael D Kinney <michael.d.kinney@intel.com>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Jeff Fan <jeff.fan@intel.com>

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