[VIRT-339 # ARMv8.5-BTI, Branch Target Identification ]
Posted v6. Some review from Dave Martin; will need at least
one further revision, and to wait til the kernel patches land.
[VIRT-327 # Richard's upstream QEMU work ]
Fix a reported bug in pauth Auth results.
Fix a reported bug in vector variable shift.
Review Peter's vfp decodetree patch set.
Review of v18 of target/rx. Never-ending, it seems...
Review of some target/ppc vector patches.
Posted v4 of CPUNegativeOffsetState. This looks ready to pull.
r~
Upstream Work ([VIRT-109])
==========================
- spent ages tracking down 64-on-32 cputlb errors which led to:
- adding x86_64 support to TCG system tests
- {PATCH v1 0/4} softmmu de-macro fix with tests Message-Id:
<20190605162326.13896-1-alex.bennee(a)linaro.org>
- {PATCH} cputlb: cast size_t to target_ulong before using for
address masks Message-Id:
<20190606154310.15830-1-alex.bennee(a)linaro.org>
- took over maintainership of orphaned gdbstub
- posted {PULL 00/52} testing, gdbstub and cputlb fixes Message-Id:
<20190607090552.12434-1-alex.bennee(a)linaro.org>
- problems on hackbox lead to {PATCH} tests/vm: favour the locally
built QEMU for bootstrapping Message-Id:
<20190607185337.14524-1-alex.bennee(a)linaro.org>
[VIRT-109] https://projects.linaro.org/browse/VIRT-109
Other Tasks
===========
- Did some initial reading on RPMB
- Half day fire training
Absences
========
- May 27th is a Bank Holiday
- May 31st working on train in the afternoon
Current Review Queue
====================
* {Qemu-devel} {PATCH v4 00/39} tcg: Move the softmmu tlb to CPUNegativeOffsetState
Message-Id: <20190604203351.27778-1-richard.henderson(a)linaro.org>
* {Qemu-devel} {PATCH v2} target/arm: Vectorize USHL and SSHL
Message-Id: <20190603232209.20704-1-richard.henderson(a)linaro.org>
* {Qemu-devel} {PATCH resend} test-thread-pool: be more reliable
Message-Id: <20190530093417.23370-1-pbonzini(a)redhat.com>
* {PATCH 0/4} tests/docker: add podman support
Message-Id: <20190523234011.583-1-marcandre.lureau(a)redhat.com>
* {Qemu-devel} {PATCH 0/2} Implement PowerPC FPSCR flag Fraction Rounded
Message-Id: <20190525022008.24788-1-programmingkidx(a)gmail.com>
* {Qemu-devel} {PATCH for-4.1 v2 00/36} tcg: Move the softmmu tlb to CPUNegativeOffsetState
Message-Id: <20190328230404.12909-1-richard.henderson(a)linaro.org>
--
Alex Bennée
[LLVM-122] BTI and PAC support
Committed the LLD work. Modulo bugs this should now be done.
[LLVM-542] LLVM/GCC code size investigation
- Revisited my Zephy build with clang patches and updated so that it
works with trunk.
- Work out next steps of work.
- Work out to build an embedded gcc toolchain using the linaro infrastructure.
[Misc]
Reported bug in gold whereupon it would generate v4t veneers for v8-a CPUs
Still waiting for TK-1 board to finish building clang so that it can
run the testsuite. Hopefully finished over the weekend.
Progress:
* VIRT-65 [QEMU upstream maintainership]
+ Got the VFP decodetree conversion patchset out for review
(42 patches, 8 files changed, 3024 insertions(+), 1476 deletions(-))
+ sent a patchset which does the (easy) first step in my plan
for converting QEMU's documentation to Sphinx; sadly all the other
steps are much trickier...
thanks
-- PMM
== Progress ==
* FDPIC
- GCC: No progress, still waiting for feedback
* GCC upstream validation:
- reported a few regressions.
* GCC:
- UBSAN/bare-metal: added sync primitives implementation for low-end
cores (eg cortex-m0) Seems OK
- noinit attribute: started work
* Infra
- Fixed Dejagnu configuration issue in ABE which prevented us from
using target variant specifications
- Investigated problems with ABE and failure to cross-build "recent"
glibc (trouble with C++ compiler detection). ABE patches under review.
- Reduced load on APM machines to avoid depending on them too much
== Next ==
GCC:
- handle feedback on FDPIC patches
- noinit attribute
- UBSAN/bare-metal: do more testing
Hi,
Food for thought for today's sync up. I've been writting QEMU plugins to
exercise the plugin system and see what sort of useful information you
can extract when you can control the instruction stream.
For example I now have a plugin that can break down instruction counts
for any given run, for example a kernel boot:
Instruction Classes:
Class: UDEF not counted
Class: SVE (68 hits)
Class: Reserved (0 hits)
Class: PCrel addr (4589078 hits)
Class: Add/Sub (imm,tags) (0 hits)
Class: Add/Sub (imm) (26832113 hits)
Class: Logical (imm) (74304974 hits)
Class: Move Wide (imm) (10933759 hits)
Class: Bitfield (71470957 hits)
Class: Extract (85655 hits)
Class: Data Proc Imm (0 hits)
Class: Cond Branch (imm) (37227632 hits)
Class: Exception Gen (6 hits)
Class: NOP not counted
Class: Hints (244825554 hits)
Class: Barriers (1668558 hits)
Class: PSTATE (202144 hits)
Class: System Insn (7132992 hits)
Class: System Reg (2268308 hits)
Class: Branch (reg) (6280976 hits)
Class: Branch (imm) (18347905 hits)
Class: Cmp & Branch (180167025 hits)
Class: Tst & Branch (4092972 hits)
Class: Branches (0 hits)
Class: AdvSimd ldstmult (0 hits)
Class: AdvSimd ldstmult++ (0 hits)
Class: AdvSimd ldst (0 hits)
Class: AdvSimd ldst++ (0 hits)
Class: ldst excl (160861365 hits)
Class: Prefetch (0 hits)
Class: Load Reg (lit) (12828544 hits)
Class: ldst noalloc pair (0 hits)
Class: ldst pair (60381349 hits)
Class: ldst reg (0 hits)
Class: Atomic ldst (0 hits)
Class: ldst reg (reg off) (0 hits)
Class: ldst reg (pac) (0 hits)
Class: ldst reg (imm) (119597941 hits)
Class: Loads & Stores (0 hits)
Class: Data Proc Reg (113586343 hits)
Class: Scalar FP (0 hits)
Class: Unclassified (0 hits)
You can break down each class to individual instructions. For example
the Hints are mostly:
Individual Instructions:
Instr: wfe (132400072 hits) (op=0xd503205f/ Hints)
Instr: sevl (66433640 hits) (op=0xd50320bf/ Hints)
Instr: yield (29619246 hits) (op=0xd503203f/ Hints)
Instr: wfi (2865 hits) (op=0xd503207f/ Hints)
So I'm looking for a similar experiment that would be useful for the
memory sub-system. When I chatted to Maxim we thought maybe a simplified
cache line simulator might be useful. The aim wouldn't be to simulate
what a real cache might do but to be useful say for identifying regions
of code which might be susceptible to cache line bouncing. So as
compiler writers what sort of run time memory behaviour would you like
to track? What sort of information would be useful to extract with such
a tool?
I'm open to ideas ;-)
--
Alex Bennée
Four day week.
[VIRT-327 # Richard's upstream QEMU work ]
Reviewed s390 fp vector patch set.
Posted v16 rx. This seemed so close to being ready
last week, but now I don't know. I think I should
quit pushing it myself and let Yoshinori do more of
the lifting here.
Reviewed avr v20 patch set.
Reviewed Alex's testing patch set.
Submitted patches to constify upstream capstone
(500k from .data to .rodata).
r~
Short week (off Thursday/Friday)
== Progress ==
* FDPIC
- GCC: No progress, still waiting for feedback
* GCC upstream validation:
- reported a few regressions / fixed some testcases
* GCC:
- UBSAN/bare-metal: added sync primitives implementation for low-end
cores (eg cortex-m0) Seems OK
* Infra
- cleanup
- handling some problems with boards upgrades and crashes
== Next ==
FDPIC:
- GCC: handle feedback
UBSAN/bare-metal: do more testing
== This Week ==
* PR88837 (7/10)
- Addressed all upstream suggestions.
- Found a (hackish) way to test patch with qemu (multiple issues).
- Sorting thru "strange" testsuite fallout most of which seems
unrelated to my patch.
* PR88833 (2/10)
- Looking at fwprop pass
* Misc (1/10)
- Meetings
== Next Week ==
- Continue ongoing tasks.
