Hi Sir,
I have some questions for tool chain:
1. Can the latest version “linaro-gcc/7.5” support ARMv9 new ISA?
2. If not, when will the new release version can support?
Thanks a lot.
Chun-Chia
VirtIO Related Work ([VIRT-366])
================================
- Followed up with ARM on the roll of Hafnium and secure partitioning
with VirtIO
- Continued working through various requirements for the work
- raised [VIRT-373] to describe some potentially common work on
handling userspace backends
- started discussion on approaches on virtio-dev list Message-Id:
<874kv15o4q.fsf(a)linaro.org>
- posted [RFC PATCH] tools/virtiofsd: add support for --socket-group
Message-Id: <20200304185025.19853-1-alex.bennee(a)linaro.org>
[VIRT-366] <https://projects.linaro.org/browse/VIRT-366>
[VIRT-373] <https://projects.linaro.org/browse/VIRT-373>
Upstream Work ([VIRT-109])
==========================
- posted [PATCH v1 00/10] testing/next updates (tweaks and
re-greening) Message-Id:
<20200302181907.32110-1-alex.bennee(a)linaro.org>
- posted [PULL 0/9] testing updates (tests/vm and acceptance tweaks)
Message-Id: <20200304100154.14822-1-alex.bennee(a)linaro.org>
[VIRT-109] <https://projects.linaro.org/browse/VIRT-109>
Completed Reviews [3/3]
=======================
[PATCH v3 00/33] Convert qemu-doc to rST
Message-Id: <20200228153619.9906-1-peter.maydell(a)linaro.org>
[PATCH v5 00/50] Initial support for multi-process qemu
Message-Id: <cover.1582576372.git.jag.raman(a)oracle.com>
- CLOSING NOTE [2020-03-02 Mon 18:20]
Initial pass, mostly checking wasn't CI broken, which it was.
Added: <2020-02-28 Fri>
[PATCH v6 00/18] Add Allwinner H3 SoC and Orange Pi PC Machine
Message-Id: <20200301215029.15196-1-nieklinnenbank(a)gmail.com>
Absences
========
- None
Current Review Queue
====================
* [PATCH v16 00/10] VIRTIO-IOMMU device
Message-Id: <20200214132745.23392-11-eric.auger(a)redhat.com>
Added: <2020-03-03 Tue>
* [RFC][PATCH 0/3] IVSHMEM version 2 device for QEMU
Message-Id: <cover.1573477032.git.jan.kiszka(a)siemens.com>
Added: <2020-02-14 Fri>
* {PATCH v2 0/2} tests/tcg/multiarch: Add tests for implemented real
Message-Id: <1581603905-21565-1-git-send-email-Filip.Bozuta(a)rt-rk.com>
Added: <2020-02-13 Thu>
* [RFC 0/9] Add an interVM memory sharing device
Message-Id: <1580815851-28887-1-git-send-email-i.kotrasinsk(a)partner.samsung.com>
Added: <2020-02-05 Wed>
--
Alex Bennée
Progress:
* VIRT-65 [QEMU upstream maintainership]
- found and fixed some bugs in our "hflags caching" for M-profile
which caused spurious assertions in some corner cases
- got the rST conversion patchset through review and into master
- sent some followup cleanup patches that remove some texinfo
related bits of code we no longer need
- patch review:
+ rth's final respin of the "honour more HCR_EL2 traps" series
+ patchset fixing some memory leaks of timer objects
+ patchset for cubieboard model to error out rather than ignoring
some bogus user command line options
* VIRT-241 [QEMU ISA Support for A-profile]
+ Wrote an implementation of v8.2-TTS2UXN; investigating how best
to test it
thanks
-- PMM
[VIRT-344 # ARMv8.5-MemTag, Memory Tagging Extension ]
Lots of work, including an arch update. The system-mode patch set is much
changed, but still not quite ready.
[VIRT-349 # QEMU SVE2 Supprt ]
[VIRT-327 # Richard's upstream QEMU work ]
TBI fixes, 2 rounds.
HCR fixes, 2 rounds.
TCG patch queue flushed.
Some patch review.
r~
Good afternoon,
I would like to announce the breakthrough in extending gdb with non
intrusive instructions and functions tracing on ARM processors using
Coresight ETM traces, as described in previous mails.
the source code is made public in the git repository
https://github.com/gzied/binutils-gdb/ in the branch gdb_arm_coresight.
this implementation was compiled and tested on an STM32MP1 (ARMv7
Architecture) board running "Linux arm 5.3.10-armv7-lpae-x15" distribution
where the device tree was modified to declare CoreSight components.
to build the software
>checkout the software from the branch gdb_arm_coresight
> cd ..
>mkdir build
>cd build
> ../binutils-gdb/configure --with-arm-cs
>make
after a successful build gdb will be available in the folder build/gdb
to run the software
build the software you would like to debug with debugging info (-g flag)
>gcc -g software.c -o software
start debugging your software
>gdb software
set a breakpoint at main
(gdb) b main
(gdb) run
set a breakpoint in a location after the code you would like to trace
(gdb) b my_function
set your etm sink, sinks can be found by listing the folder
/sys/bus/event_source/devices/cs_etm/sinks/. use a sink that is capable of
storing the traces on chip (etf, etb ...)
(gdb) set record btrace etm sink tmc_etf0
start recording etm traces
(gdb) record btrace etm
continue the execution of the program
(gdb) c
wait until the breakpoint is hit,
analyse and display the traces
- on assembly level
(gdb) record instruction-history
- on c level
(gdb) record function-call-history /ilc
you can increase the number of instructions displayed by using
(gdb) set record instruction-history-size size
(gdb) set record function-call-history-size size
the work is still in an early stage and needs to be improved, extended and
stabilized. your feedback and contributions are welcome
Kind Regards
Zied Guermazi
VirtIO Related Work ([VIRT-366])
================================
- had a couple of HOs and internal threads to flesh out understanding
for VirtIO work
- queried VIRTIO adoption in other hypervisors Message-Id:
<87mu93vwy2.fsf(a)linaro.org> to help understanding
- need a meeting with QC/NXP to discuss their requirements and why
they need certain devices in VirtIO
- a lot of the Android focus seems to be on isolating various secure
workloads
- avoiding needing secure but un-trusted code at elevated privileges
with access to main OS
- suspect the breakdown in the card needs re-arranging
[VIRT-366] <https://projects.linaro.org/browse/VIRT-366>
Upstream Work ([VIRT-109])
==========================
- posted [PATCH v2 00/12] testing/next (with build fixes!) Message-Id:
<20200130113223.31046-10-alex.bennee(a)linaro.org>
- posted [PULL 00/19] testing and plugin updates Message-Id:
<20200226073929.28237-1-alex.bennee(a)linaro.org>
- did some debugging/diagnosis for recent slowdown of ARM emulation in
master Message-Id:
<CAPan3Wq-MVwcJQELP8n+g33CR7tsiGXQ698gA177nd2my9hWCw(a)mail.gmail.com>
- posted [PATCH v1 0/4] Fix codegen translation cache size
Message-Id: <20200226181020.19592-1-alex.bennee(a)linaro.org>
[VIRT-109] <https://projects.linaro.org/browse/VIRT-109>
Completed Reviews [3/3]
=======================
[PATCH v16 00/10] VIRTIO-IOMMU device
Message-Id: <20200214132745.23392-1-eric.auger(a)redhat.com>
- CLOSING NOTE [2020-02-26 Wed 15:37]
It's in an in-flight PR now, will play with it once it lands.
Added: <2020-02-14 Fri>
[PATCH RISU] aarch64.risu: Add patterns for v8.3-RCPC and v8.4-RCPC insns
Message-Id: <20200225143923.22297-1-peter.maydell(a)linaro.org>
[PATCH v3 0/3] Fix number of priority bits for arm boards
Message-Id: <1582537164-764-1-git-send-email-sai.pavan.boddu(a)xilinx.com>
- CLOSING NOTE [2020-02-28 Fri 17:22]
Have been pulled into target-arm next but didn't fix the
kvm-unit-test failures with priority masking as I had hopped they
would.
Added: <2020-02-25 Tue>
Absences
========
- None
Current Review Queue
====================
* [RFC][PATCH 0/3] IVSHMEM version 2 device for QEMU
Message-Id: <cover.1573477032.git.jan.kiszka(a)siemens.com>
Added: <2020-02-14 Fri>
* {PATCH v2 0/2} tests/tcg/multiarch: Add tests for implemented real
Message-Id: <1581603905-21565-1-git-send-email-Filip.Bozuta(a)rt-rk.com>
Added: <2020-02-13 Thu>
* [RFC 0/9] Add an interVM memory sharing device
Message-Id: <1580815851-28887-1-git-send-email-i.kotrasinsk(a)partner.samsung.com>
Added: <2020-02-05 Wed>
* [PATCH v2 0/7] configure: Improve PIE and other linkage
Message-Id: <20191218223441.23852-1-richard.henderson(a)linaro.org>
Added: <2020-01-06 Mon>
--
Alex Bennée
Progress:
* VIRT-65 [QEMU upstream maintainership]
- Got confused by QEMU aborting in the PMU code on a GICv3-only host,
which turns out to be because our error handling for "no GICv2
support" was broken. Sent a patch.
- Another push towards getting texi-to-rST conversion done:
+ Converted a few more simple texi doc files to rST
+ Took up a patchset Paolo did for more automated conversion, and
sorted out the parts it didn't deal with, to get it to a point
where it could delete almost all of the texinfo sources. Sent
a big patchset to the list for review.
- patch review:
+ Gumstix cleanup patchset
+ rth's series to honour more HCR_EL2 traps
+ add a few missing devices to integratorcp
+ get the number of implemented priority bits in GICv2 right
* VIRT-241 [QEMU ISA Support for A-profile]
- Implemented the v8.3-RCPC, v8.4-RCPC and v8.3-CCIDX extensions,
and sent patches to the list
thanks
-- PMM
== Progress ==
* BFD Linker:
- GNU-629: non-contiguous memory support: posted updated v5
* GCC:
* GCC-9: continued work for validation of -mpure-code on v6m. Fix
committed to trunk and backported to gcc-9
* GCC upstream validation:
- reported a couple of failures/regressions
- working on reproducing a non-functional code problem with spec2006
on arm with LTO and -Os
* misc:
- infra fixes / troubleshooting / reviews
== Next ==
* Binutils: GNU-629: support non-contiguous memory regions in linker
* spec2006 / LTO / Os / aarch32
* FDPIC GDB
Four day week.
[VIRT-344 # ARMv8.5-MemTag, Memory Tagging Extension ]
Lots of work here.
Noticed that our TBI handling is wrong for system mode, such that the FAR_ELx
register gets the wrong contents. Noticed that SVE isn't handling TBI at all,
much less being prepared for MTE. Noticed that even AdvSIMD would not quite
produce the correct results for LD*/ST* (multiple structures).
Rearranging the actual MTE check from the ground up. Found an odd case with
DC_ZVA that threw a wrench into that planning.
[VIRT-327 # Richard's upstream QEMU work ]
Honor more HCR_EL2 trap bits.
HPPA patch queue flushed.
Patch review for ppc "hardfloat" patch.
Patch review for memory_region_allocate_system_memory.
r~
Progress:
* VIRT-65 [QEMU upstream maintainership]
- Sent out a patchset creating a 'tools' manual and moving some
docs into it that were previously in the 'interop' manual
- more code review this week than last week
- pushed out another arm pullreq
* VIRT-241 [QEMU ISA Support for A-profile]
- several patches implementing features landed in master,
so I was able to close out some of the subtasks here
thanks
-- PMM
== Progress ==
* BFD Linker:
- GNU-629: non-contiguous memory support: handling feedback received
* GCC:
* GCC-9: continued work for validation of -mpure-code on v6m. All new
failures reported with cortex-m0 + -mpure-code are to be expected
(mainly testcases forcing options incompatible with -mpure-code)
* GCC upstream validation:
- reported a couple of failures/regressions
- looked at a problem with LTO profiled bootstrap failing on aarch32
with gcc-8. Could not reproduce with current trunk
- working on reproducing a non-functional code problem with spec2006
on arm with LTO and -Os
* misc:
- infra fixes / troubleshooting / reviews
- looked at a problem reported about addr2line and kernel symbols.
Needs more analysis
== Next ==
* Binutils: GNU-629: support non-contiguous memory regions in linker
* GCC-9: continue work for validation of -mpure-code on v6m
* spec2006 / LTO / Os / aarch32
* FDPIC GDB
== Progress ==
* More Morello (updating for new capability encoding)
* Tiny amount of GlobalISel arm32 maintenance (not committed yet)
== Plan ==
* More Morello
Same comment applies with regards to mailing lists.
On Mon, 17 Feb 2020 at 10:16, zied guermazi <guermazi_zied(a)yahoo.com> wrote:
>
> Hi Mike, hi Matthieu,
>
> I was too rapid to press the send button, sorry for the inconvienience.
> and yes, it works. I published the source code in github (https://github.com/gzied/binutils-gdb/tree/gdb_arm_coresight) ,as well as a mail in linaro mailing list (https://lists.linaro.org/pipermail/coresight/2020-February/003676.html).
Unfortunately you didn't publish your work in "PATCH" format and as
such it can't be reviewed.
> Eventhough there is still an effort needed to stabilize it for armv7, and test it for armv8, I consider this as a breakthough that we can build on the top of it.
> I will be visiting Embedded world exhibition between 25th and 27th of February in Nuremberg, Germany. are you planning to be there too. I am looking forwards to meet you there if possible to discuss possibilities of further development and integration in the main stream.
I won't be in Nuremberg next week and I'm pretty sure Mike won't be
there either. Other people on the lists might be around and
interested in meeting with you. Mike and I will be attending Linaro
Connect in Budapest between the 23rd and 27th of March. The Linaro
toolchain group will also be there so it might be the perfect
opportunity to sit down for an hour or so and have a chat.
A good day to you,
Mathieu
>
> Kind Regards
> Zied Guermazi
>
>
>
>
>
> On Monday, February 17, 2020, 06:08:26 PM GMT+1, zied guermazi <guermazi_zied(a)yahoo.com> wrote:
>
>
> Hi Mike, hi Matthieu
> it works!
>
>
>
> On Monday, December 16, 2019, 11:20:20 PM GMT+1, zied guermazi <guermazi_zied(a)yahoo.com> wrote:
>
>
> hi Mike, hi Mathieu
> last few weeks I was able to spend some time on implementing this feature, and I want to share the status with you and get your recommendation on organizational and technical level.
> so far I was able to use perf events to configure the drivers for etm and collect the traces. the code was tested successfully on an STM32MP157A discovery kit (arm v7).
> I would like to push this on git, first for review and second for integration and creating traction . Do you think it is ok to push it in this status (feature partially achieved) ? is linaro gdb git the correct one? who is the maintainer of this part of gdb? I do not have an ARMv8 platform to test. who can support here?
>
> during the implementation few technical question raised:
> - etm tracing collection requires selecting a trace sink. and I have two alternatives: either extending the "record btrace etm" command (used to start tracing) with a sink as an argument or extending the command "set record btrace" (general configuration of tracing) with etm sink sub-command? (I have hard-coded it currently to be able to progress)
> - currently I am hardcoding the path "/sys/bus/event_source/devices/cs_etm/" as the default etm source, is this guaranteed to be unique? can we have a system with many etm sources enumerated in the sysfs.
>
> for parsing the traces I will need some configuration parameters like the content of registers ETMCR, ETMIDR, ETMCCER, ETMTRACEIDR. if my understanding of the implementation of perf is correct, it is collecting them from the sysfs files located in /sys/bus/event_source/devices/cs_etm/cpu0/mgmt/. which are global for the system. my question is what will happen if two process are requesting tracing at the same time? how to differentiate between traces going to one session from the second one? is it possible to get the parameters of a given session by some kind of ioctl request to the file descriptor we get out of sys_perf_open call?
>
> I will publish those queries in the linaro coresight and gdb forums, I wanted first to align with you especially on the organizational issues, before going to a bigger round.
>
> Thanks for your support
> Zied Guermazi
>
>
i
Hi Zied,
As requested before, always add the CS mailing list when interacting
with us. There is a fair amount of people on there that would surely
be interested in this work. I also CC'd the linaro-toolchain group
since some of the content below is related to what they do.
On Mon, 17 Feb 2020 at 10:08, zied guermazi <guermazi_zied(a)yahoo.com> wrote:
>
> Hi Mike, hi Matthieu
> it works!
>
>
>
> On Monday, December 16, 2019, 11:20:20 PM GMT+1, zied guermazi <guermazi_zied(a)yahoo.com> wrote:
>
>
> hi Mike, hi Mathieu
> last few weeks I was able to spend some time on implementing this feature, and I want to share the status with you and get your recommendation on organizational and technical level.
> so far I was able to use perf events to configure the drivers for etm and collect the traces. the code was tested successfully on an STM32MP157A discovery kit (arm v7).
> I would like to push this on git, first for review and second for integration and creating traction . Do you think it is ok to push it in this status (feature partially achieved) ? is linaro gdb git the correct one? who is the maintainer of this part of gdb? I do not have an ARMv8 platform to test. who can support here?
I will address your questions one by one:
Q: Do you think it is ok to push it in this status (feature partially
achieved) ?
A: That depends on how advanced things are. If it is stable (i.e it
does something) and can be used as a starting point for other people
to work on, then there is probably value in publishing your work.
Q: is linaro gdb git the correct one?
A: I see from your other email that you've already published your work.
Q: who is the maintainer of this part of gdb?
A: I'm sure the GDB project has documentation and a well defined
process that would identify who you should submit your code to.
Q: I do not have an ARMv8 platform to test. who can support here?
A: No doubt you'd get a lot more interest if you were working on V8.
I suggest purchasing a dragonboard 410c - they are super cheap, well
supported and one of our CS reference platforms. I think we talked
about that before...
>
> during the implementation few technical question raised:
> - etm tracing collection requires selecting a trace sink. and I have two alternatives: either extending the "record btrace etm" command (used to start tracing) with a sink as an argument or extending the command "set record btrace" (general configuration of tracing) with etm sink sub-command? (I have hard-coded it currently to be able to progress)
I would assume this "set record btrace" command has an effect on the
current session only. If so I would go for the latter option.
> - currently I am hardcoding the path "/sys/bus/event_source/devices/cs_etm/" as the default etm source, is this guaranteed to be unique? can we have a system with many etm sources enumerated in the sysfs.
>
I am very confused by this question. Yes, the path
"/sys/bus/event_source/devices/cs_etm/" is guaranteed to be unique but
it is by no means a "default source". Is is simply a directory used
by the perf tools to have more details on the CS specifics for the
running platform. Nowadays it is fair to assume there is one ETM perf
CPU, all enumerated under sysfs. Also keep in mind that processes are
being moved around by the scheduler and as such, a specific source
can't be hard coded.
> for parsing the traces I will need some configuration parameters like the content of registers ETMCR, ETMIDR, ETMCCER, ETMTRACEIDR. if my understanding of the implementation of perf is correct, it is collecting them from the sysfs files located in /sys/bus/event_source/devices/cs_etm/cpu0/mgmt/. which are global for the system. my question is what will happen if two process are requesting tracing at the same time? how to differentiate between traces going to one session from the second one? is it possible to get the parameters of a given session by some kind of ioctl request to the file descriptor we get out of sys_perf_open call?
Configuration of the tracers does indeed need to be considered. At
this time we assume all the tracers in an implementation are similar,
hence using ".../cpu0/mgmt". The information gathered from there is
related to the static configuration of the tracers. Per session
dynamic configuration is collected from the perf tools command line
and communicated to the perf infrastructure for later interpretation
by the decoding code when instantiating a decoder from the openCSD
library. Since the current framework handles only N:1 source/sink
configuration, there can only be one trace session using a sink.
There is currently no way to extract trace session configuration other
than the user space perf tools mechanic.
>
> I will publish those queries in the linaro coresight and gdb forums, I wanted first to align with you especially on the organizational issues, before going to a bigger round.
>
> Thanks for your support
> Zied Guermazi
>
>
== Progress ==
* More Morello (updating for new capability encoding)
* Went to the embassy to get my passport
* Read a couple ARM policy refreshers...
== Plan ==
* More Morello
== Progress ==
* BFD Linker:
- GNU-629: non-contiguous memory support: posted v4
* GCC:
* GCC-9: continued work for validation of -mpure-code on v6m:
posted updated patch for latent bug on trunk
* GCC upstream validation:
- reported a couple of failures/regressions
- fixed FDPIC build broken on trunk
* misc:
- infra fixes / troubleshooting / reviews
== Next ==
* Binutils: GNU-629: support non-contiguous memory regions in linker
* GCC-9: continue work for validation of -mpure-code on v6m
* FDPIC GDB
VirtIO Related Work
===================
This is essentially a mind-map of bullet points as we work out what
concrete work items should be implemented by the TCWG Virt hackers
(most likely just me ;-)
Xen for Automotive ([LBI-24])
- Things that need doing
- support for virtio in core (i.e. not just emulated devices)
- support for virtio-iommu and sharing memory between guests
(ivshmemv2?)
- support virtio over ivshmemv2 (would native virtio be supported?)
- support for vhost over shared memory (zero copy device emulation)
- support isolating userspace emulation from hvm (vhost-user)
- Why?
- userspace emulation has performance benefits (exit-less, polling)
- growing number of virtio devices for that guests support
[LBI-24] <https://projects.linaro.org/browse/LBI-24>
Virtualizing Android ([LBI-38])
- Builds on Google's work on Cuttlefish
- New Android Device model using VirtIO (including VirtGPU) \o/!
- Used to run on QEMU, now targeting CrosVM
- Potential interest in using as a HAL layer
- Potential work items
- Better support for ARM in CrosVM
- Is QEMU of interest to members? (emulation & tooling - unlike
CrosVM)
- Is a virtualised Android HAL possible
- Where does Hafnium fit it?
[LBI-38] <https://projects.linaro.org/browse/LBI-38>
QEMU Tooling ([VIRT-252])
=========================
Extend gdbstub for SVE ([VIRT-281])
- re-based [a v7 branch]
[VIRT-281] <https://projects.linaro.org/browse/VIRT-281>
[a v7 branch]
<https://github.com/stsquad/qemu/tree/gdbstub/sve-registers-v7>
Upstream Work ([VIRT-109])
==========================
- posted [PATCH v2 00/12] testing/next (with build fixes!) Message-Id:
<20200130113223.31046-10-alex.bennee(a)linaro.org>
- posted [PATCH v2 00/19] testing and plugin updates Message-Id:
<20200213225109.13120-1-alex.bennee(a)linaro.org>
[VIRT-109] <https://projects.linaro.org/browse/VIRT-109>
Completed Reviews [3/3]
=======================
[RFC PATCH 1/2] GitLab CI: avoid calling before_scripts on unintended jobs
Message-Id: <5d0def0e-0943-3345-784d-80f8ccc318b9(a)redhat.com>
[PATCH v1 00/14] tests/vm: Add support for aarch64 VMs
Message-Id: <20200205212920.467-1-robert.foley(a)linaro.org>
- CLOSING NOTE [2020-02-07 Fri 19:56]
Some problems with hangs, not sure about using threads/file
approach.
Added: <2020-02-06 Thu>
[PATCH 0/2] target/arm: Pass arguments by value for sve FMLA/FCMLA
Message-Id: <20200212025145.24300-1-richard.henderson(a)linaro.org>
Absences
========
- 17t-24th Feb Half Term
- 23rd-27th March BUD20
Current Review Queue
====================
* [PATCH v16 00/10] VIRTIO-IOMMU device
Message-Id: <20200214132745.23392-1-eric.auger(a)redhat.com>
Added: <2020-02-14 Fri>
* [RFC][PATCH 0/3] IVSHMEM version 2 device for QEMU
Message-Id: <cover.1573477032.git.jan.kiszka(a)siemens.com>
Added: <2020-02-14 Fri>
* {PATCH v2 0/2} tests/tcg/multiarch: Add tests for implemented real
Message-Id: <1581603905-21565-1-git-send-email-Filip.Bozuta(a)rt-rk.com>
Added: <2020-02-13 Thu>
* [RFC 0/9] Add an interVM memory sharing device
Message-Id: <1580815851-28887-1-git-send-email-i.kotrasinsk(a)partner.samsung.com>
Added: <2020-02-05 Wed>
--
Alex Bennée
Progress:
* VIRT-241 [QEMU ISA Support for A-profile]
- Looking into implementing some of the easier, smaller architecture features
- Implemented ARMv8.1-VMID16 (16-bit VMID support), which is trivial
for QEMU because it doesn't care much about VMIDs
- Working on ARMv8.1-PMU and ARMv8.4-PMU: it turns out that we already have
most of these extensions, so we just need to finish off some smaller pieces
and fix one or two bugs. Sent out a patchset implementing these.
- Found a bunch of ID-register related bugs in the process, which I have
fixes for
- Implemented the "mandatory from v8.2" ACTLR2 and HACTLR2 registers
* VIRT-65 [QEMU upstream maintainership]
- code review:
- series from Laurent fixing a long-standing issue with handling of
realtime signals in our linux-user code
- imx6 model patches to fix a watchdog device bug and add the
watchdog to our imx6 boards
- final few unreviewed patches in rth's "PAN, ATS1E1, UAO" series
- respin of the json QAPI Sphinx conversion patchset; hopefully the
first half of this is now uncontroversial cleanups that can go in
while the second half gets code reviewed
thanks
-- PMM
o LLVM:
* 10.0.0 RC:
- reported issues upstream
- upload AArch64 binaries
* IR Outliner:
- looking at the branch status
o Misc
* Resurrected an old GNU toolchain prototype w/r to Linux kernel
size reduction.
* Various meetings and discussions.
== Progress ==
* BFD Linker:
- GNU-629: non-contiguous memory support: posted v3, no feedback yet.
* GCC:
* GCC-9: continued work for validation of -mpure-code on v6m:
reproduced latent bug on trunk, fix accepted, but I'm still worried by
it not setting all insn attributes correctly.
* GCC upstream validation:
- reported a couple of failures/regressions
- FDPIC build broken on trunk
* misc:
- infra fixes / troubleshooting / reviews
== Next ==
* Binutils: GNU-629: support non-contiguous memory regions in linker
* GCC-9: continue work for validation of -mpure-code on v6m
* Fix FDPIC build
[ Linux on ARM mini-conference ]
2 days. Some interesting stuff in the future hardware directions talks.
Helped out a bit with ABI history in the toolchain breakout session. Some good
hallway discussion, especially re record-replay on aarch64.
I should make time this weekend to produce a more complete trip report.
[VIRT-263 # ARMv8.1-VHE Virtual Host Extensions ]
Posted v7 -- merged!
[VIRT-262 # ARMv8.1-PAN ]
[VIRT-273 # ARMv8.2-ATS1E1 ]
[VIRT-276 # ARMv8.2-UAO ]
Posted v3.
[VIRT-327 # Richard's upstream QEMU work ]
Random patch review.
Updated some aa32 vfp cleanup patches; still need to
re-test and post.
r~
