... and apologies for tomorrow's meeting.
[VIRT-344 # ARMv8.5-MemTag, Memory Tagging Extension ]
Updated the branch, both system and user.
There's a report of an assertion failure in system mode, but no testcase to go
with it. I need to ping for a devel branch with which to play.
[VIRT-349 # QEMU SVE2 Support ]
Some prerequisites merged upstream.
[VIRT-327 # Richard's upstream QEMU work ]
Review of risc-v risu patches.
r~
VirtIO Related Work ([VIRT-366])
================================
- virtio sync-up call see minutes Message-Id:
<87a72j64gt.fsf(a)linaro.org>
[VIRT-366] <https://projects.linaro.org/browse/VIRT-366>
VirtIO RPMB ([VIRT-371])
- continued work on my vhost-user-rpmb daemon
- vhost-user-rpmb plumbed in with QEMU and virtio-pci transport
- detected in lspci and comms established \\o/
- started experimenting with front-ends from ACRN linux port
- currently blows up on feature negotiation
- asked for clarification of divergence between ACRN and OASIS
spec Message-Id: <87sgga4daf.fsf(a)linaro.org>
[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])
- still TODO new work and architectures
- bit of writers block on last couple of paragraphs
[LBO-2] <https://projects.linaro.org/browse/LBO-2>
Upstream Work ([VIRT-109])
==========================
- posted [PULL 00/14] testing and gdbstub updates Message-Id:
<20200506120529.18974-1-alex.bennee(a)linaro.org>
[VIRT-109] <https://projects.linaro.org/browse/VIRT-109>
Completed Reviews [1/1]
=======================
[PATCH 0/4] softfloat: fix floatx80 emulation bugs
Message-Id: <alpine.DEB.2.21.2005010034560.30535(a)digraph.polyomino.org.uk>
--
Alex Bennée
(Short week, 4 days.)
Progress:
* VIRT-65 [QEMU upstream maintainership]
- Added brief documentation of some of the QEMU models of Arm
devboards, now we have a better place for this info to live
* VIRT-364 [QEMU support for ARMv8.1-M extensions]
- Fixed https://bugs.launchpad.net/bugs/1877136 (we were not using
the right gdb XML feature for M-profile CPUs, which meant that
stack backtraces across an exception stack frame didn't work and
we didn't report the XPSR to gdb correctly)
- Started working through code review responses from rth to the
first lot of neon-decodetree patches
thanks
-- PMM
Short week (4 days)
== Progress ==
* GCC upstream validation:
- Added gcc-10 branch
- maybe we should agree on a common way of running the testsuite
* GCC:
- PR94743 (IRQ handler and Neon registers): iterating. Refining patch
that emits a warning (testsuite refinements...), Need to update
additional patch that actually saves the FP regs so that it takes the
D16/D32 versions into account.
* misc:
- infra fixes / troubleshooting / reviews
- looking at cortex-m benchmarking harnesses, issues with openocd
== Next ==
* GCC validation matrix updates
* PR94743
* GCC/cortex-M testing
* cortex-m benchmarking
* FDPIC GDB
Hi, Chris, and Linaro Toolchain team,
Recently I found an issue of SVE intrinsics (svld1_f64, svld1_vnum_f64)
when using gcc -O0 (gcc 10.0.1 debian nightly build, optimization level 0).
Would you please help me to reach out to people who can fix it?
svld1_f64() is a function defined in Arm intrinsics for SVE (scalable
vector extensions) [2].
Changing -O0 to -O1 makes the issue disappear.
svld1_vnum_f64() has the same problem.
To show the issue, I wrote this simple test program, see test1.c in [1]. A
full issue report and gcc version string can be found in the attached pdf
file.
[1] My test program:
https://github.com/docularxu/sve-code-test/tree/working-svld1_f64
[2] Arm SVE intrinsics: https://developer.arm.com/docs/100987/latest
Feel free to contact me if you need more details.
Best regards,
-Guodong Xu
[VIRT-349 # QEMU SVE2 Support ]
More progress on insn implementation; just about done with all of the indexed
multiply. Perhaps 10 insns remaining.
Assad mentioned on irc that he has fixed the Armie bug that prevented RISU from
running properly, so I hope to start doing some testing soon.
[VIRT-327 # Richard's upstream QEMU work ]
Reviewed Peter's decodetree conversion. Posted some extracts from my sve2
branch that may be relevant and helpful.
r~
Progress:
* VIRT-65 [QEMU upstream maintainership]
- code review:
+ rth's v3 patchset for 'sve load/store improvements'
+ Paolo's improvements to my run-coverity-scan script
- tagged QEMU 5.0 and pushed it out of the door; put together and
sent out the first target-arm pullreq for the 5.1 cycle
* VIRT-364 [QEMU support for ARMv8.1-M extensions]
- Neon decodetree progressing nicely (though it is a bigger
job than I had anticipated when I started it...) Sent out a
first part patchset that covers the v8.0-and-later extensions,
the loads-and-stores, and the 3-reg-same part of the dp insns.
NB: UK bank holiday next Friday...
thanks
-- PMM
Hi,
You are receiving this email because you are listed as the owner for at least one LLVM build slave on http://lab.llvm.org:8011/buildslaves <http://lab.llvm.org:8011/buildslaves>.
This message is a heads up concerning the upcoming upgrade of CMake discussed here: http://lists.llvm.org/pipermail/llvm-dev/2020-March/140349.html <http://lists.llvm.org/pipermail/llvm-dev/2020-March/140349.html>. As discussed on that thread, LLVM will require CMake 3.13.4 in order to build after the release branch for LLVM 11.0.0 is created. Using an older CMake will be an error.
In order to keep things running smoothly, we would greatly appreciate if you could upgrade CMake on your builder(s) to at least CMake 3.13.4 before the next release branch is created. Please reply privately to this email when you've done so -- this will allow keeping track of who has and has not upgraded.
Thank you and have a wonderful day,
Louis
Short week (4 days)
== Progress ==
* GCC upstream validation:
- reported a couple of failures/regressions
- still looking at improving MVE tests to avoid failures in several
non-supported configurations. No satisfactory solution so far (there
are always combinations of GCC configure option and validation-time
options that are incompatible and produce failures instead of
unsupported)
- maybe we should agree on a common way of running the testsuite
* GCC:
- PR94743 (IRQ handler and Neon registers): sent a patch to emit a
warning. More ambitious patches would be too intrusive for stage 4.
* FDPIC/GDB:
- no progress this week
* misc:
- infra fixes / troubleshooting / reviews
- started looking at cortex-m benchmarking harnesses
== Next ==
* FDPIC GDB
* GCC/cortex-M
* cortex-m benchmarking
== Progress ==
* Morello
- Finished capability formatting
- Got a couple cosmetic patches in review
- Also reviewing needed ptrace support
== Plan ==
* More Morello
[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