Progress: * UM-2 [QEMU upstream maintainership] - catch up on email after a week away - Put together some arm pull requests - sent out draft QEMU summit minutes for review - sent patch to avoid using the buggy __builtin_subcll in Apple Clang 14 - sent patch fixing build error with newer xkeyboard-data - some gardening of Coverity issue reports

Last week was KVM Forum in Brno -- here's a quick trip summary:

This year KVM Forum was a slightly smaller conference (2 days, single-track), as we are now organizing it independently of the Linux Foundation. The independent organization went pretty well this year (despite the slightly awkward short notice) and the conference was very useful both for the talks and for the hallway track.

Interesting talks (just a sampling biased to my interests): * KVM: Arm Confidential Compute Architecture Support Suzuki Poulose presented a summary of FEAT_RME and the CCA hardware and software architecture, and how it's intended to fit into KVM * KVM/arm64: Episode V - The Blob Strikes Back Immediately following was Marc Zyngier and Oliver Upton from Google: their talk was a pretty strong critique of the CCA software stack architecture. Their central point is that having the RMM be "part of the firmware" rather than "part of the hypervisor" is going to cause a rerun of all the issues we've seen with dubious and non-upgradable vendor code in EL3. Secondly, having the fixed API between the hypervisor and the RMM restricts to least-common-denominator and provides no room for experimentation and optimizations. They want an architected way to deploy an RMM at boot time. * Handling complex guest exits with eBPF Will Deacon presented what he described as "conference driven development" -- an interesting prototype of having device models in the host kernel that are implemented in eBPF. This (in theory) gives you the performance gains of an in-kernel device without it putting a lot of C code onto the security boundary between the guest and host. * Challenges Revisited in Supporting Virt CPU Hotplug on architectures that don't Support CPU Hotplug (like ARM64) James Morse (Arm) and Salil Mehta (Huawei) presented on CPU hotplug. The underlying problem here remains that Arm has no hardware hotplug handling, so there's no clear model for what hotplug on a VM should look like. Cloud vendors have an obvious desire for the x86-style tooling to Just Work on Arm too. The gap between "we have a prototype that seems to work" and "upstreamable maintainable code" has not yet been bridged, though... * QEMU Arm CPU models and KVM Cornelia Huck (RedHat) had a talk that was intended as a statement of the problem rather than a proposed solution. At the moment we only let a KVM guest see the same CPU type as the host and don't have a mechanism for presenting a subset of features to it. KVM is about to get support for letting the VMM define what the guest should see in the ID registers, but how should we expose that to QEMU users without ending up with a thousand command line sub-options to turn on and off every architectural FEAT_FOO? And how do we deal with errata workarounds, which the guest currently selects based on the MIDR value?

As usual, we held the QEMU Summit (an hour-long maintainer discussion mostly about process and organizational issues) during KVM Forum. I still need to write up the minutes for this, but they'll be published on the qemu-devel list shortly.

thanks -- PMM