mbox series

[v4,00/10] arm64: Add support for FEAT_E2H0, or lack thereof

Message ID 20240122181344.258974-1-maz@kernel.org (mailing list archive)
Headers show
Series arm64: Add support for FEAT_E2H0, or lack thereof | expand

Message

Marc Zyngier Jan. 22, 2024, 6:13 p.m. UTC
Since ARMv8.1, the architecture has grown the VHE feature, which makes
EL2 a superset of EL1. With ARMv9.5 (and retroactively allowed from
ARMv8.1), the architecture allows implementations to have VHE as the
*only* implemented behaviour, meaning that HCR_EL2.E2H can be
implemented as RES1. As a follow-up, HCR_EL2.NV1 can also be
implemented as RES0, making the VHE-ness of the architecture
recursive.

This has a number of consequences, both at boot time and for KVM,
though the changes at that level are pretty minor.

The real meat of this series is on the cpufeature front, as FEAT_E2H0
is a *negative* feature, where 0b1111 (-1) represents E2H being RES1
and 0b1110 (-2) additionally indicates that NV1 is RES0. Fun, isn't
it?

As a bonus, a popular crop of non-compliant HW gets promoted as the
first batch of non-zero E2H0 users, making things easy for KVM.

This series is a prefix for the NV support.

* From v3 [3]:
  - Dropped the capability for E2H being RES1
  - Dropped the MIDR-based IDreg override
  - Rebased on 6.8-rc1

* From v2 [2]:
  - Moved some SYS_FIELD_VALUE() usage to the correct patch
  - Fixed a couple of spelling mistakes
  - Picked RBs from Suzuki (thanks!)

* From v1 [1]:
  - Added a SYS_FIELD_VALUE() helper to handle the concatenation
    of various fields
  - Only test for the top bit of ID_AA64MMFR4_EL1.E2H0 to decide
    whether HCR_EL2.E2H is RES1.
  - Picked RBs from Oliver (thanks!)
  - Rebased on 6.7-rc2

[1] https://lore.kernel.org/r/20231113174244.3026520-1-maz@kernel.org
[2] https://lore.kernel.org/r/20231120123721.851738-1-maz@kernel.org
[3] https://lore.kernel.org/r/20231127114559.990314-1-maz@kernel.org

Marc Zyngier (10):
  arm64: Add macro to compose a sysreg field value
  arm64: cpufeatures: Correctly handle signed values
  arm64: cpufeature: Correctly display signed override values
  arm64: sysreg: Add layout for ID_AA64MMFR4_EL1
  arm64: cpufeature: Add ID_AA64MMFR4_EL1 handling
  arm64: cpufeature: Detect HCR_EL2.NV1 being RES0
  arm64: Treat HCR_EL2.E2H as RES1 when ID_AA64MMFR4_EL1.E2H0 is
    negative
  KVM: arm64: Expose ID_AA64MMFR4_EL1 to guests
  KVM: arm64: Force guest's HCR_EL2.E2H RES1 when NV1 is not implemented
  KVM: arm64: Handle Apple M2 as not having HCR_EL2.NV1 implemented

 arch/arm64/include/asm/cpu.h         |   1 +
 arch/arm64/include/asm/cpufeature.h  |   1 +
 arch/arm64/include/asm/kvm_emulate.h |   3 +-
 arch/arm64/include/asm/sysreg.h      |   5 +-
 arch/arm64/kernel/cpufeature.c       | 103 ++++++++++++++++++++++++---
 arch/arm64/kernel/cpuinfo.c          |   1 +
 arch/arm64/kernel/head.S             |  23 +++---
 arch/arm64/kvm/nested.c              |   7 ++
 arch/arm64/kvm/sys_regs.c            |  17 ++++-
 arch/arm64/tools/cpucaps             |   1 +
 arch/arm64/tools/sysreg              |  37 ++++++++++
 11 files changed, 176 insertions(+), 23 deletions(-)

Comments

Oliver Upton Feb. 2, 2024, 7:03 p.m. UTC | #1
On Mon, Jan 22, 2024 at 06:13:34PM +0000, Marc Zyngier wrote:
> Since ARMv8.1, the architecture has grown the VHE feature, which makes
> EL2 a superset of EL1. With ARMv9.5 (and retroactively allowed from
> ARMv8.1), the architecture allows implementations to have VHE as the
> *only* implemented behaviour, meaning that HCR_EL2.E2H can be
> implemented as RES1. As a follow-up, HCR_EL2.NV1 can also be
> implemented as RES0, making the VHE-ness of the architecture
> recursive.
> 
> This has a number of consequences, both at boot time and for KVM,
> though the changes at that level are pretty minor.
> 
> The real meat of this series is on the cpufeature front, as FEAT_E2H0
> is a *negative* feature, where 0b1111 (-1) represents E2H being RES1
> and 0b1110 (-2) additionally indicates that NV1 is RES0. Fun, isn't
> it?

