From: Platform Team regression test user <citrix-osstest@xenproject.org>
To: xen-devel@lists.xensource.com, osstest-admin@xenproject.org
Subject: [ovmf baseline-only test] 38340: regressions - FAIL
Date: Wed, 25 Nov 2015 11:00:38 +0000 [thread overview]
Message-ID: <osstest-38340-mainreport@xen.org> (raw)
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@linaro.org>
Ruiyu Ni <ruiyu.ni@intel.com>
Wei Huang <wei@redhat.com>
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@linaro.org>
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@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
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@linaro.org>
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@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
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@linaro.org>
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@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Wei Huang <wei@redhat.com>
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@linaro.org>
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@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Wei Huang <wei@redhat.com>
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@intel.com>
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@intel.com>
Reviewed-by: Shumin Qiu <shumin.qiu@intel.com>
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@intel.com>
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@intel.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18926 6f19259b-4bc3-4df7-8a09-765794883524
reply other threads:[~2015-11-25 11:00 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=osstest-38340-mainreport@xen.org \
--to=citrix-osstest@xenproject.org \
--cc=osstest-admin@xenproject.org \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.