KVM ARM Archive mirror
 help / color / mirror / Atom feed
From: James Morse <james.morse@arm.com>
To: linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev
Cc: Marc Zyngier <maz@kernel.org>,
	Oliver Upton <oliver.upton@linux.dev>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Zenghui Yu <yuzenghui@huawei.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Jing Zhang <jingzhangos@google.com>,
	James Morse <james.morse@arm.com>
Subject: [PATCH v3 0/6] KVM: arm64: Hide unsupported MPAM from the guest
Date: Thu, 21 Mar 2024 16:57:22 +0000	[thread overview]
Message-ID: <20240321165728.31907-1-james.morse@arm.com> (raw)

'lo

Sorry skipped a cycle, I got busy with the resctrl end of this, and it took
me a while to convince myself doing this can still work if we need to
prevent migration to incompatible hardware.

The change since v2 is to (mostly) ignore the value provided by user-space
as the simplest thing to do. The value is ignored when it matches the
sanitised hardware value - as that is the value exposed by the bug. But
otherwise is checked normally. This allows the value to be used to prevent
migration on some hypothetical MPAM==2 hardware if that is incompatible. If
it is compatible, the writeable-id-registers can be used. Sufficiently hairy
that I added a test.

~

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,
just ignore that field when it matches the hardware. KVM wasn't going to
expose MPAM anyway. The guest will not see MPAM in the id registers.

This series includes the head.S and KVM changes to enable/disable traps. If
MPAM is neither enabled nor emulated by EL3 firmware, these system register
accesses will trap to EL3.
If your kernel doesn't boot, and the problem bisects here - please update
your firmware. MPAM has been supported by trusted firmware since v1.6 in
2018. (also noted on patch 2).

This series is based on Linus' commit 23956900041d and can be retrieved from:
https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git
mpam/kvm_mpam_fix/v3

Sorry for the mid-merge window base, I'm away for a few weeks - this should
rebase trivially onto rc1.

Thanks

James

[v1] https://lore.kernel.org/linux-arm-kernel/20200925160102.118858-1-james.morse@arm.com/
[v2] https://lore.kernel.org/linux-arm-kernel/20231207150804.3425468-1-james.morse@arm.com/

James Morse (6):
  arm64: head.S: Initialise MPAM EL2 registers and disable traps
  arm64: cpufeature: discover CPU support for MPAM
  KVM: arm64: Fix missing traps of guest accesses to the MPAM registers
  KVM: arm64: Disable MPAM visibility by default and ignore VMM writes
  KVM: arm64: selftests: Move the bulky macro invocation to a helper
  KVM: arm64: selftests: Test ID_AA64PFR0.MPAM isn't completely ignored

 .../arch/arm64/cpu-feature-registers.rst      |   2 +
 arch/arm64/Kconfig                            |  19 +++-
 arch/arm64/include/asm/cpu.h                  |   1 +
 arch/arm64/include/asm/cpufeature.h           |  13 +++
 arch/arm64/include/asm/el2_setup.h            |  16 +++
 arch/arm64/include/asm/kvm_arm.h              |   1 +
 arch/arm64/include/asm/mpam.h                 |  75 +++++++++++++
 arch/arm64/include/asm/sysreg.h               |   8 ++
 arch/arm64/kernel/Makefile                    |   2 +
 arch/arm64/kernel/cpufeature.c                | 104 ++++++++++++++++++
 arch/arm64/kernel/cpuinfo.c                   |   4 +
 arch/arm64/kernel/image-vars.h                |   5 +
 arch/arm64/kernel/mpam.c                      |   8 ++
 arch/arm64/kvm/hyp/include/hyp/switch.h       |  32 ++++++
 arch/arm64/kvm/sys_regs.c                     |  43 +++++++-
 arch/arm64/tools/cpucaps                      |   1 +
 arch/arm64/tools/sysreg                       |  32 ++++++
 .../selftests/kvm/aarch64/set_id_regs.c       |  64 ++++++++++-
 18 files changed, 424 insertions(+), 6 deletions(-)
 create mode 100644 arch/arm64/include/asm/mpam.h
 create mode 100644 arch/arm64/kernel/mpam.c

-- 
2.39.2


             reply	other threads:[~2024-03-21 16:57 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-21 16:57 James Morse [this message]
2024-03-21 16:57 ` [PATCH v3 1/6] arm64: head.S: Initialise MPAM EL2 registers and disable traps James Morse
2024-03-21 16:57 ` [PATCH v3 2/6] arm64: cpufeature: discover CPU support for MPAM James Morse
2024-04-12 14:41   ` Will Deacon
2024-03-21 16:57 ` [PATCH v3 3/6] KVM: arm64: Fix missing traps of guest accesses to the MPAM registers James Morse
2024-03-21 16:57 ` [PATCH v3 4/6] KVM: arm64: Disable MPAM visibility by default and ignore VMM writes James Morse
2024-03-21 16:57 ` [PATCH v3 5/6] KVM: arm64: selftests: Move the bulky macro invocation to a helper James Morse
2024-03-21 16:57 ` [PATCH v3 6/6] KVM: arm64: selftests: Test ID_AA64PFR0.MPAM isn't completely ignored 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=20240321165728.31907-1-james.morse@arm.com \
    --to=james.morse@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=jingzhangos@google.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=maz@kernel.org \
    --cc=oliver.upton@linux.dev \
    --cc=suzuki.poulose@arm.com \
    --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 read-only IMAP folder(s) and NNTP newsgroup(s).