On Sun, 15 Dec 2024 09:22:53 +0000, Greg KH gregkh@linuxfoundation.org wrote:
On Thu, Dec 12, 2024 at 03:14:06PM +0000, Joey Gouly wrote:
From: James Morse james.morse@arm.com
commit 6685f5d572c22e1003e7c0d089afe1c64340ab1f upstream.
commit 011e5f5bf529f ("arm64/cpufeature: Add remaining feature bits in ID_AA64PFR0 register") exposed the MPAM field of AA64PFR0_EL1 to guests, but didn't add trap handling. A previous patch supplied the missing trap handling.
Existing VMs that have the MPAM field of ID_AA64PFR0_EL1 set need to be migratable, but there is little point enabling the MPAM CPU interface on new VMs until there is something a guest can do with it.
Clear the MPAM field from the guest's ID_AA64PFR0_EL1 and on hardware that supports MPAM, politely ignore the VMMs attempts to set this bit.
Guests exposed to this bug have the sanitised value of the MPAM field, so only the correct value needs to be ignored. This means the field can continue to be used to block migration to incompatible hardware (between MPAM=1 and MPAM=5), and the VMM can't rely on the field being ignored.
Signed-off-by: James Morse james.morse@arm.com Co-developed-by: Joey Gouly joey.gouly@arm.com Signed-off-by: Joey Gouly joey.gouly@arm.com Reviewed-by: Gavin Shan gshan@redhat.com Tested-by: Shameer Kolothum shameerali.kolothum.thodi@huawei.com Reviewed-by: Marc Zyngier maz@kernel.org Link: https://lore.kernel.org/r/20241030160317.2528209-7-joey.gouly@arm.com Signed-off-by: Oliver Upton oliver.upton@linux.dev [ joey: fixed up merge conflict, no ID_FILTERED macro in 6.6 ] Signed-off-by: Joey Gouly joey.gouly@arm.com Cc: stable@vger.kernel.org # 6.6.x Cc: Vitaly Chikunov vt@altlinux.org Link: https://lore.kernel.org/linux-arm-kernel/20241202045830.e4yy3nkvxtzaybxk@alt...
This fixes an issue seen when using KVM with a 6.6 host kernel, and newer (6.13+) kernels in the guest.
Tested with a stripped down version of set_id_regs from the original patch series.
What about 6.12.y? You can't just skip a stable tree, otherwise you will get a regression when you upgrade to 6.12.y, right?
Posted as [1].
M.
[1] https://lore.kernel.org/r/20241216085002.334880-1-maz@kernel.org