[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linaro-toolchain
Subject:    [ACTIVITY] report week ending 23 Jun (inc. KVM Forum trip report)
From:       Peter Maydell <peter.maydell () linaro ! org>
Date:       2023-06-23 15:32:44
Message-ID: CAFEAcA9N1eaeDqwcyOCqWkTqp4=rXcAK-_yxnWSDyEEGW-fPrw () mail ! gmail ! com
[Download RAW message or body]

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
_______________________________________________
linaro-toolchain mailing list -- linaro-toolchain@lists.linaro.org
To unsubscribe send an email to linaro-toolchain-leave@lists.linaro.org
[prev in list] [next in list] [prev in thread] [next in thread]