[VIRT-349 # QEMU SVE2 Support ]
More progress on insn implementation.
More patches from Stephen Long merged.
More good review from Laurent Desnogues.
Down to perhaps 30 insns remaining, and then figuring out some miscomparisons
reported by Laurent, but not diagnosed.
[VIRT-344 # ARMv8.5-MemTag ]
Fixed an exception return bug vs PSTATE.TCO.
[VIRT-327 # Richard's upstream QEMU work ]
Posted some tcg patch sets for 5.1.
Worked on the sparc regression Alex reported vs TEMP_CONST. I've set that
aside for now; I need to come up with a new scheme to debug that one.
r~
Progress:
* VIRT-65 [QEMU upstream maintainership]
- We needed an rc4 (which I wasn't very surprised about), so more
release wrangling again.
- Noticed some bugs in how we set ID registers for the AArch64 'max' CPU;
sent patches (one of which seemed worth getting into rc4)
- There's been a long-standing problem where a linux-user QEMU running
on a 64-bit host and emulating a 32-bit guest can't deal with the
64-bit hash 'offsets' from ext4 getdents, which causes guests using
newer glibc to fail. Linus Walleij wrote a kernel patch which allows
QEMU to request that the kernel gives it hash values that will fit
into 32 bits. I wrote an RFC QEMU patch that would use this and tested
that this does indeed solve the problem. Discussion is continuing on
the kernel size about what the correct API for this is, but the
principle that the kernel should change seems to be accepted.
- A bug was raised that BKPT for arm linux-user wasn't causing SIGTRAP;
sent patches fixing that and some other issues I noticed in that
bit of the code while I was fixing it.
- code review:
+ a patch adding proper FIFO emulation to the PL011 UART model
+ rth's patchset improving codegen of neon integer-compare-vs-0 insns
+ xilinx patchset to disable unsupported FDT firmware nodes
+ patchset adding kaslr-seed properties to the virt board dtb
(mostly useful for OP-TEE)
* VIRT-364 [QEMU support for ARMv8.1-M extensions]
- Progress with neon decodetree conversion. I've now completed all
the 3-reg-same insn grouping, which is a large enough amount that
I'm planning to send out a patchset with what I have so far.
Need to refactor/tidy up some bits of the code first, now I can
see what the completed conversion looks like.
thanks
-- PMM
== Progress ==
* GCC upstream validation:
- reported a couple of failures/regressions
* GCC:
- Committed a few fixes to MVE/CDE tests to avoid failures on
arm-linux-gnueabi toolchains
- Sent a few more testcases fixes
- PR94538 (pure-code/M23): Let Wilco handle it since he has more testcases
- Looked at Linaro bug #5614, and forwarded it for upstream discussion
as PR94743 (IRQ handler and Neon registers)
* FDPIC/GDB:
- rebased gdbserver patches, it still crashes at runtime. Code size
bigger than my last attempt with gdb-8.x.
- tried to link it statically, but that fails because of multiple defs
in uclibc.
* misc:
- infra fixes / troubleshooting / reviews
- lots of disruptions
== Next ==
* FDPIC GDB
* GCC/cortex-M
Looks like there might be something wrong with this buildbot? (none of the
commits seem to have changed lnt - or maybe lnt isn't monitored/blamed in
the buildbot config?)
On Tue, Apr 21, 2020 at 12:16 AM <llvm.buildmaster(a)lab.llvm.org> wrote:
> The Buildbot has detected a new failure on builder clang-cmake-armv8-lld
> while building llvm.
> Full details are available at:
> http://lab.llvm.org:8011/builders/clang-cmake-armv8-lld/builds/3875
>
> Buildbot URL: http://lab.llvm.org:8011/
>
> Buildslave for this Build: linaro-armv8-01-arm-lld
>
> Build Reason: scheduler
> Build Source Stamp: [branch master]
> c2d86e1f3044abb295796c8267c7b9057f54a067
> Blamelist: Alexander Shaposhnikov <alexshap(a)fb.com>,Chris Bieneman <
> chris.bieneman(a)me.com>,Dan Liew <dan(a)su-root.co.uk>,David Blaikie <
> dblaikie(a)gmail.com>,Johannes Doerfert <johannes(a)jdoerfert.de>,Mircea
> Trofin <mtrofin(a)google.com>,Pavel Iliin <Pavel.Iliin(a)arm.com>,Sam Kerner <
> skerner(a)chromium.org>,Shengchen Kan <shengchen.kan(a)intel.com>,Sriraman
> Tallam <tmsriram(a)google.com>
>
> BUILD FAILED: failed setup lit
>
> sincerely,
> -The Buildbot
>
>
>
>
Short weeks around Easter.
[VIRT-349 # QEMU SVE2 Support ]
Lots of progress on insn implementation.
Several patches from Stephen Long merged. He's coming up to speed nicely.
Some good review from Laurent Desnogues.
Spent some time writing a version of strspn for Arm optimized-routines, as a
way of testing the NMATCH instruction. Found bugs in the tcg optimizer
instead. Still in the process of rebasing the branch upon those fixes, and
upon patch review from Peter.
[VIRT-327 # Richard's upstream QEMU work ]
Couple of patches for 5.0.
[GCC]
Posted v4 of aarch64 cmpti patch set.
r~
VirtIO Related Work ([VIRT-366])
================================
[VIRT-366] <https://projects.linaro.org/browse/VIRT-366>
VirtIO RPMB ([VIRT-371])
- started work on [vhost-user backend for rpmb]
- have the basic vhost-user loop created, still need to plumb into
QEMU
- will be able to experiment with [VIRT-402] minimal profile once
running
[VIRT-371] <https://projects.linaro.org/browse/VIRT-371>
[vhost-user backend for rpmb]
<https://github.com/stsquad/qemu/tree/vhost-user-rpmb>
[VIRT-402] <https://projects.linaro.org/browse/VIRT-402>
VirtiIO blogpost ([LBO-2])
- wrote up history of VirtIO up to standardisation
- still TODO new work and architectures
[LBO-2] <https://projects.linaro.org/browse/LBO-2>
slides with virtio architectures for Victor
Upstream Work ([VIRT-109])
==========================
- posted [PULL for 5.0-rc3 0/8] a few small fixes (docker, user, pie
and gdbstub) Message-Id:
<20200415104211.9388-1-alex.bennee(a)linaro.org>
[VIRT-109] <https://projects.linaro.org/browse/VIRT-109>
Other
=====
- preparation work and GSoC candidate interviews
[my QEMU developer guide]
<https://people.linaro.org/~alex.bennee/org/presentations/qemu-developer-gui…>
Absences
========
- Home-schooling in mornings
Current Review Queue
====================
* [RFC][PATCH v2 0/3] IVSHMEM version 2 device for QEMU
Message-Id: <cover.1578407802.git.jan.kiszka(a)siemens.com>
Added: <2020-04-09 Thu>
* [PATCH v6 00/36] Initial support for multi-process qemu
Message-Id: <cover.1586165555.git.elena.ufimtseva(a)oracle.com>
Added: <2020-04-06 Mon>
* [PATCH v4 00/10] tests/vm: Add support for aarch64 VMs
Message-Id: <20200312142728.12285-1-robert.foley(a)linaro.org>
Added: <2020-03-27 Fri>
--
Alex Bennée
(short week, 3 days)
Progress:
* VIRT-65 [QEMU upstream maintainership]
- getting rc3 out of the door, including sorting out some last
minute bug fixes. As usual, we hope not to need an rc4 but I
expect we will.
- code review; a two-day blitz has got my to-review queue down
to a slightly more manageable size...
+ rth's series refactoring SVE load/store implementation
+ Guenter's i.MX watchdog support series
+ brief pass over raspi USB host controller emulation series
+ patch adding /secure-chosen/kaslr-seed to the virt dtb
+ the Greensocs/Xilinx clock framework patchset
[including doing an editing pass on the docs]
thanks
-- PMM
Hello!
I know, this is probably a very stupid question, but I couldn't find an
answer for it. On the page
https://releases.linaro.org/components/toolchain/binaries/latest-5/arm-linu…
there are 3 major download components: gcc/sysroot/runtime.
I download 'gcc', add 'gcc-linaro-.../bin' to my PATH and cross compile my
apps.
On my target system, I need 'libc', and it is present in the
'sysroot-linaro-...'. Do I need to copy all of the contents of
'sysroot-linaro-...' folder to my target? 'linaro-sysroot' folder is kinda
big. 'libc.so' library is 13MB. If there is a way to decrease its size, if
I want to use Linaro compiled programs on an embedded target?
And what is a purpose of 'runtime-linaro-..." component?
Hello!
I know, this is probably a very stupid question, but I couldn't find an answer for it. On the page https://releases.linaro.org/components/toolchain/binaries/latest-5/arm-linu… there are 3 major download components: gcc/sysroot/runtime.
I download 'gcc', add 'gcc-linaro-.../bin' to my PATH and cross compile my apps.
On my target system, I need 'libc', and it is present in the 'sysroot-linaro-...'. Do I need to copy all of the contents of 'sysroot-linaro-...' folder to my target? 'linaro-sysroot' folder is kinda big. 'libc.so' library is 13MB. If there is a way to decrease its size, if I want to use Linaro compiled programs on an embedded target?
And what is a purpose of 'runtime-linaro-..." component?
== This Week ==
* LLVM-611 (tune heuristic to lower blx): Working on feedback.
* GNU-659: Doing benchmarking experiments
* Public holiday
- One day off
== Next Week ==
- Continue with LLVM-611 and GNU-659
== Progress ==
* GCC upstream validation:
- reported a couple of failures/regressions
* GCC:
- comparing testsuite results for cortex-m3 and cortex-m33 with
cortex-a9 to check what cortex-M problem there are. Updated cmse-15.c test.
Analyzing / bisecting other failures.
- Sent fixes to MVE tests to avoid failures on arm-linux-gnueabi toolchains
- Updated a few bugzilla entries about cortex-m issues
* misc:
- infra fixes / troubleshooting / reviews
== Next ==
* FDPIC GDB
* GCC/cortex-M
Hi,
clang-cmake-armv7-full fails with "No space left on device", e.g.:
http://lab.llvm.org:8011/builders/clang-cmake-armv7-full/builds/9808/steps/…
> The Buildbot has detected a new failure on builder clang-cmake-armv7-
full while building llvm.
> Full details are available at:
> http://lab.llvm.org:8011/builders/clang-cmake-armv7-full/builds/9808
>
> Buildbot URL: http://lab.llvm.org:8011/
>
> Buildslave for this Build: linaro-tk1-06
>
> Build Reason: scheduler
> Build Source Stamp: [branch master]
3bc439bdff8bb5518098bd9ef52c56ac071276bc
> Blamelist: Ilya Leoshkevich <iii(a)linux.ibm.com>
>
> BUILD FAILED: failed Checkout test-suite
>
> sincerely,
> -The Buildbot
Could someone please take a look?
Best regards,
Ilya
VirtIO Related Work ([VIRT-366])
================================
[VIRT-366] <https://projects.linaro.org/browse/VIRT-366>
slides with virtio architectures for Victor
an overview blogpost for Ebba
- started drafting a blog post
Upstream Work ([VIRT-109])
==========================
- posted [PULL for 5.0-rc2 00/13] various fixes Message-Id:
<20200407155118.20139-1-alex.bennee(a)linaro.org>
- a bit of launchpad triage for release
- posted [PATCH for 5.0-rc3 v1 00/11] more random fixes Message-Id:
<20200409211529.5269-1-alex.bennee(a)linaro.org>
[VIRT-109] <https://projects.linaro.org/browse/VIRT-109>
Other
=====
- updated [my QEMU developer guide] for team workshop
[my QEMU developer guide]
<https://people.linaro.org/~alex.bennee/org/presentations/qemu-developer-gui…>
Absences
========
- Easter Weekend (bank holidays)
Current Review Queue
====================
* [RFC][PATCH v2 0/3] IVSHMEM version 2 device for QEMU
Message-Id: <cover.1578407802.git.jan.kiszka(a)siemens.com>
Added: <2020-04-09 Thu>
* [PATCH v6 00/36] Initial support for multi-process qemu
Message-Id: <cover.1586165555.git.elena.ufimtseva(a)oracle.com>
Added: <2020-04-06 Mon>
* [PATCH v4 00/10] tests/vm: Add support for aarch64 VMs
Message-Id: <20200312142728.12285-1-robert.foley(a)linaro.org>
Added: <2020-03-27 Fri>
* [PATCH v8 00/74] per-CPU locks
Message-Id: <20200326193156.4322-1-robert.foley(a)linaro.org>
Added: <2020-03-27 Fri>
--
Alex Bennée
(short week, 4 days)
Progress:
* VIRT-364 [QEMU support for ARMv8.1-M extensions]
- Still working through the Neon decoder refactoring. Finished
loads-and-stores and am now on the 2000-line function that handles
data-processing insns...
thanks
-- PMM
Hi,
It looks like several bots assigned to you started failing after e6a39f00e8d0 was committed:
http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-armv8-linux-no…http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-armv8-linuxhttp://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-aarch64-linuxhttp://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-aarch64-linux-…
They all fail on the test libcxx/test/libcxx/modules/stds_include.sh.cpp with the following error:
<...>/libcxx/test/libcxx/modules/stds_include.sh.cpp:28:2: fatal error: file '<...>/libcxx/include/type_traits' has been modified since the module file '<TMP>/ModuleCache/1E92AHT/std-1V9DLRO.pcm' was built
#include <vector>
^
<...>/libcxx/test/libcxx/modules/stds_include.sh.cpp:28:2: note: please rebuild precompiled header '<TMP>/ModuleCache/1E92AHT/std-1V9DLRO.pcm'
1 error generated.
Our other bots are not failing, so I very strongly suspect this is not because of the change itself, but rather some weirdness in your bot configuration. For that reason, I will *not* revert the change (that would likely not improve the situation anyway). Can you please collaborate with us to understand and fix the issue?
Thanks,
Louis
Hi,
It looks like the following bots assigned to you started failing recently:
http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-armv7-linuxhttp://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-armv7-linux-no…
The failing tests are all filesystem tests:
FAIL: libc++::assign.pass.cpp
FAIL: libc++::path.pass.cpp
FAIL: libc++::replace_filename.pass.cpp
FAIL: libc++::refresh.pass.cpp
FAIL: libc++::file_size.pass.cpp
FAIL: libc++::file_type_obs.pass.cpp
FAIL: libc++::hard_link_count.pass.cpp
FAIL: libc++::last_write_time.pass.cpp
FAIL: libc++::ctor.pass.cpp
FAIL: libc++::ctor.pass.cpp
FAIL: libc++::increment.pass.cpp
FAIL: libc++::exists.pass.cpp
FAIL: libc++::is_block_file.pass.cpp
FAIL: libc++::is_character_file.pass.cpp
FAIL: libc++::is_directory.pass.cpp
FAIL: libc++::is_empty.pass.cpp
FAIL: libc++::is_fifo.pass.cpp
FAIL: libc++::is_other.pass.cpp
FAIL: libc++::is_regular_file.pass.cpp
FAIL: libc++::is_socket.pass.cpp
Having seen some of these issues before, I strongly suspect this is due to the fact that your builder is running as root. Libc++'s filesystem tests are known to fail when run as root, because some of them need to check for failure to access some files for which there's no permission. This doesn't seem to work when run as root.
Can you work with us to resolve this issue?
Thanks,
Louis
== Progress ==
* GCC upstream validation:
- reported a couple of failures/regressions
* GCC:
- comparing testsuite results for cortex-m3 and cortex-m33 with
cortex-a9 to check what cortex-M problem there are.
Spent a long time isolating a regression in CMSE tests. Filed
PR94445 which was then quickly fixed by upstream in ICF optimization.
* misc:
- infra fixes / troubleshooting / reviews
== Next ==
* FDPIC GDB
* GCC/cortex-M
[VIRT-349 # QEMU SVE2 Support ]
Met with Qualcomm on Friday to discuss sharing the development work, and help
start bringing their new-hire, Stephen Long, up to speed on qemu.
Gave Stephen generic qemu development pointers, and a simple set of SVE2
instruction on which to wet his feet.
[VIRT-327 # Richard's upstream QEMU work ]
Better constant propagation and allocation for TCG.
Worked on probe_guest_base as a follow-up to some of the work Alex was doing
wrt init_guest_space.
Misc patch review for 5.0.
[GCC]
Posted v3 of aarch64 cmpti patch set.
r~
== This Week ==
* LLVM
- LLVM-611 (Tune heuristic for blx): Posted upstream.
- LLVM-612 (Redundant reg moves for 8-bit immediates): WIP patch
* Public Holiday
- one day off
== Next Week ==
- Continue with LLVM tasks
- Start looking at GNU-659
VirtIO Related Work ([VIRT-366])
================================
- minor planning work
- need a few slides with virtio architectures for Victor
- a overview blogpost for Ebba
[VIRT-366] <https://projects.linaro.org/browse/VIRT-366>
Upstream Work ([VIRT-109])
==========================
- GSoC feedback on proposals
- we have 3 students putting forward proposals for TCG cache plugin
- posted [PATCH] hw/core: properly terminate loading .hex on EOF
record Message-Id: <20200401193849.14017-1-alex.bennee(a)linaro.org>
- posted [PATCH] target/arm: don't expose "ieee_half" via gdbstub
Message-Id: <20200402143913.24005-1-alex.bennee(a)linaro.org>
- posted [PATCH for 5.0 v2 00/10] A selection of sanitiser fixes
Message-Id: <20200401094759.5835-1-alex.bennee(a)linaro.org>
- the linux-user guest map is better targeted at next week
- posted [PATCH v3 for 5.0-rc2 00/12] a selection of random fixes
Message-Id: <20200403191150.863-1-alex.bennee(a)linaro.org>
[VIRT-109] <https://projects.linaro.org/browse/VIRT-109>
Completed Reviews [1/1]
=======================
[PATCH for-5.0 v3 0/7] configure: Improve PIE and other linkage
Message-Id: <20200327220353.27233-1-richard.henderson(a)linaro.org>
Absences
========
- Splitting time between work and home-schooling
Current Review Queue
====================
* [PATCH v4 00/10] tests/vm: Add support for aarch64 VMs
Message-Id: <20200312142728.12285-1-robert.foley(a)linaro.org>
Added: <2020-03-27 Fri>
* [PATCH v8 00/74] per-CPU locks
Message-Id: <20200326193156.4322-1-robert.foley(a)linaro.org>
Added: <2020-03-27 Fri>
* [virtio-dev] [RFC PATCH] virtio-iommu: Add PAGE_SIZE_MASK property
Message-Id: <20200323133831.2110014-1-jean-philippe(a)linaro.org>
Added: <2020-03-27 Fri>
* [virtio-dev] [PATCH v2 00/10] virtio-mem: paravirtualized memory
Message-Id: <20200311171422.10484-1-david(a)redhat.com>
Added: <2020-03-27 Fri>
--
Alex Bennée
Progress:
* VIRT-65 [QEMU upstream maintainership]
- More freeze related wrangling...
* VIRT-241 [QEMU ISA Support for A-profile]
- pushed the ARMv8.2-TTS2UXN patchset out to the mailing list
- found and fixed a bug in our PAN support where we were making
PSTATE.PAN forbid execute access, not just data access
* VIRT-364 [QEMU support for ARMv8.1-M extensions]
- Started on some preliminary refactoring that we'll need so we can
more conveniently modify the decoder for v8.1M: converting the
A32/T32 Neon decoder to use decodetree. I've done the "post-v8.0
extensions" instructions, and started on the loads-and-stores.
thanks
-- PMM
Hi,
We are having some serious problems after we upgraded from C++14 to C++17
on an Jetson TX2 ARM device. Our system tests started to behave differently
and fail.
It seems that when our application uses a library (also developed by us)
some data gets corrupted when delivered to a class constructor. For
example, the .second of and std::pair<float> appears to be the .first and
the .second is garbage. This is deterministic, but different tests are
failing depending on the combination: library C++17/C++14 <-> application
C++14/C++17.
This is on Ubuntu 18.04 and gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04).
Nothing like this happens on Intel.
So:
ARM, C++14: OK
Intel, C++14: OK
ARM, C++17: FAIL
Intel, C++17: OK
Any ideas what could cause this? I know this is a bit vague, but this a
commercial, closed-source application so I cannot yet give any other
information.
BR,
Jussi Lind
[VIRT-349 # QEMU SVE2 Support ]
Posted the first incremental patch set
for review, as requested by Qualcomm.
[VIRT-327 # Richard's upstream QEMU work ]
Patch review, much of it 5.0 related,
but also v6 of the riscv vector patch set.
Revise the PIE and linkage patch set.
r~
== Progress ==
* GCC upstream validation:
- reported a couple of failures/regressions
* GCC:
- comparing testsuite results for cortex-m3 and cortex-m33 with
cortex-a9 to check what cortex-M problem there are. Fixed a few
testcases. Managed to use qemu-system-arm to run cortex-m33 code with
CMSE features. (Thanks to Peter Maydell for the help!)
* misc:
- infra fixes / troubleshooting / reviews
== Next ==
* FDPIC GDB
* GCC/cortex-M