Re: [RFC PATCH v7 00/28] KVM: arm64: Add Statistical Profiling Extension (SPE) support

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

Hi Alex,

I've gone through all of the patches now, thank you for your patience with
the review :)

So there are various dependencies/architectural decisions that need to be
made here to go from RFC -> non-RFC:

1. The 'Ignore MMU notifiers for guest_memfd-only memslots' patch [0] is a
   hard dependency for the series. I chased over there, hopefully we can
   get something landed there.

2. non-VHE, pKVM, NV disallowed for SPE - As I mentioned off-list, I spoke
   to Marc, and he confirmed that he's more than happy for these to be off
   the table for a v1. So I think you can drop the HACK: patches and just
   make these conditions of using SPE.

3. The entire VM needs to be pre-faulted, but who should do it? - I do
   think that relying on userland to do this is a little iffy. So I wonder
   whether it might be possible to, on SPE first run, prefault the ranges
   there, and make that a condition of using it? Relatedly, KVM could
   reject non-guest_memfd memslots for an SPE VM rather than trusting
   userspace there too.

4. Dirty page logging - patch 27/28 relies on series [1] being landed,
   which is also an RFC, and allows migration of SPE VMs. So we need to
   decide - do we want this migration? Additionally, I think it's
   reasonable to, if we want it, send both [1] and patch 27/28 as a follow
   up separate from the v1 non-RFC of the series.

5. Errata handling - the default already disallows SPE on the affected
   silicon, which seems right. I wonder whether kvm-arm.ignore_spe_errata
   should exist at all though, other than in some sort of debug mode.

So 1 is a known dependency, I think there's no getting around that, and
thus that makes merging [0] or something like it a top priority.

It seems to me 2 is pretty clear-cut, and 4 can reasonably (if we want it)
be sent as a follow up.

So really 3 and 5 are the decisions to make here!

--
Cheers, Lorenzo

[0]: https://lore.kernel.org/all/20260714160411.302386-1-alexandru.elisei@arm.com/
[1]: https://lore.kernel.org/kvmarm/20260702142912.6395-1-alexandru.elisei@arm.com/