linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Joey Gouly <joey.gouly@arm.com>,
	stable@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	kvmarm@lists.linux.dev, gshan@redhat.com, james.morse@arm.com,
	oliver.upton@linux.dev, shameerali.kolothum.thodi@huawei.com,
	vt@altlinux.org, Suzuki K Poulose <suzuki.poulose@arm.com>,
	Zenghui Yu <yuzenghui@huawei.com>,
	Jing Zhang <jingzhangos@google.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>
Subject: Re: [PATCH 6.6 v1] KVM: arm64: Disable MPAM visibility by default and ignore VMM writes
Date: Mon, 16 Dec 2024 08:51:38 +0000	[thread overview]
Message-ID: <86a5cwrox1.wl-maz@kernel.org> (raw)
In-Reply-To: <2024121528-refurbish-plausibly-31c7@gregkh>

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@altlinux.org/
> > ---
> > 
> > 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

-- 
Without deviation from the norm, progress is not possible.


  reply	other threads:[~2024-12-16  8:53 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-12 15:14 [PATCH 6.6 v1] KVM: arm64: Disable MPAM visibility by default and ignore VMM writes Joey Gouly
2024-12-15  9:22 ` Greg KH
2024-12-16  8:51   ` Marc Zyngier [this message]
2024-12-17 10:40   ` Joey Gouly
2024-12-19 10:49     ` Vitaly Chikunov
2024-12-16  8:52 ` Marc Zyngier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86a5cwrox1.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=gshan@redhat.com \
    --cc=james.morse@arm.com \
    --cc=jingzhangos@google.com \
    --cc=joey.gouly@arm.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=oliver.upton@linux.dev \
    --cc=shameerali.kolothum.thodi@huawei.com \
    --cc=stable@vger.kernel.org \
    --cc=suzuki.poulose@arm.com \
    --cc=vt@altlinux.org \
    --cc=will@kernel.org \
    --cc=yuzenghui@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).