Progress:
* VIRT-65 [QEMU upstream maintainership]
+ usual release cycle work
+ Our Coverity-Scan issues had been left untended a bit too long:
went through them doing triage, reporting them back to patch
submitters, and writing a few fixes for some of the easy ones
+ That took me down a rabbit-hole of fixing some issues with our
sparc64 usermode emulation so I could demonstrate that the coverity
fixes hadn't broken anything...
thanks
-- PMM
hi all
I am announcing updates in the implementation of branch tracing using
coresight etm in GDB. in this update, functions and instruction history
are running successfully on single threaded applications. reverse
debugging is basically working with the limitation that sometimes cspr
register (register 25) is required but current implementation does not
provide it.
the feature requires linux kernel v 4.19 or higher with manual etm sink
setup. 5.9.1 or higher for automatic sink selection.
GDB gdb.btrace test suite was adapted to run on arm processors. here is
the summary of the gdb.btrace test results executed on an STM32MP157
(ARM cortex A7) with Linux kernel 5.9.1
=== gdb Summary ===
# of expected passes 390
# of unexpected failures 119
# of unsupported tests 4
following tests are 100% successful:
- buffer-size
- enable
- instruction_history
- function_call_history
- data
- delta
- cpu
- gcore
- record_goto-step
- dlopen
- vdso
- segv
GDB source code is available on
https://github.com/gzied/binutils-gdb/tree/gdb_arm_coresight
many thanks to GDB and linaro communities for their support
Kind Regards
Zied Guermazi
hi
Thanks Mike for your support, it was very helpful.
to put everything together, on arm, gdb inserts a sw breakpoint by
patching the code with an undefined instruction ( see comments in
arm-tdep.c line7687) when a breakpoint is hit, an exception number 9
"Undefined Instruction exception" is raised and a branch packet with
this info is generated in etm traces, the trap is get handled by the
kernel and it sends the appropriate signal to gdb process.
when the user continues the execution, gdb patches back the code and
executes the instruction. this leads to the instruction traced twice
with an exception in between, the same happens for next executed instruction
here is the log of decoded packets
[btrace] [ftrace] update insn: fun = main, file =
./function_call_history.c, level = 0, insn = [1; 2)
cs_etm_decoder_trace_element_callback: elem->elem_type
OCSD_GEN_TRC_ELEM_INSTR_RANGE */<= first execution attempt that raises
an undefined instruction exception/*
trace_chan_id: 18
isa: CS_ETM_ISA_T32
start addr = 0x400534
end addr = 0x400536
instructions count = 1
last_i_type: OCSD_INSTR_OTHER
last_i_subtype: OCSD_S_INSTR_NONE
last instruction was executed
last instruction size: 2
[btrace] [ftrace] update insn: fun = main, file =
./function_call_history.c, level = 0, insn = [1; 3)
cs_etm_decoder_trace_element_callback: elem->elem_type
OCSD_GEN_TRC_ELEM_EXCEPTION */<= the exception is traced/*
trace_chan_id: 18
exception number: 9 */<= undefined instruction exception/*
cs_etm_decoder_trace_element_callback: elem->elem_type
OCSD_GEN_TRC_ELEM_TRACE_ON
cs_etm_decoder_trace_element_callback: elem->elem_type
OCSD_GEN_TRC_ELEM_PE_CONTEXT
cs_etm_decoder_trace_element_callback: elem->elem_type
OCSD_GEN_TRC_ELEM_INSTR_RANGE */<= execution of the original instruction/*
trace_chan_id: 18
isa: CS_ETM_ISA_T32
start addr = 0x400534
end addr = 0x400536
instructions count = 1
last_i_type: OCSD_INSTR_OTHER
last_i_subtype: OCSD_S_INSTR_NONE
last instruction was executed
last instruction size: 2
as the code was changed during execution, it can not be reconstructed
during traces decoding.
in addition, and for tracing applications running on Linux, we are not
interested in capturing raised exceptions, we can consider rolling back
last instruction in ftraces. As this is not obvious, we can consider
ignoring the repeated instruction as a workaround.
for tracing bare metal software, we need to keep tracing exception, so
we can have a flag for ignoring exceptions, and activate or dis-activate
it according to the context.
what do you think about it, shall I go for implementing it as described
above?
Kind Regards
Zied Guermazi
On 02.11.20 12:59, Mike Leach wrote:
> Hi Zeid,
>
> On Sat, 31 Oct 2020 at 23:11, Zied Guermazi <zied.guermazi(a)trande.de> wrote:
>> hi,
>>
>> while testing the implementation in gdb of branch tracing on arm
>> processors using etm, I faced the the situation where a breakpoint was
>> set, was hit and then the execution of the program was continued. While
>> decoding generated traces, I got the address of the breakpoint
>> (0x400552) executed twice, and then the following address (0x400554)
>> also executed twice. the instruction at (0x400554) is a BL ( a function
>> call) and the second execution corrupts the function history.
>>
>> here is a dump of generated trace elements
>>
>>
>> ---------------------------------
>> trace_chan_id: 18
>> isa: CS_ETM_ISA_T32
>> start addr = 0x400552
>> end addr = 0x400554
>> instructions count = 1
>> last_i_type: OCSD_INSTR_OTHER
>> last_i_subtype: OCSD_S_INSTR_NONE
>> last instruction was executed
>> last instruction size: 2
>> ---------------------------------
>> trace_chan_id: 18
>> isa: CS_ETM_ISA_T32
>> start addr = 0x400552
>> end addr = 0x400554
>> instructions count = 1
>> last_i_type: OCSD_INSTR_OTHER
>> last_i_subtype: OCSD_S_INSTR_NONE
>> last instruction was executed
>> last instruction size: 2
>> ---------------------------------
>> trace_chan_id: 18
>> isa: CS_ETM_ISA_T32
>> start addr = 0x400554
>> end addr = 0x400558
>> instructions count = 1
>> last_i_type: OCSD_INSTR_BR
>> last_i_subtype: OCSD_S_INSTR_BR_LINK
>> last instruction was executed
>> last instruction size: 4
>> ---------------------------------
>> trace_chan_id: 18
>> isa: CS_ETM_ISA_T32
>> start addr = 0x400554
>> end addr = 0x400558
>> instructions count = 1
>> last_i_type: OCSD_INSTR_BR
>> last_i_subtype: OCSD_S_INSTR_BR_LINK
>> last instruction was executed
>> last instruction size: 4
>>
>> the explanation I have for this behavior is that :
>>
>> -when setting the software breakpoint, the memory content of the
>> instruction (at 0x400552) was altered to the instruction BKPT,
>>
>> -when the breakpoint was hit, the original opcode was set at (0x400552)
>> and a BKPT was set to the next instruction address (0x400554), then the
>> execution was continued
>>
>> -when the second breakpoint (0x400554) was hit, the a BKPT opcode was
>> set at (0x400552) and the original opcode was set at (0x400554) then the
>> execution was continued
>>
>> I am using the function "int target_read_code (CORE_ADDR memaddr,
>> gdb_byte *myaddr, ssize_t len)" to give program memory content to the
>> decoder. so the collected etm traces are correct, but, as memory was
>> altered in between, the decoder is "cheated".
>>
>> I need to identify the re-execution of code due to breakpoint handling,
>> and roll back its impact on etm decoding.
>>
>> is there a mean to get the actual content of program memory including
>> patched addresses?
>>
>> is there a means of getting the history of patched addresses during the
>> debugging of a program?
>>
>> what is the type and subtype of a BKPT instruction in a decoded trace
>> elements?
>>
> I can only really comment on this question. The type / subtype
> information in the output from the decoder is generated from the
> decoder walking the memory image of the executed trace - not from the
> trace packets themselves.
> The decoder classifies instructions according to how they will affect
> trace flow with the "other" category being set for the majority of
> instructions. The categories are: other, branch, indirect branch, ISB
> / DSB / DMB / WFI / WFE.
> These are important in program flow trace (PTM 1.x, ETM 4.x) as these
> determine which instruction we attach the E/N atoms to. BKPT will be
> classified as "other", if it is seen, as it has no effect on normal
> program flow. It will cause an exception which has a specific trace
> packet format.
>
> Regards
>
> Mike
>
>
>> do you have any other idea for handling this situation?
>>
>>
>> I am attaching the source code of the program as well as the
>> disassembled binary. the code was compiled as an application running on
>> linux on an ARMv7 A (STM32MP157 SoC). the breakpoint was set at line 43
>> in the source code (line 238 in the disassembled code)
>>
>>
>> Kind Regards
>>
>> Zied Guermazi
>>
>> _______________________________________________
>> CoreSight mailing list
>> CoreSight(a)lists.linaro.org
>> https://lists.linaro.org/mailman/listinfo/coresight
>
>
hi,
while testing the implementation in gdb of branch tracing on arm
processors using etm, I faced the the situation where a breakpoint was
set, was hit and then the execution of the program was continued. While
decoding generated traces, I got the address of the breakpoint
(0x400552) executed twice, and then the following address (0x400554)
also executed twice. the instruction at (0x400554) is a BL ( a function
call) and the second execution corrupts the function history.
here is a dump of generated trace elements
---------------------------------
trace_chan_id: 18
isa: CS_ETM_ISA_T32
start addr = 0x400552
end addr = 0x400554
instructions count = 1
last_i_type: OCSD_INSTR_OTHER
last_i_subtype: OCSD_S_INSTR_NONE
last instruction was executed
last instruction size: 2
---------------------------------
trace_chan_id: 18
isa: CS_ETM_ISA_T32
start addr = 0x400552
end addr = 0x400554
instructions count = 1
last_i_type: OCSD_INSTR_OTHER
last_i_subtype: OCSD_S_INSTR_NONE
last instruction was executed
last instruction size: 2
---------------------------------
trace_chan_id: 18
isa: CS_ETM_ISA_T32
start addr = 0x400554
end addr = 0x400558
instructions count = 1
last_i_type: OCSD_INSTR_BR
last_i_subtype: OCSD_S_INSTR_BR_LINK
last instruction was executed
last instruction size: 4
---------------------------------
trace_chan_id: 18
isa: CS_ETM_ISA_T32
start addr = 0x400554
end addr = 0x400558
instructions count = 1
last_i_type: OCSD_INSTR_BR
last_i_subtype: OCSD_S_INSTR_BR_LINK
last instruction was executed
last instruction size: 4
the explanation I have for this behavior is that :
-when setting the software breakpoint, the memory content of the
instruction (at 0x400552) was altered to the instruction BKPT,
-when the breakpoint was hit, the original opcode was set at (0x400552)
and a BKPT was set to the next instruction address (0x400554), then the
execution was continued
-when the second breakpoint (0x400554) was hit, the a BKPT opcode was
set at (0x400552) and the original opcode was set at (0x400554) then the
execution was continued
I am using the function "int target_read_code (CORE_ADDR memaddr,
gdb_byte *myaddr, ssize_t len)" to give program memory content to the
decoder. so the collected etm traces are correct, but, as memory was
altered in between, the decoder is "cheated".
I need to identify the re-execution of code due to breakpoint handling,
and roll back its impact on etm decoding.
is there a mean to get the actual content of program memory including
patched addresses?
is there a means of getting the history of patched addresses during the
debugging of a program?
what is the type and subtype of a BKPT instruction in a decoded trace
elements?
do you have any other idea for handling this situation?
I am attaching the source code of the program as well as the
disassembled binary. the code was compiled as an application running on
linux on an ARMv7 A (STM32MP157 SoC). the breakpoint was set at line 43
in the source code (line 238 in the disassembled code)
Kind Regards
Zied Guermazi
Progress:
* VIRT-65 [QEMU upstream maintainership]
+ more code review and assembly of the last pull request for
softfreeze for QEMU 5.2
+ noticed that our AArch32 Neon emulation doesn't work on big-endian
hosts. RTH fixed most of this and I wrote a couple of patches to
fix bugs in some insns that were only noticeable once we got out
of the "anything working on vectors is broken" state :-)
+ looked at trying to get our documentation to build with Sphinx 3,
which has made some annoying incompatible changes to the markup
it accepts
* VIRT-364 [QEMU support for ARMv8.1-M extensions]
+ started implementation of new insns VSCCLRM, CLRM, and
the new FP sysregs accessed via VLDR/VSTR
KVM Forum (virtual conference) was this week. Some interesting talks:
* Will Deacon on what Google is doing to introduce KVM into Android
* Marc Zyngier/Christoffer Dall on a virtual-only interrupt controller
that's less of a big lump of code to put on a security boundary than
a full-on GIC
* Salil Mehta on the current problems with doing Arm vCPU hotplug in KVM
thanks
-- PMM
VirtIO Initiative ([STR-9])
===========================
- Stratos sync call, discussion on AGL demo
- Google sync call
- Created a first cut of additional Xen work cards under [STR-16]
[STR-16] <https://projects.linaro.org/browse/STR-16>
VirtIO Portability Demo ([STR-13])
==================================
- Created a [branch with the experimental ioreq (virtio-mmio) support]
- developing understanding of the ioreq piece
- posted [PATCH] meson.build: fix building of Xen support for aarch64
Message-Id: <20201028174406.23424-1-alex.bennee(a)linaro.org>
- continued work and expanded into [branch to clean-up and add "virt"
machine]
[STR-13] <https://projects.linaro.org/browse/STR-13>
[branch with the experimental ioreq (virtio-mmio) support]
<http://git.linaro.org/people/alex.bennee/linux.git/shortlog/refs/heads/expe…>
[branch to clean-up and add "virt" machine]
<https://github.com/stsquad/qemu/tree/xen/add-xen-virt-machine>
Upstream Work ([QEMU-109])
==========================
- posted [PULL 0/8] testing and misc (gitdm, gitlab, docker, make)
Message-Id: <20201027095938.28673-1-alex.bennee(a)linaro.org>
[QEMU-109] <https://projects.linaro.org/browse/QEMU-109>
Other
=====
- KVM Forum 2020
Completed Reviews [2/2]
=======================
[PATCH 0/2] tcg: optimize across branches
Message-Id: <20201013222330.173525-1-richard.henderson(a)linaro.org>
[PATCH 00/15] remove bios_name variable
Message-Id: <20201026143028.3034018-8-pbonzini(a)redhat.com>
Absences
========
- Welsh lockdown next week
- Children at home
Current Review Queue
====================
* [PATCH 0/8] arm/virt: add usb support
Message-Id: <20201023071022.24916-1-kraxel(a)redhat.com>
Added: <2020-10-27 Tue>
* [PATCH 0/4] riscv: Add semihosting support [v10]
Message-Id: <20201026212853.92880-1-keithp(a)keithp.com>
Added: <2020-10-27 Tue>
* [PATCH v2 0/7] xen/arm: Unbreak ACPI
Message-Id: <20201023154156.6593-1-julien(a)xen.org>
Added: <2020-10-24 Sat>
* [PATCH v3 0/4] GitLab Custom Runners and Jobs (was: QEMU Gating CI)
Message-Id: <20201014052140.1146924-1-crosa(a)redhat.com>
Added: <2020-10-14 Wed>
--
Alex Bennée
* 2 days off
== Progress ==
* GCC upstream validation:
- reported several regressions/new failures
* GCC
- PR96767: patch accepted
- PR96770: patch accepted
- patch for C++ thunks with -mpure-code and cortex-m0: iterating, almost OK
- Neon intrinsics: vceqq, vceqz and vceqzq for p64 patch: no feedback
* benchmarking:
- Scripts to run coremark on stm32 now merged, debugging issues.
* infra:
- debugging issues with our docker containers
- added monitoring for disk space on dev machines
== Next ==
* GCC/cortex-M testing improvements & fixes
* cortex-m benchmarking
* MVE intrinsics improvements
[VIRT-327 # Richard's upstream QEMU work ]
More time than I expected on float128_muladd, adjusting the codebase to share
code with float64_muladd.
[VIRT-339 # ARMv8.5-BTI, Branch Target Identification ]
Posted v12, adjusting one of the smoke tests vs a distro linker bug (fixed in
mainline).
r~
VirtIO Initiative ([STR-9])
===========================
VirtIO RPMB ([STR-5])
=====================
- Synced with with Ulf/Illias on enhancements for eMMC stacks
- need to support 512 frames somehow for the CSD, everything else
should be fine
[STR-5] <https://projects.linaro.org/browse/STR-5>
VirtIO Portability Demo ([STR-13])
==================================
- More work on trying to get Xen working on MB
- more failures, this time GIC related. Might just stick to KVM
- Created a [branch with the experimental ioreq (virtio-mmio) support]
- Got Virgl based acceleration working on both TCG and KVM - so now
fast graphics!
- posted [PATCH v1 0/4] add guest-loader (for direct Xen boot)
Message-Id: <20201021170842.25762-1-alex.bennee(a)linaro.org>
[STR-13] <https://projects.linaro.org/browse/STR-13>
[branch with the experimental ioreq (virtio-mmio) support]
<http://git.linaro.org/people/alex.bennee/linux.git/shortlog/refs/heads/expe…>
Upstream Work ([QEMU-109])
==========================
- Some discussion on converting the final bits of 96/128 bit softfloat
- posted [RFC PATCH 0/8] fpu: experimental conversion of
float128_addsub Message-Id:
<20201020163738.27700-1-alex.bennee(a)linaro.org>
- partial reviewed [RFC PATCH 00/15] softfloat: alternate conversion
of float128_addsub Message-Id:
<20201021045149.1582203-1-richard.henderson(a)linaro.org>
- posted [PATCH v1 0/6] testing/next (gitdm, acceptance, docker,
gitlab) Message-Id: <20201021163136.27324-5-alex.bennee(a)linaro.org>
Other
=====
- reclaiming space for my gmail (98.5% used!)
Completed Reviews [1/1]
=======================
[PATCH 0/2] tcg: optimize across branches
Message-Id: <20201013222330.173525-1-richard.henderson(a)linaro.org>
Absences
========
- Welsh lockdown next week
- Children at home
Current Review Queue
====================
* [PATCH v3 0/4] GitLab Custom Runners and Jobs (was: QEMU Gating CI)
Message-Id: <20201014052140.1146924-1-crosa(a)redhat.com>
Added: <2020-10-14 Wed>
* [PATCH v6 0/5] Enable plugin support on msys2/mingw
Message-Id: <20201013002806.1447-1-luoyonggang(a)gmail.com>
Added: <2020-10-13 Tue>
* [PATCH v7 0/4] Improve cirrus msys2
Message-Id: <20201012233740.190-1-luoyonggang(a)gmail.com>
Added: <2020-10-13 Tue>
* [PATCH RFC 00/22] Support of Virtual CPU Hotplug for ARMv8 Arch
Message-Id: <20200613213629.21984-1-salil.mehta(a)huawei.com>
Added: <2020-09-23 Wed>
--
Alex Bennée
* 2 days off
== Progress ==
* GCC upstream validation:
- identified several regressions, but they had already been reported
* GCC
- PR96767: no feedback
- PR96770: no feedback
- patch for C++ thunks with -mpure-code and cortex-m0: handling
further feedback
- Neon intrinsics: vceqq, vceqz and vceqzq for p64 patch: no feedback
* benchmarking:
- Scripts to run coremark on stm32 now merged, debugging issues. No
progress this week.
* infra:
- debugging issues with our docker containers
== Next ==
* GCC/cortex-M testing improvements & fixes
* cortex-m benchmarking
* MVE intrinsics improvements
Hi,
I am new to toolchains. I would like to know information on building
toolchains for different architectures.
My objective is to build a cross compiling toolchain for AARCH64 BE
target on the RHEL7.6 build system. It would be great if you can give me
pointers on how to compile toolchains. Do we have any Wiki pages on
building linaro toolchains for different architectures?
Appreciate your help.
Regards
Suresh
== Progress ==
* GCC upstream validation:
- reported several regressions
- committed minor cleanup fixes
- fixed broken trunk build with gcc-4.8
* GCC
- PR96767: no feedback
- PR96770: no feedback
- patch for C++ thunks with -mpure-code and cortex-m0: sent updated patch
- Neon intrinsics: sent patch to implement vceqq, vceqz and vceqzq for p64.
* benchmarking:
- Scripts to run coremark on stm32 now merged, debugging issues. No
progress this week.
* infra:
- debugging issues with our docker containers
== Next ==
* GCC/cortex-M testing improvements & fixes
* cortex-m benchmarking
* MVE intrinsics improvements
Progress:
* VIRT-65 [QEMU upstream maintainership]
+ another round of code review and target-arm queue wrangling
+ found and fixed an edge-case bug in setting Q flag in SMLAD insn
+ fixed a GICv3 emulation bug where we didn't ever raise
maintenance interrupts
* VIRT-364 [QEMU support for ARMv8.1-M extensions]
+ went through Arm ARM and identified exactly what the "v8.1M changes
which aren't part of a named architectural feature" are (for
QEMU-409 subtask)
+ implemented some parts of NOCP handling that were left as TODO comments
for being v8.1M-specific
+ implemented conditional-select insns (CSEL, CSINC, CSINV, CSNEG)
+ implemented low-overhead-loops and branch-future (in the 'trivial'
don't-cache-anything way the architecture permits)
thanks
-- PMM
== Progress ==
* GCC upstream validation:
- reported several regressions
- committed minor cleanup fixes
- reduced the number of gcc-testresults emails to avoid too much traffic
* GCC
- PR96767: no feedback
- PR96770: no feedback
- patch for C++ thunks with -mpure-code and cortex-m0: received
comments, handling
- PR96914 MVE intrinsics: committed patches to remove a few illegal
ones and add the missing ones.
* benchmarking:
- Scripts to run coremark on stm32 now merged, debugging issues. No
progress this week.
== Next ==
* GCC/cortex-M testing improvements & fixes
* cortex-m benchmarking
* MVE intrinsics improvements
== Progress ==
* GCC upstream validation:
- reported several regressions
- committed minor cleanup fixes
- improved gcc-testresults email titles after discussion with other contributors
* GCC
- PR96767: patch sent
- PR96770: patch sent
- sent another patch to fix C++ thunks with -mpure-code and cortex-m0
- PR94595: patch committed
- looking at some problems with validating with PCH disabled
* benchmarking:
- Scripts to run coremark on stm32 now merged, debugging issues
== Next ==
* GCC/cortex-M testing improvements & fixes
* cortex-m benchmarking
* MVE intrinsics improvements
VirtIO Initiative ([STR-9])
===========================
VirtIO RPMB ([STR-5])
=====================
- some discussion about eMMC pass-through
[STR-5] <https://projects.linaro.org/browse/STR-5>
VirtIO Portability Demo ([STR-13])
==================================
- more debugging and tweaking for Xen
- rooting out ACPI and DT issues
- got working on QEMU TCG (with GICv2)
- testing Grub patches for MachiatoBin
- see state on MB Message-Id:
<01000174ea0b72ae-028e8625-0ead-4cb8-a429-49bd11b5bf30-000000(a)email.amazonses.com>
and state on TCG Message-Id: <87tuvcn067.fsf(a)linaro.org>
- verified sound and KVM working on MachatioBin
[STR-13] <https://projects.linaro.org/browse/STR-13>
Upstream Work ([QEMU-109])
==========================
- posted [PULL 00/14] testing updates (python, plugins) Message-Id:
<20201002113645.17693-1-alex.bennee(a)linaro.org>
[QEMU-109] <https://projects.linaro.org/browse/QEMU-109>
[various fixes] <https://github.com/stsquad/qemu/tree/testing/next>
Completed Reviews [1/1]
=======================
[PATCH v6 00/14] Reverse debugging
Message-Id: <160137726426.31007.12061315974029139983.stgit@pasha-ThinkPad-X280>
Current Review Queue
====================
* [PATCH v3 0/6] Enable plugin support on msys2/mingw
Message-Id: <20201001163429.1348-1-luoyonggang(a)gmail.com>
Added: <2020-10-01 Thu>
* [PATCH RFC 00/22] Support of Virtual CPU Hotplug for ARMv8 Arch
Message-Id: <20200613213629.21984-1-salil.mehta(a)huawei.com>
Added: <2020-09-23 Wed>
--
Alex Bennée
Progress:
* VIRT-65 [QEMU upstream maintainership]
+ Got a v6 series sent to the list of the conversion of QAPI
doc-comments into rST/Sphinx. This took most of the week,
following Markus' detailed review on the v5 (and involved
some wrestling with Meson). Optimistic that this can get into
master now...
thanks
-- PMM
[VIRT-349 # QEMU SVE2 Support ]
Posted v3, now tested vs armie.
[VIRT-327 # Richard's upstream QEMU work ]
Another round of capstone patches, still needs review.
r~
VirtIO Initiative ([STR-9])
===========================
- started reviewing [PATCH 00/11] Additional virtio device resources
Message-Id: <20200824143708.5664-6-ndragazis(a)arrikto.com>
- synced with Arnd and JPB on VirtIO work for [minimal memory profile
stuff]
[STR-9] <https://projects.linaro.org/browse/STR-9>
[minimal memory profile stuff]
<https://projects.linaro.org/browse/STR-8>
VirtIO RPMB ([STR-5])
=====================
- worked with Illias to get him up and running with uboot virtio-rpmb
driver
- debugging differences in HMAC implementations :-/
[STR-5] <https://projects.linaro.org/browse/STR-5>
VirtIO Portability Demo ([STR-13])
==================================
- continue to debug nouvaue issues on latest kernel
- need to ESC/reset to EFI until framebuffer comes on
- seems ok with Debian 5.6.14-2~bpo10+1
- but not vanilla 5.6.14 or above
- need to track down kernel differences
- did some poking into getting Xen up on Debian
- seems multiboot not the way, got a bit further but need a debug
build
[STR-13] <https://projects.linaro.org/browse/STR-13>
Upstream Work ([QEMU-109])
==========================
- posted [PATCH v1 0/6] deprecation and linux-user tweaks (+test fix)
Message-Id: <20200914150716.10501-5-alex.bennee(a)linaro.org>
- posted [PATCH v2 0/8] configure deprecation, linux-user and iotest
fixes Message-Id: <20200915134317.11110-1-alex.bennee(a)linaro.org>
- posted [PULL 0/8] configure deprecation, linux-user and test fix
Message-Id: <20200916122648.17468-1-alex.bennee(a)linaro.org>
[QEMU-109] <https://projects.linaro.org/browse/QEMU-109>
Completed Reviews [2/2]
=======================
[RISU PATCH 0/2] arm.risu: two minor fixes
Message-Id: <20200901162046.32670-1-peter.maydell(a)linaro.org>
[PATCH V3 00/10] fix some comment spelling errors
Message-Id: <20200917075029.313-1-zhaolichang(a)huawei.com>
Absences
========
- Family self-isolated for first half of week
Current Review Queue
====================
* [PATCH v4 00/15] Reverse debugging
Message-Id: <160006358590.31457.16757371597343007847.stgit@pasha-ThinkPad-X280>
Added: <2020-09-18 Fri>
* [RFC PATCH 0/3] Automatically convert configure options to meson build options
Message-Id: <20200913100534.22084-1-pbonzini(a)redhat.com>
Added: <2020-09-13 Sun>
* [PATCH 0/6] misc: Some inclusive terminology changes
Message-Id: <20200910070131.435543-1-philmd(a)redhat.com>
Added: <2020-09-10 Thu>
* [PATCH 00/43] tcg patch queue
Message-Id: <20200909001647.532249-1-richard.henderson(a)linaro.org>
Added: <2020-09-09 Wed>
--
Alex Bennée
Progress:
* VIRT-65 [QEMU upstream maintainership]
+ usual maintainer stuff
+ started a rebase/respin of the convert-QAPI-docs-to-Sphinx series
* VIRT-364 [QEMU support for ARMv8.1-M extensions]
+ sent patchset to make QEMU handle the way M-profile and A-profile
report presence of fp16 differently in their ID registers
thanks
-- PMM
[ Sorry it's a bit late. ]
[VIRT-327 # Richard's upstream QEMU work ]
Send out tcg patch queue.
Prototype a disassembler using llvm. Not ideal.
If we proceed with this further, we should probably
schedule time for it, because the job is not small.
Updating the capstone submodule; a couple of rounds
converting that to meson.
r~
== This Week ==
* GNU-659 (calculix)
- Comparing code-gen of hoisting region doesn't show many more extra stores
- Came up with two heuristics, which "fix" the issue, but aren't very general.
* LLVM-611
- D79785: Created fix for expensive checks issue, and posted on llvm-dev
- D87430: Posted patch for adding heuristic to LowerCall.
== Next Week ==
- Continue ongoing tasks
Hello Linaro Toolchain Working Group,
Do you plan to bring linaro-tk1-03 back online soon?
If not, I'll remove it from the LLVM buildbot this Friday.
Thanks
Galina
[VIRT-349 # QEMU SVE2 Support ]
Continuing the testing vs armie.
[VIRT-327 # Richard's upstream QEMU work ]
* More microblaze cleanup, including a check-acceptance
regression fix from the first pull. Ho hum.
* Patch review, queue is empty again.
* Old patch queue cleanup,
Fixed some gvec bugs affecting 32-bit x86;
testing vs aa32 risu.
r~
== This Week ==
* GNU-659 (calculix LTO regression)
- Gathered perf stats for various opt levels and posted on ML
* LLVM-611 (tune blx lowering heuristic)
- Dave Green committed my patch which had to be reverted due
to build-bot failure with expensive checks turned on.
- Posted analysis of the issue upstream
* Misc
- Committed patch to add --strict option to bmk-scripts/spec2xxx-config.
== Next Week ==
- Continue ongoing tasks
Progress: (short week, three days)
* VIRT-65 [QEMU upstream maintainership]
+ sent patches to remove QEMU's support for KVM on AArch32 hosts
(which we deprecated when the kernel removed its end of the support)
* VIRT-364 [QEMU support for ARMv8.1-M extensions]
+ fp16 work is now in master
+ sent patches to add support for mps2-an386 and mps2-an500
boards (Cortex-M4 and Cortex-M7 setups similar to the existing
mps2-an385 Cortex-M3 board model)
thanks
-- PMM
== This Week ==
* GNU-659 (LTO calculix regression)
- Started upstream discussion
* LLVM-611 (Tune lowering heuristic to blx for code size)
- Addressing upstream feedback for patch to fold tLDRpci, tBLx -> tBL
in foldMemoryOperand hook
- Added new heuristic to ISel, for follow up patch.
* LLVM-639 (Better idiom for comparing 32-bit values on arm)
- Started working on patch
== Next Week ==
- Continue ongoing tasks
1 day off
== Progress ==
* GCC upstream validation:
- reported several regressions
- committed testcase fixes
* GCC
- patch for PR94758 (-mpurecode and cortex-m23) applied to
thunk/gcc-10/gcc-9. Bug closed, but opened several others to track
performance improvements with -mpurecode
- PR96768: switch tables for thumb-1 with -mpure-code. Patch sent,
discussion on-going
- PR96769: WIP
- PR71233: missing ACLE intrinsics. I will first have to update the list
* benchmarking:
- Scripts to run coremark on stm32 now merged, working on using them
in production
* misc:
- infra patches/reviews
- internal support, leading to GCC testsuite cleanups for cortex-m
== Next ==
* GCC/cortex-M testing improvements & fixes
* cortex-m benchmarking
Progress:
* VIRT-65 [QEMU upstream maintainership]
+ Just the usual code review and pull request work.
* VIRT-364 [QEMU support for ARMv8.1-M extensions]
+ I have all fp16 insns (both VFP and Neon) implemented now, and the
VFP patches have been reviewed. Just need to track down a few last
test failures and then I can send the Neon patches out for review.
thanks
-- PMM
== Progress ==
* GCC upstream validation:
- reported several regressions
- committed testcase fixes
* GCC
- sent patch for PR94758 (-mpurecode and cortex-m23)
* benchmarking:
- Scripts to run coremark on stm32 now merged, working on using them
in production
* misc:
- infra patches/reviews
== Next ==
* GCC/cortex-M testing improvements & fixes
* cortex-m benchmarking
Progress (short week, 2 days):
* VIRT-65 [QEMU upstream maintainership]
+ We got 5.1 out the door. I think this is the first release
in the many years I've been handling them where we managed to
avoid needing an rc4.
+ Spent a fair amount of time helping Paolo to debug his conversion
of the QEMU build system to Meson. We managed to land that today.
+ First of the KVM Forum programme committee meetings
* VIRT-364 [QEMU support for ARMv8.1-M extensions]
+ More progress with fp16 support work; another handful of insns done.
thanks
-- PMM
[VIRT-327 # Richard's upstream QEMU work ]
Patch review, all over the place.
Patches for pauth impdef algorithm.
Patches for mte WnR bit.
Patches for crypto/cipher cleanup.
[VIRT-349 # QEMU SVE2 Support ]
Split out 20 patches from the SVE2 patch set.
r~
- 2 half days off
== Progress ==
* GCC upstream validation:
- reported several regressions (trunk and release branches)
- committed 2 testcase fixes
* GCC
- resumed work on PR94758 (-mpurecode and cortex-m23). Patch almost ready
* benchmarking:
- Scripts to run coremark on stm32 now merged, working on using them
in production
* misc:
- infra patches/reviews
== Next ==
* GCC/cortex-M testing improvements & fixes
* cortex-m benchmarking
VirtIO RPMB ([STR-5])
=====================
- got program_key and get_write_counter implemented
- finally making progress, the rest "should" be easy ;-)
[STR-5] <https://projects.linaro.org/browse/STR-5>
[testing kernel]
<http://git.linaro.org/people/alex.bennee/linux.git/shortlog/refs/heads/test…>
[qemu tree] <https://github.com/stsquad/qemu/tree/virtio/vhost-user-rpmb>
VirtIO Portability Demo ([STR-13])
==================================
- spent some time getting the MachiatoBin up and running
- system now working with latest 5.8 kernel and KVM support confirmed
- still debugging Xen setup, will return to this when back from
holidays
- currently no graphics available - need to perform [minor surgery] on
the PCI bus
[STR-13] <https://projects.linaro.org/browse/STR-13>
[minor surgery]
<http://wiki.macchiatobin.net/tiki-index.php?page=MACCHIATObin+%28up+to+rev+…>
Upstream Work ([QEMU-109])
==========================
- posted [PATCH v4 00/40] testing/next (vm, gitlab, fixes) Message-Id:
<20200701135652.1366-1-alex.bennee(a)linaro.org> : done
- posted [PULL 00/16] various fixes for rc2 (semihosting, tcg, docker,
tests/vm) Message-Id:
<20200727122357.31263-1-alex.bennee(a)linaro.org>
- a little leadership committee review
[QEMU-109] <https://projects.linaro.org/browse/QEMU-109>
Completed Reviews [2/2]
=======================
[PATCH RFC 00/10] fix some comment spelling errors
Message-Id: <20200812101500.2066-1-zhaolichang(a)huawei.com>
[PATCH 0/2] target/arm: Implement an IMPDEF pauth algorithm
Message-Id: <2219f3f9-7894-f898-0cad-43eccaa2a70d(a)linaro.org>
Absences
========
- short week
- holiday 13th-28th Aug - see you in September
Current Review Queue
====================
* [PATCH] plugins: new syscalls plugin
Message-Id: <20200812115816.4454-1-matthias(a)weckbecker.name>
Added: <2020-08-12 Wed>
* [PATCH v2 00/14] Reverse debugging
Message-Id: <159714365354.18946.2967871683340522027.stgit@pasha-ThinkPad-X280>
Added: <2020-08-11 Tue>
* [PATCH 00/11] Run cross-compilation build tests in the gitlab-CI
Message-Id: <20200804170055.2851-1-thuth(a)redhat.com>
Added: <2020-08-04 Tue>
* [RFC v3 0/8] QEMU cpus.c refactoring part2
Message-Id: <20200803090533.7410-1-cfontana(a)suse.de>
Added: <2020-08-03 Mon>
--
Alex Bennée
== Progress ==
* GCC upstream validation:
- reported a few regressions / minor testcase fix
* benchmarking:
- Created the Jenkins job to run coremark on stm32 (added/updated
scripts for that)
* misc:
- infra patches/reviews
== Next ==
* GCC/cortex-M testing improvements & fixes
* cortex-m benchmarking
I got an email and an irc ping for
http://lab.llvm.org:8011/builders/lldb-aarch64-ubuntu/builds/6924
My change has no relation to the test failure.
Flaky bots aren't allowed to send email or ping, so either make it
non-flaky or make it not send stuff.
Thanks,
Nico
[VIRT-327 # Richard's upstream QEMU work ]
Patch review -- lots of riscv vector stuff.
Fix for PAUTH error indication.
Diagnosed an MTE KASAN problem
-- my theory is a guest os thread error.
Investigation into PAUTH slowdown.
r~
Realised I missed last week so bumper update.
VirtIO Initiative ([STR-9])
===========================
- Inter-VM device emulation (call on Mon 20th July 2020) Message-Id:
<20200715112342.GD18817(a)stefanha-x1.localdomain>
- posted [RFC PATCH v1 0/3] put arm64 kvm_config on a diet Message-Id:
<20200804124417.27102-1-alex.bennee(a)linaro.org>
- EGL Call
- saw an interesting breakdown from other team doing vhost-user
- OpenSynergy
- got a good idea of where they are heading and the various players
[STR-9] <https://projects.linaro.org/browse/STR-9>
VirtIO RPMB ([STR-5])
=====================
- got the return path working
- re-based my [testing kernel] and made more spec conforming tweaks
[STR-5] <https://projects.linaro.org/browse/STR-5>
[simplified testing branch]
<http://git.linaro.org/people/alex.bennee/linux.git/shortlog/refs/heads/revi…>
[kernel]
<http://git.linaro.org/people/alex.bennee/linux.git/shortlog/refs/heads/revi…>
[testing kernel]
<http://git.linaro.org/people/alex.bennee/linux.git/shortlog/refs/heads/test…>
VirtIO Portability Demo ([STR-13])
==================================
- spent some time getting the MachiatoBin up and running
[STR-13] <https://projects.linaro.org/browse/STR-13>
Upstream Work ([QEMU-109])
==========================
- posted [PATCH v4 00/40] testing/next (vm, gitlab, fixes) Message-Id:
<20200701135652.1366-1-alex.bennee(a)linaro.org> : done
- Debugging a failure on m68k with pgd_find_hole_fallback
- seems 4.17+ with no /proc leave mmap_min_addr = 0 and NOREPLACE
hits it
- rth pondering a fix, may get back to it on Monday
- More debugging of icount bug, looks like -icount sleep=off interacts
with [bug 1859021]
- posted [PULL 00/16] various fixes for rc2 (semihosting, tcg, docker,
tests/vm) Message-Id:
<20200727122357.31263-1-alex.bennee(a)linaro.org>
[QEMU-109] <https://projects.linaro.org/browse/QEMU-109>
[bug 1859021] <https://bugs.launchpad.net/qemu/+bug/1859021>
Completed Reviews [6/6]
=======================
[PATCH v2 0/2] linux-user: fix clock_nanosleep()
Message-Id: <20200722174612.2917566-1-laurent(a)vivier.eu>
- CLOSING NOTE [2020-07-24 Fri 21:47]
Queued to my tree
Added: <2020-07-22 Wed>
[PATCH v1 0/3] python/qemu: follow-up changes for ConsoleSocket
Message-Id: <20200717203041.9867-1-robert.foley(a)linaro.org>
- CLOSING NOTE [2020-07-24 Fri 21:47]
Queued to my tree
Added: <2020-07-18 Sat>
[virtio-dev] [PATCH v5 00/10] introduce virtio vhost-user backend device type
Message-Id: <20200518203721.7625-1-ndragazis(a)arrikto.com>
- CLOSING NOTE [2020-07-24 Fri 21:48]
Interesting stuff, sent a few terminology fixes
Added: <2020-07-15 Wed>
[PATCH v2] cputlb: Make store_helper less fragile to compiler optimizations
Message-Id: <20200724195128.2373212-1-scw(a)google.com>
[PATCH 0/4] Refactor get_fpstatus_ptr() ready for AArch32 fp16
Message-Id: <20200806104453.30393-1-peter.maydell(a)linaro.org>
[DRAFT PATCH 000/143] Meson integration for 5.2
Message-Id: <1596741379-12902-1-git-send-email-pbonzini(a)redhat.com>
Absences
========
- 2 days off sick
- "holiday" 13th-25th Aug
Current Review Queue
====================
* [PATCH 00/11] Run cross-compilation build tests in the gitlab-CI
Message-Id: <20200804170055.2851-1-thuth(a)redhat.com>
Added: <2020-08-04 Tue>
* [RFC v3 0/8] QEMU cpus.c refactoring part2
Message-Id: <20200803090533.7410-1-cfontana(a)suse.de>
Added: <2020-08-03 Mon>
* [PATCH 0/2] accel/tcg: remove implied BQL from cpu_handle_interrupt/exception path
Message-Id: <20200731125127.30866-1-robert.foley(a)linaro.org>
Added: <2020-07-31 Fri>
* [PATCH 0/3] float16 APIs and alternative sNaN handling
Message-Id: <1596102747-20226-1-git-send-email-chihmin.chao(a)sifive.com>
Added: <2020-07-30 Thu>
--
Alex Bennée
Progress:
* VIRT-65 [QEMU upstream maintainership]
+ rc3 sent out. Optimistically hoping for release next week.
+ rebased the patchset converting QAPI doc-comments to rST
+ Fixed a bug in syndrome register values for copro insns trapped
from AArch32 to AArch64
* VIRT-364 [QEMU support for ARMv8.1-M extensions]
+ Finished and sent out the patchset that cleans up the coproc
insn decode and corrects the NOCP handling
+ With assistance from RTH, figured out how to use gvec helpers
to implement fp16 for various Neon insns. Added fp16 support to
20 or so insns; still have 15 or so to go.
thanks
-- PMM
Progress:
* VIRT-65 [QEMU upstream maintainership]
+ More release herding...
+ Sent fixes for some bugs:
- assertion in the imx_epit timer device when guest soft-reset it
- netduino2/netduinoplus2 forgot to configure system clock scale so
using SysTick in "run at CPU frequency" mode would hang
- most M-profile boards failed to make AIRCR.SYSRESETREQ actually
reset the system
* VIRT-364 [QEMU support for ARMv8.1-M extensions]
+ More progress with fp16: all the VFP insns now handled, including
the new-for-fp16 ones. Still to do: all of Neon...
+ Spent some time working through the details of NOCP vs UNDEF
in the M-profile coprocessor space for the various revisions
of the architecture. v8.1M adjusts things a bit in this area
and I want to clean up this bit of QEMU's current code and
get the v8.1M bits right.
Fact: next Monday (3rd August) will be the 10th anniversary
of my secondment into Linaro!
-- PMM
[VIRT-327 # Richard's upstream QEMU work ]
Misc patch review.
- Largest bit is half of riscv 0.9 vector patch set.
Fix arm E2 bug in ptw_translate.
Fix arm E3 buts in direct kernel startup.
Fix linux-user chroot failure.
r~
[VIRT-327 # Richard's upstream QEMU work ]
Misc patch review.
[GCC]
I looked into Adhemerval's libgomp-scalability patch set. The code looks good,
and I can't see anything wrong.
The cancel-parallel-2 test that's reported to regress, does, sometimes. It
never fails for me on qemu-test (aarch64, tx1). It *only* fails under the
dejagnu test harness on x86_64 and ppc64le. When run by hand it succeeds,
always. I cannot explain that at all. I've run the testsuite with
OMP_DEBUG_ENV=verbose and see that the dejagnu environment is as expected.
Anyway, I can't make forward progress because I can't reproduce the problem
under controlled conditions.
r~
VirtIO Related Work ([STR-9])
=============================
- putting together a demo system with a MacchiatoBin - idea here
Message-Id: <871rlkmzbs.fsf(a)linaro.org>
- posted On doorbells (queue notifications) Message-Id:
<87r1tdydpz.fsf(a)linaro.org> for discussion on RTT
- posted Enhancing virtio-mmio for MSI (new card required?)
Message-Id:
<alpine.DEB.2.21.2007151407190.4124@sstabellini-ThinkPad-T480s>
- started reviewing [virtio-dev] [PATCH v5 00/10] introduce virtio
vhost-user backend device type Message-Id:
<20200518203721.7625-3-ndragazis(a)arrikto.com>
- VIRTIO Sync-up call
- mainly discussing reducing traps MMIO vs PCIe
- need some better figures to justify adding MSI to MMIO
[STR-9] <https://projects.linaro.org/browse/STR-9>
VirtIO RPMB ([STR-5])
- realised the virtio driver in the [kernel] sent extra frames I
wasn't expecting
[STR-5] <https://projects.linaro.org/browse/STR-5>
[kernel]
<http://git.linaro.org/people/alex.bennee/linux.git/shortlog/refs/heads/revi…>
Upstream Work ([QEMU-109])
==========================
- posted [PATCH v4 00/40] testing/next (vm, gitlab, fixes) Message-Id:
<20200701135652.1366-1-alex.bennee(a)linaro.org> : done
- posted [PATCH v2 00/11] misc fixes for rc0 (docker, plugins,
softfloat) Message-Id:
<20200713200415.26214-1-alex.bennee(a)linaro.org>
- posted [PULL 0/9] final misc fixes for 5.1-rc0 Message-Id:
<20200714095247.19573-1-alex.bennee(a)linaro.org>
- took a couple of Message-Id:
<20200715105542.14428-1-alex.bennee(a)linaro.org> attempt to finally
get merged Message-Id:
<20200715111455.19237-1-alex.bennee(a)linaro.org>
- posted [PATCH v1 0/5] candidate fixes for 5.1-rc1 (shippable,
semihosting, OOM tcg) Message-Id:
<20200717105139.25293-1-alex.bennee(a)linaro.org>
[QEMU-109] <https://projects.linaro.org/browse/QEMU-109>
Blog Post ([LBO-34])
====================
- finished writing the [evolution of the translator] blogpost, should
go up next week
[LBO-34] <https://projects.linaro.org/browse/LBO-34>
[evolution of the translator]
<https://docs.google.com/document/d/190BlYjSTt-nZSR8dNdOxptt-swOZiGnASndEuXo…>
Completed Reviews [4/4]
=======================
[PATCH for-5.1 0/4] Document virt and a few other Arm boards
Message-Id: <20200713175746.5936-1-peter.maydell(a)linaro.org>
[PATCH 0/2] python/qemu: follow-up changes for ConsoleSocket
Message-Id: <20200715204814.2630-1-robert.foley(a)linaro.org>
[PATCH 00/13] Reverse debugging
Message-Id: <159316678008.10508.6615172353109944370.stgit@pasha-ThinkPad-X280>
Lost patience with more merge failures.
[PATCH 0/5] linux-user: Support extended clone(CLONE_VM)
Message-Id: <87h7vbyowf.fsf(a)linaro.org>
Current Review Queue
====================
* [virtio-dev] [PATCH v5 00/10] introduce virtio vhost-user backend device type
Message-Id: <20200518203721.7625-1-ndragazis(a)arrikto.com>
Added: <2020-07-15 Wed>
* [PATCH v4 00/22] target/xtensa: implement double precision FPU
Message-Id: <20200711110655.20287-1-jcmvbkbc(a)gmail.com>
Added: <2020-07-13 Mon>
* [PATCH v3 00/19] mailmap: Add more entries to sanitize 'git log' output
Message-Id: <20200702173818.14651-1-f4bug(a)amsat.org>
Added: <2020-07-02 Thu>
* [PATCH v3 0/9] memory: assert and define MemoryRegionOps callbacks
Message-Id: <20200630122710.1119158-1-ppandit(a)redhat.com>
Added: <2020-06-30 Tue>
--
Alex Bennée
Progress:
* VIRT-65 [QEMU upstream maintainership]
+ More wrangling of release stuff and unreliable infrastructure.
* VIRT-364 [QEMU support for ARMv8.1-M extensions]
+ Managed to find a few days to put in some more work pushing fp16
handling forwards. I now have implementations of fp16 for most of
the VFP insns (still todo: VCVT, VSEL, VMAXNM/VMINNM, VRINT*; then
the few insns that are new-for-fp16. Then all of Neon, which is larger.)
thanks
-- PMM
Progress:
* VIRT-65 [QEMU upstream maintainership]
+ softfreeze this week, so a lot of handling of pull requests,
reviewing various patchsets, sorting through newly reported
Coverity issues, etc etc.
thanks
-- PMM
== Progress ==
* GCC upstream validation:
- reported a few regressions / minor testcase fix
- enabled gcc-testresults for release branches, which will send even more emails
* benchmarking:
- added HAL support for the stm32 board we have in the Lab. Will start
testing once the board is actually connected to a builder
* misc:
- infra patches/reviews
== Next ==
* Holidays next two weeks, back on July 28th
* GCC/cortex-M testing improvements & fixes
* cortex-m benchmarking
== Progress ==
* Uploaded binaries for llvm 10.0.1 rc3 and rc4
* More work on Morello (including docs)
== Plan ==
* More Morello
* On vacation between July 20 - 31
4 day week.
[VIRT-327 # Richard's upstream QEMU work ]
Bug hunting vs aa32 ldrex/strex. I had hoped it would be relatively easy to
reproduce -- just run something from the .NET testsuite -- but even getting
that far wasn't obvious. So I put that aside; let's see if Peter's request for
an actual reproducer gets results.
Bug hunting vs aa64 gcc sync-4.c as reported by clyon. I determined that it's
not the fault of the null-pointer dereference, and that something goes wrong
somewhere in libgcc's exception unwind prior to the c++ throw. But it doesn't
fail all of the time. And worse, the problem vanishes when randomize_va_space
is disabled. So I can neither get a "good" vs "bad" trace without needless
differences nor produce a failure under gdb. I should try again with rr and
see if that works...
r~
Linaro folks - why is this buildbot sending mail when it's already red
(looks like this buildbot has been red for a while, at least 11187
seems to be red for the same reason that 11188 is red - so the people
on this blame list aren't relevant)? That adds noise to the buildbot
results & makes it harder for developers to find actionable email.
On Mon, Jul 6, 2020 at 9:30 PM <llvm.buildmaster(a)lab.llvm.org> wrote:
>
> 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/11188
>
> Buildbot URL: http://lab.llvm.org:8011/
>
> Buildslave for this Build: linaro-tk1-08
>
> Build Reason: scheduler
> Build Source Stamp: [branch master] 0c6b6e28e70c06a3cb4704d2d8f90829a689e230
> Blamelist: Amara Emerson <amara(a)apple.com>,Amy Kwan <amy.kwan1(a)ibm.com>,Biplob Mishra <biplmish(a)in.ibm.com>,David Blaikie <dblaikie(a)gmail.com>,Eric Christopher <echristo(a)gmail.com>,Jordan Rupprecht <rupprecht(a)google.com>,LLVM GN Syncbot <llvmgnsyncbot(a)gmail.com>,Nico Weber <thakis(a)chromium.org>,Sanjay Patel <spatel(a)rotateright.com>,Wolfgang Pieb <wolfgang_pieb(a)playstation.sony.com>,Yuanfang Chen <yuanfang.chen(a)sony.com>
>
> BUILD FAILED: failed build stage 2
>
> sincerely,
> -The Buildbot
>
>
>
== Progress ==
* GCC upstream validation:
- reported a few regressions
- added fortran to arm-none-eabi configs
- enabled gcc-testresults for most configurations, which now sends a
lot of emails
* GCC:
- PR94743 (IRQ handler and Neon registers): patch committed.
* benchmarking:
- cleanup of hal lib to run benchmarks on stm32, the board we have in
TCWG is different from the ones we used in ST, I'll have to update the
hal settings accordingly.
* misc:
- switch tcwg_gnu job to use our gcc-compare-results script, to be
able to ignore some tests with random results (especially under qemu)
== Next ==
* GCC/cortex-M testing improvements & fixes
* cortex-m benchmarking
[VIRT-344 # ARMv8.5-MemTag, Memory Tagging Extension ]
Lots of work here, finally merging MTE system support.
[VIRT-349 # QEMU SVE2 Support ]
Posted v2, all 100 patches.
[VIRT-327 # Richard's upstream QEMU work ]
A fair amount of patch review.
Merged the decodetree exclusive groups feature.
r~
== This Week ==
* GCC
- GNU-659 (LTO regressing calculix): Running and analysing benchmarks
with different configs.
* LLVM
- LVM-611 (heuristic to lower calls to blx for armv6-m): Addressing
upstream suggestions.
- LLVM-612 (code-gen for imm8 args for Thumb1): Posted patch upstream,
waiting for feedback.
* Validation
- Prototype script for metric based comparison
== Next Week ==
- Continue ongoing tasks
Progress:
* VIRT-65 [QEMU upstream maintainership]
+ respun the QEMU side of the "fix 32-bit-guest readdir of
ext4 filesystems on a 64-bit host" work to match Linus Walleij's
most recent kernel patch.
+ code review (actually emptied my queue for the first time in forever):
- patchset adding some missing devices to MPS2 boards
- another round of RTH's MTE patchset (now fully reviewed and ready to go in)
- SMMUv3.2 range-invalidation support patchset from RedHat
- RTH's implementation of the kernel MTE ABI for QEMU linux-user
+ had a look at some of the lurking Coverity issues
* VIRT-364 [QEMU support for ARMv8.1-M extensions]
+ fp16 support: started by working out risu patterns for all the
affected instructions so we have a means for testing the changes.
+ implemented a handful of fp16 insns; plan to back-burner this for
a little while as it's not going to be complete before we freeze
for QEMU 5.1, so work like reviewing the MTE patchset and other
for-5.1 efforts will take priority.
NB: on holiday next week
thanks
-- PMM
VirtIO Related Work ([VIRT-366])
================================
- posted [PATCH v2 0/5] some tweaks to the document build process
Message-Id: <20200619204959.7877-1-alex.bennee(a)linaro.org>
Upstream Work ([VIRT-109])
==========================
- posted [PATCH v2] docs/devel: add some notes on tcg-icount for
developers Message-Id:
<20200619170930.11704-1-alex.bennee(a)linaro.org>
[VIRT-109] <https://projects.linaro.org/browse/VIRT-109>
Completed Reviews [7/7]
=======================
[RFC v5 0/4] QEMU cpus.c refactoring
Message-Id: <20200615180346.3992-1-cfontana(a)suse.de>
[PATCH v1 1/2] semihosting: defer connect_chardevs a little more to use serialx
Message-Id: <1592215252-26742-1-git-send-email-frederic.konrad(a)adacore.com>
- CLOSING NOTE [2020-06-16 Tue 16:14]
A little confused as to the purpose of patch 1/2.
Added: <2020-06-15 Mon>
[PATCH 0/5] linux-user: Support extended clone(CLONE_VM)
Message-Id: <20200612014606.147691-1-jkz(a)google.com>
- CLOSING NOTE [2020-06-16 Tue 17:08]
This is super hairy stuff. Would like to know the use case for all
this additional complexity.
Added: <2020-06-12 Fri>
[PATCH v2 00/15] tests/tcg: Add TriCore tests
Message-Id: <20200604085441.103087-1-kbastian(a)mail.uni-paderborn.de>
- CLOSING NOTE [2020-06-16 Tue 18:29]
A few minor comments, v2 should be mergable.
Added: <2020-06-04 Thu>
[PATCH 0/3] Add Scripts for Finding Top 25 Executed Functions
Message-Id: <20200616231204.8850-1-ahmedkhaledkaraman(a)gmail.com>
[RFC] ivshmem v2: Shared memory device specification
Message-Id: <f109fe5a-92eb-e5a5-bb83-ada42b3a9b61(a)siemens.com>
- CLOSING NOTE [2020-06-17 Wed 16:49]
Finally got round to making some comments. All in all looks pretty
sane.
Added: <2020-05-25 Mon>
[PATCH v9 0/9] tests/vm: Add support for aarch64 VMs
Message-Id: <20200601211421.1277-1-robert.foley(a)linaro.org>
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 v7 00/42] target/arm: Implement ARMv8.5-MemTag, system mode
Message-Id: <20200603011317.473934-1-richard.henderson(a)linaro.org>
Added: <2020-06-18 Thu>
* [PATCH RFC 00/22] Support of Virtual CPU Hotplug for ARMv8 Arch
Message-Id: <20200613213629.21984-1-salil.mehta(a)huawei.com>
Added: <2020-06-13 Sat>
* [PATCH v8 0/4] vhost-user block device backend implementation
Message-Id: <20200604233538.256325-1-coiby.xu(a)gmail.com>
Added: <2020-06-12 Fri>
--
Alex Bennée
Progress:
* VIRT-65 [QEMU upstream maintainership]
+ code review:
- a fix for an A9 global timer device bug
- imx_fec ethernet bugfixes/cleanups
- SD card emulation bugfixes/cleanups (including a CVE fix)
- sm501 graphics card minor fixes
- implementation of qemu_init_exec_dir() for OSX
- patchset adding some missing devices to MPS2 boards
- RTH's v7 MemTag emulation series (this was a big one, took most of
a couple of days to work through)
+ sent docs patch deprecating our tilegx port
+ discussion about what exactly target code has to do
for icount support; wrote some patches to remove some 'gen_io_end()'
calls that turn out to be no-longer-necessary
* VIRT-364 [QEMU support for ARMv8.1-M extensions]
+ completed the neon decodetree conversion and sent the last batch
of patches out for review; plan to start on fp16 support next
NB: have recorded my maintainership work under the old VIRT-65
for now; not yet clear when/which jira issue to use in the new UM-*
hierarchy.
thanks
-- PMM
* Training all week
== Progress ==
* GCC upstream validation:
- reported a few regressions
- enabled sending of some validation results to gcc-testresults mailing-list
* GCC:
- PR94743 (IRQ handler and Neon registers): No feedback yet.
* misc:
- infra fixes / troubleshooting / reviews
- cleanup of hal lib to run benchmarks on stm32
== Next ==
* PR94743
* GCC/cortex-M testing improvements & fixes
* cortex-m benchmarking
* FDPIC GDB
* VIRT-364 [QEMU support for ARMv8.1-M extensions]
+ Good progress with the neon decodetree conversion this week -- now feels
like it's nearly done. Wrote and sent out another couple of patchsets for
review. The only remaining insns to convert are the 2-reg-misc grouping.
Have made a start on that; hope to get the final part of the conversion
out for review next week.
thanks
-- PMM
(0.5 day off)
== Progress ==
* GCC upstream validation:
- scripts updates and cleanup for cortex-m33 with qemu-system-mode
- investigated a random error with a C++ testcase under qemu-aarch64
since I upgraded to qemu-5.0.
- reported a few regressions
- fixed cross-build of GCC after C++11 upgrade, looked at fixing
native builds (different problem), but someone had already posted the
same fix during the week-end
* GCC:
- PR94743 (IRQ handler and Neon registers): No feedback yet.
* misc:
- infra fixes / troubleshooting / reviews
- looking at cortex-m benchmarking harnesses. Updated docker images to
include openocd and checked I could connect to the board from a docker
container.
- helping test Dejagnu new master branch in preparation for next stable release
== Next ==
* training next week
[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