[0/4] KVM: arm64: Parallel access faults

Message

Oliver Upton Nov. 29, 2022, 7:19 p.m. UTC

When I implemented the parallel faults series I was mostly focused on
improving the performance of 8.1+ implementations which bring us
FEAT_HAFDBS. In so doing, I failed to put access faults on the read side
of the MMU lock.

Anyhow, this small series adds support for handling access faults in
parallel, piling on top of the infrastructure from the first parallel
faults series. As most large systems I'm aware of are 8.1+ anyway, I
don't expect this series to provide significant uplift beyond some
oddball machines Marc has lying around. Don't get me wrong, I'd love to
have a D05 to play with too...

Patches 1-3 are the significant portion of the series, and patch 4 was
used to test on an Ampere Altra system by guarding VTCR_EL2.HA with the
kernel's Kconfig option for FEAT_HAFDBS. I've included it as I find it
helpful for testing on newer hardware. Having said that, I won't throw a
fit if it gets dropped either.

Applies to kvmarm/next due to the dependency on the larger parallel
faults series. Tested on Ampere Altra w/ VTCR_EL2.HA=0 as well as a
Raspberry Pi 4.

Oliver Upton (4):
  KVM: arm64: Use KVM's pte type/helpers in handle_access_fault()
  KVM: arm64: Don't serialize if the access flag isn't set
  KVM: arm64: Handle access faults behind the read lock
  KVM: arm64: Condition HW AF updates on config option

 arch/arm64/include/asm/kvm_pgtable.h |  5 +++++
 arch/arm64/kvm/hyp/pgtable.c         | 12 +++++++++---
 arch/arm64/kvm/mmu.c                 | 14 ++++++--------
 3 files changed, 20 insertions(+), 11 deletions(-)


base-commit: 456ce3545dd06700df7fe82173a06b369288bcef

Comments

Marc Zyngier Nov. 30, 2022, 4:54 p.m. UTC | #1

On Tue, 29 Nov 2022 19:19:42 +0000,
Oliver Upton <[e-mail]> wrote:
> 
> When I implemented the parallel faults series I was mostly focused on
> improving the performance of 8.1+ implementations which bring us
> FEAT_HAFDBS. In so doing, I failed to put access faults on the read side
> of the MMU lock.
> 
> Anyhow, this small series adds support for handling access faults in
> parallel, piling on top of the infrastructure from the first parallel
> faults series. As most large systems I'm aware of are 8.1+ anyway, I
> don't expect this series to provide significant uplift beyond some
> oddball machines Marc has lying around. Don't get me wrong, I'd love to
> have a D05 to play with too...

Hey, that puts the whole fruity range of machines in the oddball
department too, as they don't implement any of HAFDBS!

The feature being optional, I wouldn't be surprised if others would
either not implement it (or disable it to hide that it is b0rk3n...).

	M.