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] 68409: tolerable trouble: blocked/broken
Date: Sat, 21 Jan 2017 13:08:25 +0000 [thread overview]
Message-ID: <osstest-68409-mainreport@xen.org> (raw)
This run is configured for baseline tests only.
flight 68409 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68409/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-i386 3 host-install(3) broken baseline untested
build-amd64 3 host-install(3) broken baseline untested
build-i386-pvops 3 host-install(3) broken baseline untested
build-i386-xsm 3 host-install(3) broken baseline untested
build-amd64-pvops 3 host-install(3) broken baseline untested
build-amd64-xsm 3 host-install(3) broken baseline untested
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a
build-amd64-libvirt 1 build-check(1) blocked n/a
test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a
build-i386-libvirt 1 build-check(1) blocked n/a
version targeted for testing:
ovmf aa961dea1e199d23d9b7681f970ee023a856d0e5
baseline version:
ovmf 9c8fe63c15d638a1a546ca4592c15d1612e2123e
Last test of basis 68407 2017-01-20 22:46:38 Z 0 days
Testing same since 68409 2017-01-21 03:52:08 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Achin Gupta <achin.gupta@arm.com>
Ard Biesheuvel <ard.biesheuvel@linaro.org>
Laszlo Ersek <lersek@redhat.com>
Ryan Harkin <ryan.harkin@linaro.org>
jobs:
build-amd64-xsm broken
build-i386-xsm broken
build-amd64 broken
build-i386 broken
build-amd64-libvirt blocked
build-i386-libvirt blocked
build-amd64-pvops broken
build-i386-pvops broken
test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked
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
broken-step build-i386 host-install(3)
broken-step build-amd64 host-install(3)
broken-step build-i386-pvops host-install(3)
broken-step build-i386-xsm host-install(3)
broken-step build-amd64-pvops host-install(3)
broken-step build-amd64-xsm host-install(3)
Push not applicable.
------------------------------------------------------------
commit aa961dea1e199d23d9b7681f970ee023a856d0e5
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date: Fri Jan 20 16:44:35 2017 +0000
ArmPkg/ArmMmuLib: Revert "use a pool allocation for the root table"
This reverts commit d32702d2c2aa23e828363a7f88829b78ce36c3af.
Using a pool allocation for the root translation table seemed like
a good idea at the time, but as it turns out, such allocations are
handled in a way that makes them unsuitable for this purpose: they
are backed by HOBs that don't remain in the same place during the
various PI phase changes, which means the address programmed into
the TTBR register is no longer valid, and may refer to memory that
is reported as available to the OS.
So switch back to using a page based allocation.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
commit 734bd6cc41097bde7cc7d54084a042ff9b0ca0f5
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date: Fri Jan 20 11:58:37 2017 +0000
ArmPkg/ArmLib: remove indirection layer from timer register accessors
The generic timer support libraries call the actual system register
accessor function via a single pair of functions ArmArchTimerReadReg()
and ArmArchTimerWriteReg(), which take an enum argument to identify
the register, and return output values by pointer reference.
Since these functions are never called with a non-immediate argument,
we can simply replace each invocation with the underlying system register
accessor instead. This is mostly functionally equivalent, with the
exception of the bounds check for the enum (which is pointless given the
fact that we never pass a variable), the check for the presence of the
architected timer (which only makes sense for ARMv7, but is highly unlikely
to vary between platforms that are similar enough to run the same firmware
image), and a check for enum values that refer to the HYP view of the timer,
which we never referred to anywhere in the code in the first place.
So get rid of the middle man, and update the ArmGenericTimerPhyCounterLib
and ArmGenericTimerVirtCounterLib implementations to call the system
register accessors directly.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Tested-by: Ryan Harkin <ryan.harkin@linaro.org>
commit 90d1f671cdad43fa80ba295b3f8d1133d68229df
Author: Achin Gupta <achin.gupta@arm.com>
Date: Fri Jan 20 11:54:59 2017 +0000
ArmPlatformPkg/NorFlashDxe: Change Flash memory attributes before writes
In NorFlashFvbInitialize() if a valid Firmware Volume header is not found at the
start of NOR Flash, the Flash memory is written before it has been remapped with
EFI_MEMORY_UC attributes to allow write commands. Since the flash memory was
previously mapped with Normal and possibly cacheable memory attributes, the
Flash commands might never reach the device.
This patch fixes this issue by remapping the Flash memory region with correct
memory attributes before writing to it.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Achin Gupta <achin.gupta@arm.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
reply other threads:[~2017-01-21 13:08 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-68409-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).