Progress:
* UM-2 [QEMU upstream maintainership]
- attended KVM Forum
- catching up with code review, email, etc...
- sent out an Arm pullreq now 7.2 has opened up for development
* QEMU-422 [QEMU Arm Neoverse V1 vCPU for TCG]
- diagnosed a regression caused by the recent FEAT_PMUv3p5 changes
and sent out a fix
KVM Forum trip highlights:
* it was good to be able to meet people face-to-face again after
several years
* Cloud use of Arm hardware has now got to the point where big cloud
companies are working through performance issues and then coming to
present about it; e.g. Google did a talk about perf issues during
migration on an Ampere Altra setup. The solutions seem to be a mix
of "apply the lessons and fixes we already went through with x86"
and "architecture fixes coming down the pipe" (in this case
FEAT_TLBIRANGE and FEAT_BBM).
* lots of Google talks about pKVM (using hypervisor hardware on
Android to improve security). In fact lots of Google all over --
apparently they've made a big push to do more upstream kernel work
and as a result a large chunk of the kernel KVM commits come from
them...
* talk from Xilinx (now with AMD) about doing co-simulation of QEMU
and RTL -- basically (with the aid of a lot of non-upstream stuff)
having QEMU talk to a SystemC environment so you can have eg an
emulated ethernet card in FPGA that plugs into a QEMU VM. This kind
of thing is a use-case which historically upstream have not really
been interested in addressing.
* Which brings me to the BoF session on emulation, perhaps the most
interesting bit of the conference for me. There was a lot of
discussion about whether QEMU might move closer to what I call the
"bag of lego bricks" paradigm, where it provides device models and
users might be able to configure it at runtime to stitch them
together, perhaps adding out-of-tree devices of their own. There is
clearly interest in this (eg from attendees from Xilinx and
Qualcomm); the sticking point is that from upstream's perspective
this seems like "you should do this thing that will benefit us and
not you". My take is that whether this goes anywhere will depend on
whether those who would like this are prepared to coordinate
together to present themselves as a group who are willing to dig in
to the necessary upstream refactoring and cleanup that would be a
precondition for having something like this be anywhere near
supportable, i.e. that they're a group who will come and help
rather than merely consume...
* There was also a shorter discussion in the BoF about the idea of
"heterogenous CPU emulation", eg one QEMU model with both Arm and
Microblaze CPUs. This is not conceptually controversial, it's just
a lot of work. It seemed like maybe a few folk now care enough to
have a go at it.
-- PMM
Hello,
# [GNU-767] Support changing SVE vector length in remote debugging
- Made a few last-minute adjustments to the code and fixed a couple of
regressions on x86_64-linux. Re-ran regression tests on x86_64-linux and
aarch64-linux. Wrote cover letter and descriptions for all the patches.
- Finally posted the patch series upstream¹.
# [GNU-796] Stabilize GDB testsuite results in the Linaro CI
- Started working on this issue. Currently adding a new CI job to run the
same small subset of GDB testcases that Sourceware's buildbot runs. This
subset runs quickly and has stable results so the job will be a good
canary to check that the CI infrastructure is working correctly.
--
Thiago
¹https://inbox.sourceware.org/gdb-patches/20220908064151.3959930-1-thiago.b…
Hello,
# [GNU-767] Support changing SVE vector length in remote debugging
- Cleaned up code for upstream submission, and divided it into patches.
A couple of the patches affect other architectures and OSes, so made
sure the code builds on as many combinations I can test, and now doing
final regression testing on some of them. I'm hoping to finally send
the patches upstream early next week.
--
Thiago
Hello,
# [GNU-767] Support changing SVE vector length in remote debugging
- Finished fixing regressions in my changes to gdbserver for debugging an
inferior which changes the SVE length.
- Started cleaning up code for upstream submission and dividing it into
patches.
# Community participation
- Reviewed mailing list patches:
- [PATCH,v3] [aarch64] Fix removal of non-address bits for PAuth
- [PATCH 1/2] gdb: Fix deleted thread when issuing next command
- [PATCH 2/2] gdb: Improve the resuming of the stepped thread
--
Thiago
Progress (short week, 3 days):
* UM-2 [QEMU upstream maintainership]
- pretty much just tying up loose ends and doing other
miscellaneous bits and pieces
* QEMU-422 [QEMU Arm Neoverse V1 vCPU for TCG]
- respin, resend of PMUv3p5 series
-- PMM
Hello,
# [GNU-767] Support changing SVE vector length in remote debugging
- v2 of the patches fixing a small SVE bug when debugging in native mode
an inferior which changes the SVE length was committed upstream.
- Continued working on fixing regressions in my changes to gdbserver for
debugging an inferior which changes the SVE length.
--
Thiago
Project Stratos
===============
- continued working on [adding vhost-user-rng to crosvm]
- this is to demo Stratos on Gunyah
- re-built guest kernel with known working backend
- it works :-)
- initial review of Viresh's slides for KVM Forum talk
[adding vhost-user-rng to crosvm]
<https://github.com/stsquad/crosvm/tree/add-vhost-user-rng>
vhost-device maintainer effort ([UM-196])
- prepared a clean-up [branch for new queue interface]
- spent time testing and realised it had broken things
[branch for new queue interface]
<https://github.com/stsquad/vhost-device/tree/update-queue-interface>
QEMU Upstream Work ([UM-2])
===========================
- posted [PULL for 7.1 0/3] memory leak and testing tweaks Message-Id:
<CAFEAcA8oPjTq9quHxOCSczckwmmBSP0fY6dtCzwrNs59pMrNCw(a)mail.gmail.com>
- sadly one patch had to be reverted as it exposed another race
[UM-2] <https://linaro.atlassian.net/browse/UM-2>
Completed Reviews [1/1]
=======================
[PATCH 00/62] target/arm: Implement FEAT_HAFDBS
Message-Id: <20220703082419.770989-1-richard.henderson(a)linaro.org>
Absences
========
- will take a long w/e for August BH
Current Review Queue
====================
TODO [PATCH v2 00/33] accel/tcg + target/arm: pc-relative translation
Message-Id: <20220816203400.161187-1-richard.henderson(a)linaro.org>
=======================================================================================================================================
TODO [PATCH for-7.2 00/21] accel/tcg: minimize tlb lookups during translate + user-only PROT_EXEC fixes
Message-Id: <20220812180806.2128593-22-richard.henderson(a)linaro.org>
===========================================================================================================================================================================
--
Alex Bennée
Progress:
* UM-2 [QEMU upstream maintainership]
- respin and resend for a few patchsets after code review
* QEMU-422 [QEMU Arm Neoverse V1 vCPU for TCG]
- identified what the old ARMv8.5-CMODX feature is now
("prefetch speculation protection") and confirmed that
QEMU is already compliant with the instruction fetch ordering
requirements so there's no coding work required here
- Checked that we implement FEAT_ETS already and sent patches
to advertise it in the ID registers
- Checked that we already conform to the ordering rules required
by "prefetch speculation protection"
- Discovered that we accidentally fail to RAZ for a big chunk
of the reserved-for-new-AArch32-ID-registers space for v8 CPUs;
sent patches fixing that
thanks
-- PMM
Hello Linaro Toolchain Working Group,
clang-arm64-windows-msvc is red for 12 days. The host is missing a correct
version of msvc.
Is somebody looking at this?
Thanks
Galina
Progress:
* UM-2 [QEMU upstream maintainership]
- usual release cycle work: rounded up a couple of last-minute
fixes for "whoops, this crashes" bugs and some safe changes like
docs typo fixes.
* QEMU-422 [QEMU Arm Neoverse V1 vCPU for TCG]
- Finished implementing the FEAT_PMUv3p5 work. In the process of
testing it I found a handful of bugs in our existing PMU
emulation code. Sent out the patchset which fixes those bugs and
adds FEAT_PMUv3p5.
- Cleaned up the epic to remove subtasks we aren't going to
implement (FEAT_SPE, FEAT_TRF), and added one for "actually
define the new CPU model"
- FEAT_LSE2 is the only remaining real work here, and it is
probably going to be seriously tricky...(i.e. I hope to leave
it to RTH ;-))
-- PMM
