[PATCH v2 0/4] KVM: arm64: Hide unsupported MPAM from the guest

[Oliver Upton]

Hi James,

Thank you very much for posting these fixes.

On Thu, Dec 07, 2023 at 03:08:00PM +0000, James Morse wrote:
> 'lo
> 
> This series fixes up a long standing bug where MPAM was accidentally exposed
> to a guest, but the feature was not otherwise trapped or context switched.
> This could result in KVM warning about unexpected traps, and injecting an
> undef into the guest contradicting the ID registers.
> This would prevent an MPAM aware kernel from booting - fortunately, there
> aren't any of those.
> 
> Ideally, we'd take the MPAM feature away from the ID registers, but that
> would leave existing guests unable to migrate to a newer kernel. Instead,
> use the writable ID registers to allow MPAM to be re-enabled - but emulate
> it as RAZ/WI for the system registers that are trapped.

This is certainly a reasonable approach, but TBH I'm not too terribly
concerned about the completeness of the workaround plumbing that we need
here. Undoubtedly what you propose is the most complete solution to the
problem, but it is somewhat involved.

So long as we don't break migration at the userspace ioctl level I'm not
too worried. Maybe something like:

 - Ensure the reset value of ID_AA64PFR0_EL1.MPAM is 0

 - Allow userspace to write ID_AA64PFR0_EL1.MPAM as 1, *but*

 - KVM reinterprets this as '0' behind the scenes for the final register
   value

 - Add the MPAM registers to the sysreg table with trap_raz_wi() as the
   handler to avoid the unsupported sysreg printk, since it is possible
   that older VMs may've already seen the MPAM feature.

We've already done something similar to hide our mistakes with IMP DEF
PMU versions in commit f90f9360c3d7 ("KVM: arm64: Rewrite IMPDEF PMU
version as NI"), and I think MPAM may be a good candidate for something
similar.

-- 
Thanks,
Oliver