[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [ovmf baseline-only test] 72134: all pass
This run is configured for baseline tests only. flight 72134 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/72134/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 947f3737abf65fda63f3ffd97fddfa6986986868 baseline version: ovmf b68c793144e8f239cf59fcc34ee6e35c1fdcd8a6 Last test of basis 72132 2017-09-20 21:47:10 Z 0 days Testing same since 72134 2017-09-21 06:22:21 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Aleksei Kovura <alex3kov@xxxxxxxx> 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 947f3737abf65fda63f3ffd97fddfa6986986868 Author: Laszlo Ersek <lersek@xxxxxxxxxx> Date: Tue Sep 19 17:05:08 2017 +0200 OvmfPkg/QemuVideoDxe/VbeShim: handle PAM1 register on Q35 correctly In commit db27e9f3d8f0 ("OvmfPkg/LegacyRegion: Support legacy region manipulation of Q35", 2016-03-15), Ray extended the OvmfPkg/Csm/CsmSupportLib PAM register manipulation to Q35. However, we missed that the same should be done to the QemuVideoDxe VBE Shim as well. The omission has caused no problems in practice on Q35, because QEMU has let us write to the ROM area, regardless of the PAM1 setting, all this time. This has now changed with recent QEMU commit 208fa0e43645 ("pc: make 'pc.rom' readonly when machine has PCI enabled", 2017-07-28). The QEMU commit exposes the OVMF bug when Windows 7 is started on Q35, using QEMU 2.10 -- the VBE Shim is no longer put in place and Windows 7 cannot find it. To remedy this, assign the "Pam1Address" local variable a PciLib address that matches the board type (i440fx vs. q35). Regarding the PcdLib dependency: QemuVideoDxe already uses PcdLib, both directly (see "PcdDriverSupportedEfiVersion") and indirectly (e.g. via the DxePciLibI440FxQ35 PciLib instance). Add PcdLib to [LibraryClasses] for completeness. Cc: Aleksei Kovura <alex3kov@xxxxxxxx> Cc: Gerd Hoffmann <kraxel@xxxxxxxxxx> Cc: Igor Mammedov <imammedo@xxxxxxxxxx> Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx> Cc: Ruiyu Ni <ruiyu.ni@xxxxxxxxx> Ref: https://bugs.launchpad.net/qemu/+bug/1715700 Reported-by: Aleksei Kovura <alex3kov@xxxxxxxx> Special-thanks-to: Gerd Hoffmann <kraxel@xxxxxxxxxx> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx> Tested-by: Aleksei Kovura <alex3kov@xxxxxxxx> Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx> commit ce461ae240a72ff6b0d8a407f004c5db354d91ae Author: Laszlo Ersek <lersek@xxxxxxxxxx> Date: Tue Sep 19 16:48:36 2017 +0200 OvmfPkg/QemuVideoDxe/VbeShim: rename Status to Segment0AllocationStatus This clarifies the purpose of the local variable in InstallVbeShim(). Cc: Aleksei Kovura <alex3kov@xxxxxxxx> Cc: Gerd Hoffmann <kraxel@xxxxxxxxxx> Cc: Igor Mammedov <imammedo@xxxxxxxxxx> Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx> Cc: Ruiyu Ni <ruiyu.ni@xxxxxxxxx> Ref: https://bugs.launchpad.net/qemu/+bug/1715700 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx> Tested-by: Aleksei Kovura <alex3kov@xxxxxxxx> Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx> commit ba1d245f1d3d40c7d87db57dae76e19cbf289718 Author: Laszlo Ersek <lersek@xxxxxxxxxx> Date: Tue Sep 19 15:50:39 2017 +0200 OvmfPkg/CsmSupportLib: move PAM register addresses to IndustryStandard * Introduce the PIIX4_PAM* and MCH_PAM* macros under "OvmfPkg/Include/IndustryStandard". These macros capture the PAM register offsets (in PCI config space) on the respective Memory Controller B/D/F, from the respective data sheets. * Under IndustryStandard, introduce the PMC_REGISTER_PIIX4() macro for PIIX4. (For Q35, we already have DRAMC_REGISTER_Q35().) In both cases, the B/D/F is 0/0/0. * Under CsmSupportLib, replace the "PAMRegOffset" field (UINT8) in the PAM_REGISTER_VALUE structure with "PAMRegPciLibAddress" (UINTN). The new field contains the return value of the PCI_LIB_ADDRESS() macro. * Under CsmSupportLib, replace the "mRegisterValues440" elements as follows: REG_PAMx_OFFSET_440, ReadEnableData, WriteEnableData --> PMC_REGISTER_PIIX4 (PIIX4_PAMx), ReadEnableData, WriteEnableData * Under CsmSupportLib, replace the "mRegisterValuesQ35" elements as follows: REG_PAMx_OFFSET_Q35, ReadEnableData, WriteEnableData --> DRAMC_REGISTER_Q35 (MCH_PAMx), ReadEnableData, WriteEnableData * Under CsmSupportLib, update the register address calculations as follows (for all of PciOr8(), PciAnd8() and PciRead8()): PCI_LIB_ADDRESS ( PAM_PCI_BUS, PAM_PCI_DEV, PAM_PCI_FUNC, mRegisterValues[Index].PAMRegOffset ) --> mRegisterValues[Index].PAMRegPciLibAddress * Under CsmSupportLib, remove the PAM_PCI_* and REG_PAM*_OFFSET_* macros. Technically speaking, these changes could be split into three patches (IndustryStandard macro additions, CsmSupportLib code updates, CsmSupportLib macro removals). However, the patch is not big, and in this case it is actually helpful to present the code movement / refactoring in one step, for easier verification. Cc: Aleksei Kovura <alex3kov@xxxxxxxx> Cc: Gerd Hoffmann <kraxel@xxxxxxxxxx> Cc: Igor Mammedov <imammedo@xxxxxxxxxx> Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx> Cc: Ruiyu Ni <ruiyu.ni@xxxxxxxxx> Ref: https://bugs.launchpad.net/qemu/+bug/1715700 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx> Tested-by: Aleksei Kovura <alex3kov@xxxxxxxx> Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx> _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |