[ovmf baseline-only test] 71952: all pass

[ovmf baseline-only test] 71952: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 9e2a8e928995c3b1bb664b73fd59785055c6b5f6
baseline version:
 ovmf                 4cf3f37c87ba1f9d58072444bd735e40e4779e70

Last test of basis    71951  2017-08-08 17:47:30 Z    0 days
Testing same since    71952  2017-08-09 01:17:17 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Dhiru Kholia <dhiru.kholia@gmail.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 9e2a8e928995c3b1bb664b73fd59785055c6b5f6
Author: Laszlo Ersek <lersek@redhat.com>
Date:   Sun Aug 6 11:20:02 2017 +0200

    OvmfPkg/AcpiPlatformDxe: short-circuit the transfer of an empty S3_CONTEXT
    
    In commit 805762252733 ("OvmfPkg/AcpiPlatformDxe: save fw_cfg boot script
    with QemuFwCfgS3Lib", 2017-02-23), we replaced the explicit S3 boot script
    manipulation in TransferS3ContextToBootScript() with a call to
    QemuFwCfgS3CallWhenBootScriptReady(). (Passing AppendFwCfgBootScript() as
    callback.)
    
    QemuFwCfgS3CallWhenBootScriptReady() checks for fw_cfg DMA up-front, and
    bails with RETURN_NOT_FOUND if fw_cfg DMA is missing.
    
    (This is justified as the goal of QemuFwCfgS3Lib is to "enable[] driver
    modules [...] to produce fw_cfg DMA operations that are to be replayed at
    S3 resume time".)
    
    In turn, if QemuFwCfgS3CallWhenBootScriptReady() fails, then
    OvmfPkg/AcpiPlatformDxe rolls back any earlier linker/loader script
    processing, and falls back to the built-in ACPI tables.
    
    (This is also justified because failure to save WRITE_POINTER commands for
    replaying at S3 resume implies failure to process the linker/loader script
    comprehensively.)
    
    Calling QemuFwCfgS3CallWhenBootScriptReady() from
    TransferS3ContextToBootScript() *unconditionally* is wrong however. For
    the case when the linker/loader script contains no WRITE_POINTER commands,
    the call perpetuated an earlier side effect, and introduced another one:
    
    (1) On machine types that provide fw_cfg DMA (i.e., 2.5+),
        QemuFwCfgS3CallWhenBootScriptReady() would succeed, and allocate
        workspace for the boot script opcodes in reserved memory. However, no
        opcodes would actually be produced in the AppendFwCfgBootScript()
        callback, due to lack of any WRITE_POINTER commands.
    
        This waste of reserved memory had been introduced in earlier commit
        df73df138d9d ("OvmfPkg/AcpiPlatformDxe: replay
        QEMU_LOADER_WRITE_POINTER commands at S3", 2017-02-09).
    
    (2) On machine types that lack fw_cfg DMA (i.e., 2.4 and earlier),
        TransferS3ContextToBootScript() would now fail the linker/loader
        script for no reason.
    
        (Note that QEMU itself prevents adding devices that depend on
        WRITE_POINTER if the machine type lacks fw_cfg DMA:
    
        $ qemu-system-x86_64 -M pc-q35-2.4 -device vmgenid
    
        qemu-system-x86_64: -device vmgenid: vmgenid requires DMA write
        support in fw_cfg, which this machine type does not provide)
    
    Short-circuit an empty S3_CONTEXT in TransferS3ContextToBootScript() by
    dropping S3_CONTEXT on the floor. This is compatible with the current
    contract of the function as it constitutes a transfer of ownership.
    
    Regression (2) was found and reported by Dhiru Kholia as an OSX guest boot
    failure on the "pc-q35-2.4" machine type:
    
    http://mid.mail-archive.com/CANO7a6x6EaWNZ8y=MvLU=w_LjRLXserO3NmsgHvaYE0aUCCWzg@mail.gmail.com
    
    Dhiru bisected the issue to commit 805762252733.
    
    Cc: Dhiru Kholia <dhiru.kholia@gmail.com>
    Cc: Jordan Justen <jordan.l.justen@intel.com>
    Fixes: df73df138d9d53f7f7570f4fe97a6cde941a2656
    Fixes: 805762252733bb67bc5157f0137c64e010724c77
    Reported-by: Dhiru Kholia <dhiru.kholia@gmail.com>
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Laszlo Ersek <lersek@redhat.com>
    Tested-by: Dhiru Kholia <dhiru.kholia@gmail.com>
    Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

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