This looks good to me. Catalin + Will, are you comfortable with the
cpufeature changes at this point?

No strong opinions on which tree these patches get applied to. Most of
the series is non-KVM code, so I'd understand if y'all wanted it to go
through arm64. OTOH, there are some other KVM features that might appear
in 6.9 that build on top of this, so at minimum I'd probably need a
shared branch.

LMK what you think.
Catalin Marinas Feb. 8, 2024, 12:30 p.m. UTC | #2
On Fri, Feb 02, 2024 at 07:03:25PM +0000, Oliver Upton wrote:
> On Mon, Jan 22, 2024 at 06:13:34PM +0000, Marc Zyngier wrote:
> > Since ARMv8.1, the architecture has grown the VHE feature, which makes
> > EL2 a superset of EL1. With ARMv9.5 (and retroactively allowed from
> > ARMv8.1), the architecture allows implementations to have VHE as the
> > *only* implemented behaviour, meaning that HCR_EL2.E2H can be
> > implemented as RES1. As a follow-up, HCR_EL2.NV1 can also be
> > implemented as RES0, making the VHE-ness of the architecture
> > recursive.
> > 
> > This has a number of consequences, both at boot time and for KVM,
> > though the changes at that level are pretty minor.
> > 
> > The real meat of this series is on the cpufeature front, as FEAT_E2H0
> > is a *negative* feature, where 0b1111 (-1) represents E2H being RES1
> > and 0b1110 (-2) additionally indicates that NV1 is RES0. Fun, isn't
> > it?
> 
> This looks good to me. Catalin + Will, are you comfortable with the
> cpufeature changes at this point?

Yes, I acked those touching the arm64 files.

> No strong opinions on which tree these patches get applied to. Most of
> the series is non-KVM code, so I'd understand if y'all wanted it to go
> through arm64. OTOH, there are some other KVM features that might appear
> in 6.9 that build on top of this, so at minimum I'd probably need a
> shared branch.

Please take it through the arm64 kvm tree but keep it on a separate
stable branch in case I need to pull it.
Oliver Upton Feb. 8, 2024, 3:24 p.m. UTC | #3
On Mon, 22 Jan 2024 18:13:34 +0000, Marc Zyngier wrote:
> Since ARMv8.1, the architecture has grown the VHE feature, which makes
> EL2 a superset of EL1. With ARMv9.5 (and retroactively allowed from
> ARMv8.1), the architecture allows implementations to have VHE as the
> *only* implemented behaviour, meaning that HCR_EL2.E2H can be
> implemented as RES1. As a follow-up, HCR_EL2.NV1 can also be
> implemented as RES0, making the VHE-ness of the architecture
> recursive.
> 
> [...]

Thanks folks for having taken a look at the series. I've pushed it out
to kvmarm/next.

Catalin, as requested here is the shared branch:

  https://git.kernel.org/pub/scm/linux/kernel/git/oupton/linux.git/log/?h=kvm-arm64/feat_e2h0

[01/10] arm64: Add macro to compose a sysreg field value
        https://git.kernel.org/kvmarm/kvmarm/c/53eaeb7fbe27
[02/10] arm64: cpufeatures: Correctly handle signed values
        https://git.kernel.org/kvmarm/kvmarm/c/d9a065914dcc
[03/10] arm64: cpufeature: Correctly display signed override values
        https://git.kernel.org/kvmarm/kvmarm/c/d42bf63fd4db
[04/10] arm64: sysreg: Add layout for ID_AA64MMFR4_EL1
        https://git.kernel.org/kvmarm/kvmarm/c/cfc680bb04c5
[05/10] arm64: cpufeature: Add ID_AA64MMFR4_EL1 handling
        https://git.kernel.org/kvmarm/kvmarm/c/805bb61f8279
[06/10] arm64: cpufeature: Detect HCR_EL2.NV1 being RES0
        https://git.kernel.org/kvmarm/kvmarm/c/da9af5071b25
[07/10] arm64: Treat HCR_EL2.E2H as RES1 when ID_AA64MMFR4_EL1.E2H0 is negative
        https://git.kernel.org/kvmarm/kvmarm/c/3944382fa6f2
[08/10] KVM: arm64: Expose ID_AA64MMFR4_EL1 to guests
        https://git.kernel.org/kvmarm/kvmarm/c/c21df6e43f0e
[09/10] KVM: arm64: Force guest's HCR_EL2.E2H RES1 when NV1 is not implemented
        https://git.kernel.org/kvmarm/kvmarm/c/94f29ab2d801
[10/10] KVM: arm64: Handle Apple M2 as not having HCR_EL2.NV1 implemented
        https://git.kernel.org/kvmarm/kvmarm/c/aade38faca63

--
Best,
Oliver