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