[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [ovmf baseline-only test] 38340: regressions - FAIL
This run is configured for baseline tests only. flight 38340 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/38340/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm 5 xen-build fail REGR. vs. 38337 build-amd64-xsm 5 xen-build fail REGR. vs. 38337 build-i386 5 xen-build fail REGR. vs. 38337 Tests which did not succeed, but are not blocking: build-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 3164361121526318f278a7c1b84bdcc475d4ad95 baseline version: ovmf 63a9e0d6f98d65b93f2a4cfc1977b1c0c5052b5f Last test of basis 38337 2015-11-24 20:49:54 Z 0 days Testing same since 38340 2015-11-25 07:51:00 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> Ruiyu Ni <ruiyu.ni@xxxxxxxxx> Wei Huang <wei@xxxxxxxxxx> jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 pass build-i386 fail build-amd64-libvirt pass build-i386-libvirt blocked build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 blocked ------------------------------------------------------------ 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 3164361121526318f278a7c1b84bdcc475d4ad95 Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> Date: Tue Nov 24 08:40:33 2015 +0000 BaseTools/GenFw ARM: allow R_ARM_REL32 relocations R_ARM_REL32 are relative relocations, so we don't need to do anything special when performing the ELF to PE/COFF conversion, since our memory layout is identical between the two binary formats. So just allow them. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> Reviewed-by: Liming Gao <liming.gao@xxxxxxxxx> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18931 6f19259b-4bc3-4df7-8a09-765794883524 commit 2cde2696f5cd252c48fe250d44590869dae7a1e9 Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> Date: Tue Nov 24 07:48:06 2015 +0000 ArmLib/ArmV7Mmu: use 64-bit type for mapping region size The way the v7 MMU code is invoked by the Xen port is somewhat of a pathological case, since it describes its physical memory space using a single cacheable region that covers the entire addressable range. When clipping this region to the part that is 1:1 addressable, we end up with a region of exactly 4 GB in size, which just exceeds the range of the UINT32 variable we use in FillTranslationTable() to track our progress while populating the page tables. So promote it to UINT64 instead. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> Reviewed-by: Leif Lindholm <leif.lindholm@xxxxxxxxxx> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18930 6f19259b-4bc3-4df7-8a09-765794883524 commit 1dc3f34f61044a19573b1ecc507081bfcb075739 Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> Date: Tue Nov 24 07:44:41 2015 +0000 ArmVirtPkg/ArmVirtPlatformLib: reduce ID map size to GCD region size The ID mapping routines on virtual platforms simply map the entire hardware supported physical address space as device memory, and then punch some holes for regions that need to be mapped cacheable. On virtual platforms hosted on CPUs that support a large physical address range, this may result in a lot of overhead, i.e., 4 KB of page tables for each 512 GB of address space, which quickly adds up (i.e., 2 MB for the architectural maximum of 48 bits). Since there may be a platform specific limit to the size of the (I)PA space that is not reflected by CPU id registers, restrict the range of the ID mapping to gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize bits. This makes sense by itself, since we cannot manipulate mappings above that limit anwyay (because they are not covered by GCD), and it allows the PCD be set to a lower value by platforms whose (I)PA space is smaller than the hardware supported maximum. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> Reviewed-by: Laszlo Ersek <lersek@xxxxxxxxxx> Tested-by: Wei Huang <wei@xxxxxxxxxx> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18929 6f19259b-4bc3-4df7-8a09-765794883524 commit 7416fd46e330b4ffa7856754dd3f56991f4f67c9 Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> Date: Tue Nov 24 07:44:28 2015 +0000 ArmVirtPkg/ArmVirtQemu: limit the (I)PA space to 40 bits KVM uses a fixed size of 40 bits for its intermediate physical address space, so there is no need to support anything beyond that even if the host hardware does. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> Reviewed-by: Laszlo Ersek <lersek@xxxxxxxxxx> Tested-by: Wei Huang <wei@xxxxxxxxxx> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18928 6f19259b-4bc3-4df7-8a09-765794883524 commit 67b1c254dd17152d28933c5bf7fbefc53676d166 Author: Ruiyu Ni <ruiyu.ni@xxxxxxxxx> Date: Tue Nov 24 06:57:47 2015 +0000 MdeModulePkg/BdsDxe: Fix EBC build failure Define EFI_REMOVABLE_MEDIA_FILE_NAME for EBC ARCH to fix EBC build failure. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@xxxxxxxxx> Reviewed-by: Shumin Qiu <shumin.qiu@xxxxxxxxx> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18927 6f19259b-4bc3-4df7-8a09-765794883524 commit 665b26ba331d961cead150fe5b2dde385b9c3988 Author: Ruiyu Ni <ruiyu.ni@xxxxxxxxx> Date: Tue Nov 24 06:56:05 2015 +0000 MdeModulePkg/UefiBootManagerLib: Always create MemoryTypeInfo variable Align to old BDS behavior (IntelFrameworkModulePkg/BDS) to always create MemoryTypeInfo variable regardless of the PcdResetOnMemoryTypeInformationChange value. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@xxxxxxxxx> Reviewed-by: Michael Kinney <michael.d.kinney@xxxxxxxxx> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18926 6f19259b-4bc3-4df7-8a09-765794883524 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |