[VIRT-344 # ARMv8.5-MemTag, Memory Tagging Extension ]
Posted v7 of system mode
Posted v2 of user mode vs in-progress kernel abi.
Some bug fixing for Stephen and Szabolcs.
[VIRT-349 # QEMU SVE2 Support ]
Started reviewing Stephen's sve2 risu patches.
[VIRT-327 # Richard's upstream QEMU work ]
A fair amount of patch review
New version of decodetree exclusive groups.
Some work on clang 10 werrors.
r~
Short week (1.5 day off)
== Progress ==
* GCC upstream validation:
- scripts updates and cleanup for cortex-m33 with qemu-system-mode
- reported a few regressions
* GCC:
- PR94743 (IRQ handler and Neon registers): No feedback yet.
* misc:
- infra fixes / troubleshooting / reviews
- looking at cortex-m benchmarking harnesses, at last able to run
coremark stm32 board
== Next ==
* GCC validation
- switch to qemu-system-mode for cortex-m33, in order to run the cmse tests
* PR94743
* GCC/cortex-M testing
* cortex-m benchmarking
* FDPIC GDB
== Progress ==
* GCC upstream validation:
- scripts updates and cleanup
- new scheme for arm-eabi now in production (cortex-a7 in arm and
thumb modes, cortex-m[0347,33]
- upgraded to qemu-5.0
- reported a few regressions
* GCC:
- PR94743 (IRQ handler and Neon registers): No feedback yet.
* misc:
- infra fixes / troubleshooting / reviews
- looking at cortex-m benchmarking harnesses, at last able to run a
sample code on my small stm32 board
- internal meetings / paperwork
== Next ==
* GCC validation
- switch to qemu-system-mode for cortex-m33, in order to run the cmse tests
* PR94743
* GCC/cortex-M testing
* cortex-m benchmarking
* FDPIC GDB
[VIRT-339 # ARMv8.5-BTI, Branch Target Identification ]
Updated to match the latest kernel for-next/bti-user branch; I hope this is
going to be merged for 5.7.
Posted v9 for review.
[VIRT-349 # QEMU SVE2 Supprt ]
More RISU work to improve support for SVE. Stephen Long has posted some sve2
risu patterns that need reviewing, and I plan to test all of that next week vs
ArmIE.
I had a start on rebasing my current sve2 patch set on master, with lots of
prereqs merged. But stopped in the middle because I realized that I wanted to
get all of the RISU work done first, so that I can test each patch as it is
updated.
r~
PS: Out all next week on holiday.
Progress:
* VIRT-65 [QEMU upstream maintainership]
- Various bits of code review; put together and sent another
arm pullreq.
* VIRT-364 [QEMU support for ARMv8.1-M extensions]
- Fixed up the 2-reg-shift/1-reg-imm patchset as per code review
comments and sent a v2
thanks
-- PMM
[VIRT-344 # ARMv8.5-MemTag, Memory Tagging Extension ]
Some prerequisites merged upstream.
[VIRT-349 # QEMU SVE2 Support ]
Some prerequisites merged upstream.
Work on risu to compress sve output files.
Split out the crypto conversion to gvec.
[VIRT-327 # Richard's upstream QEMU work ]
Posted some softfloat cleanups.
Some patch review.
Support non-overlapping regions for decodetree.
r~
VirtIO Related Work ([VIRT-366])
================================
VirtiIO blogpost ([LBO-2])
- finished final version of draft with future work and call to action
[LBO-2] <https://projects.linaro.org/browse/LBO-2>
Upstream Work ([VIRT-109])
==========================
- posted [PATCH v1 0/8] plugins/next (cleanup, cpu_index and lockstep)
Message-Id: <20200513173200.11830-1-alex.bennee(a)linaro.org>
- posted [PATCH v1 00/10] testing and tcg tweaks Message-Id:
<20200513175134.19619-1-alex.bennee(a)linaro.org>
- posted [PULL v2 00/13] testing, tcg and plugin updates Message-Id:
<20200515144405.20580-1-alex.bennee(a)linaro.org>
[VIRT-109] <https://projects.linaro.org/browse/VIRT-109>
Completed Reviews [9/9]
=======================
[PATCH 0/4] softfloat: fix floatx80 emulation bugs
Message-Id: <alpine.DEB.2.21.2005010034560.30535(a)digraph.polyomino.org.uk>
[PATCH v2 0/4] softfloat: fix floatx80 emulation bugs
Message-Id: <alpine.DEB.2.21.2005042332380.22972(a)digraph.polyomino.org.uk>
- CLOSING NOTE [2020-05-11 Mon 08:16]
rth already pulled into his tree
Added: <2020-05-05 Tue>
[PATCH v4 00/10] tests/vm: Add support for aarch64 VMs
Message-Id: <20200312142728.12285-1-robert.foley(a)linaro.org>
- CLOSING NOTE [2020-05-11 Mon 10:22]
Generally looks ok but awaiting v11 to deal with re-base conflicts
to fully test.
Added: <2020-03-27 Fri>
[PATCH v8 00/74] per-CPU locks
Message-Id: <20200326193156.4322-1-robert.foley(a)linaro.org>
- CLOSING NOTE [2020-05-12 Tue 19:39]
A few minor comments but looking good. Ran stress testing.
Added: <2020-03-27 Fri>
[PATCH 0/3] plugins: Move declarations around and rename 'hwaddr' argument
Message-Id: <20200510171119.20827-1-f4bug(a)amsat.org>
- CLOSING NOTE [2020-05-12 Tue 19:45]
Queued to my tree
Added: <2020-05-10 Sun>
[PATCH 3/3] plugins: avoid failing plugin when CPU is inited several times
Message-Id: <CAEme+7FPF+inSJSXQPmuv8Up3Eam0N7fT03zqM-RvcvKsxjfVQ(a)mail.gmail.com>
- didn't apply but found bug in cpu_index code
[PATCH 0/5] docs/system: Document some arm board models
Message-Id: <20200507151819.28444-1-peter.maydell(a)linaro.org>
[PATCH v6 0/9] tests/vm: Add support for aarch64 VMs
Message-Id: <20200512193340.265-1-robert.foley(a)linaro.org>
- CLOSING NOTE [2020-05-15 Fri 18:31]
Ran into problems testing on my Gentoo box, sent some patches to
rf-fw
Added: <2020-05-12 Tue>
[PATCH 0/5] target/i386: fxtract, fscale fixes
Message-Id: <alpine.DEB.2.21.2005070038550.18350(a)digraph.polyomino.org.uk>
- CLOSING NOTE [2020-05-15 Fri 18:32]
Testing bit looks ok, leaving the x86 side to people that understand
it.
Added: <2020-05-15 Fri>
--
Alex Bennée
== Progress ==
* GCC upstream validation:
- reported a couple of regressions
- sent an email to discussed the preferred combinations when running
the testsuite
* GCC:
- PR94743 (IRQ handler and Neon registers): iterating. Sent updated
patch to emit a warning. Cleanup patches merged. Sent WIP patch that
saves FP regs for discussion.
* 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
Progress:
* VIRT-65 [QEMU upstream maintainership]
- Some patch review/pullreq handling. Notably, the patchset to
allow AArch64 KVM hosts to report host memory errors to guests
is now in master.
* VIRT-364 [QEMU support for ARMv8.1-M extensions]
- Sent out v2 of the neon-decodetree conversion patches (covering
the 3-reg-same grouping); this is based on RTH's vector cleanup
patchset. Got this reviewed and into master.
- Sent out a conversion patchset for 2-reg-and-shift and
1-reg-and-immediate insn groups.
thanks
-- PMM
== Progress ==
* Out of office tomorrow (Friday)
* Morello - looking into some unrelated failures after a merge from upstream
* Morello - updating aadwarf spec
== Plan ==
* Out of office next Thursday and Friday
... 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
