Marc, Joey,
On Tue, Dec 17, 2024 at 10:40:58AM GMT, Joey Gouly wrote:
> On Sun, Dec 15, 2024 at 10:22:53AM +0100, Greg KH wrote:
> > On Thu, Dec 12, 2024 at 03:14:06PM +0000, Joey Gouly wrote:
> > > From: James Morse <james.morse@xxxxxxx>
> > >
> > > 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@xxxxxxx>
> > > Co-developed-by: Joey Gouly <joey.gouly@xxxxxxx>
> > > Signed-off-by: Joey Gouly <joey.gouly@xxxxxxx>
> > > Reviewed-by: Gavin Shan <gshan@xxxxxxxxxx>
> > > Tested-by: Shameer Kolothum <shameerali.kolothum.thodi@xxxxxxxxxx>
> > > Reviewed-by: Marc Zyngier <maz@xxxxxxxxxx>
> > > Link: https://lore.kernel.org/r/20241030160317.2528209-7-joey.gouly@xxxxxxx
> > > Signed-off-by: Oliver Upton <oliver.upton@xxxxxxxxx>
> > > [ joey: fixed up merge conflict, no ID_FILTERED macro in 6.6 ]
> > > Signed-off-by: Joey Gouly <joey.gouly@xxxxxxx>
> > > Cc: stable@xxxxxxxxxxxxxxx # 6.6.x
> > > Cc: Vitaly Chikunov <vt@xxxxxxxxxxxx>
> > > Link: https://lore.kernel.org/linux-arm-kernel/20241202045830.e4yy3nkvxtzaybxk@xxxxxxxxxxxx/
> > > ---
> > >
> > > 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?
>
> I did have it ported/tested locally, but I wasn't sure of the stable process,
> so just sent out one! Next time I will send all the backports at the same
> time.
>
> Thanks Marc Z for sending it out!
Thank you for backporting this, and thanks to everyone involved in the fix.
Vitaly,
>
> Joey
