linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Oliver Upton <oliver.upton@linux.dev>
To: James Morse <james.morse@arm.com>
Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
	Marc Zyngier <maz@kernel.org>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Zenghui Yu <yuzenghui@huawei.com>
Subject: Re: [PATCH v2 0/4] KVM: arm64: Hide unsupported MPAM from the guest
Date: Wed, 13 Dec 2023 20:24:59 +0000	[thread overview]
Message-ID: <ZXoTG1Y4O16Cjq39@linux.dev> (raw)
In-Reply-To: <20231207150804.3425468-1-james.morse@arm.com>

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2023-12-13 20:25 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-07 15:08 [PATCH v2 0/4] KVM: arm64: Hide unsupported MPAM from the guest James Morse
2023-12-07 15:08 ` [PATCH v2 1/4] arm64: head.S: Initialise MPAM EL2 registers and disable traps James Morse
2023-12-07 15:08 ` [PATCH v2 2/4] arm64: cpufeature: discover CPU support for MPAM James Morse
2023-12-07 15:08 ` [PATCH v2 3/4] KVM: arm64: Fix missing traps of guest accesses to the MPAM registers James Morse
2023-12-07 15:08 ` [PATCH v2 4/4] KVM: arm64: Disable MPAM visibility by default, and handle traps James Morse
2023-12-13 20:24 ` Oliver Upton [this message]
2024-01-19 17:15   ` [PATCH v2 0/4] KVM: arm64: Hide unsupported MPAM from the guest James Morse
2024-01-23 19:00     ` Oliver Upton
2024-03-08 17:48       ` Jing Zhang
2024-03-21 15:37         ` James Morse

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=ZXoTG1Y4O16Cjq39@linux.dev \
    --to=oliver.upton@linux.dev \
    --cc=james.morse@arm.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=maz@kernel.org \
    --cc=suzuki.poulose@arm.com \
    --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).