Re: [PATCH 00/16] KVM: arm64: Support debug, SVE, MOPS, PIE/POE, FPMR and more in protected VMs

[Oliver Upton <oupton@kernel.org>]

Hi Fuad,

On Mon, Nov 09, 2026 at 08:31:49AM +0000, Fuad Tabba wrote:
> Hi folks,
> 
> With most of the groundwork now merged, bringing protected VMs up to
> the features we support for them in Android turns out not to be a big
> series. So this folds self-hosted debug [1] and SVE [2], which I posted
> separately last week, into one series with the rest. Both are small,
> and keeping them apart would only leave a few conflicts where they add
> neighbouring lines to the pVM ID-register code. The debug and SVE
> patches are unchanged from those postings.
> 
>   01:     Self-hosted debug.
>   02-05:  SVE, with EL2 owning a protected vCPU's SVE state.
>   06-07:  Compute a protected vCPU's fine-grained traps at EL2.
>   08-16:  Advertise TCR2, SCTLR2, S1PIE, S1POE, MOPS, FPMR and the
>           features EL2 already handles for non-protected guests.
> 
> Tested on QEMU, in hVHE and nVHE, and on FVP for S1POE and the fields
> QEMU doesn't model (CLRBHB, RPRFM, ECBHB, LSFE, LSUI, HAFT, ETS3 and
> F16MM). v2 of the pKVM selftests series [3] will cover debug, SVE,
> MOPS, PIE, POE and FPMR.
> 
> Based on Linux 7.4-rc1 (6628e7d4c6b25); it also applies to 7.4-rc2
> (7475ea8b58616).
> 
> Cheers,
> /fuad
> 
> [1] https://lore.kernel.org/all/20261102093950.2922035-1-fuad.tabba@linux.dev/
> [2] https://lore.kernel.org/all/20261105130456.1617185-1-fuad.tabba@linux.dev/
> [3] https://lore.kernel.org/all/20261104084842.132944-1-fuad.tabba@linux.dev/

Ok, we really need to slow down the rate of patches here. I had already
applied the SVE series locally and now we've got a grab-bag of CPU
features in addition to what I was ready to apply.

The whole point of respinning a series is so we can converge on the
shape of the feature and get it merged. Adding a whole pile of things
that wasn't asked for just muddies the context for us dumb humans and
slows down the rate at which you're going to land things upstream.

Going forward, can you please:

 - Keep an individual series focused on the original intent. Don't
   unnecessarily expand scope.

 - Only iterate on a couple of series on the list at a time. Sashiko
   findings are interesting, but you're gonna have to draw a cutline in
   terms of how many additional patches are going to ride the coattails
   of any particular series.

   You're obviously a very active contributor and reviewer, so I don't
   anticipate such a rate limit to actually impede your patch velocity.

Sorry, I really do appreciate the amount of work that you're doing to
get pKVM in good shape upstream. I just get the sense that Marc and I
are going to quickly encounter bandwidth limitations.

Thanks,
Oliver