linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Oliver Upton <oliver.upton@linux.dev>
To: kvmarm@lists.linux.dev
Cc: Marc Zyngier <maz@kernel.org>, James Morse <james.morse@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Zenghui Yu <yuzenghui@huawei.com>, Will Deacon <will@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Fuad Tabba <tabba@google.com>,
	linux-arm-kernel@lists.infradead.org, surajjs@amazon.com,
	Cornelia Huck <cohuck@redhat.com>,
	Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>,
	Jing Zhang <jingzhangos@google.com>,
	Oliver Upton <oliver.upton@linux.dev>
Subject: [PATCH v12 00/11] Support writable CPU ID registers from userspace
Date: Fri,  9 Jun 2023 19:00:43 +0000	[thread overview]
Message-ID: <20230609190054.1542113-1-oliver.upton@linux.dev> (raw)

Hello folks,

In the interest of expediting the acceptance of the generalized ID
register infrastructure, I have taken Jing's series and applied fixes
according to the feedback of reviewers and my own interpretation.

The laundry list:
 - Split and reorganize the changes to avoid introducing intermediate
   regressions in the series. Don't want to break bisection! Sadly,
   this requires introducing a bit of churn but to me is an acceptable
   tradeoff.

 - Split up monster changes into more bite-sized chunks.

 - Actually delete the old masking logic when we no longer use it.

 - Reinterpret IMP_DEF PMUs as NI at the time of write

 - Move locking back into ID reg specific code. Let it be known: if you
   want to do custom ->set_user() logic for an ID register, it better
   find its way into set_id_reg().

 - Rewrite kvm_vcpu_set_target() into something that's a bit more
   cognizant of the existence of a bitmap.

 - Prevent userspace from configuring asymmetric vCPU features. Yep,
   this is technically user-visible breakage, but has been a long time
   coming. Asymmetry in KVM has always worked by chance, and is
   inconsistent with the overall handling of asymmetry in the kernel.
   If this breaks you: now's your chance to plead your usecase.

 - Rip out the PMUVer <-> PerfMon bidirectional pipe. Making things
   consistent between the 32bit and 64bit worlds is needlessly
   complicated, and the only thing we care about in KVM is that the
   advertised feature set aligns with the limits of the system/VM.

 - Allow the value of KVM_ARM_VCPU_POWER_OFF to change between calls. It
   doesn't make sense in the context of a VM-wide feature set, and we
   may as well let userspace do whatever it wants with the bit.

 - Opportunistically rewrite sysreg definitions to use the new syntax.

Tested with selftests, kvm-unit-tests, as well as booting an actual VM
with kvmtool + QEMU.

v11: https://lore.kernel.org/kvmarm/20230602005118.2899664-1-jingzhangos@google.com/

Jing Zhang (5):
  KVM: arm64: Reuse fields of sys_reg_desc for idreg
  KVM: arm64: Save ID registers' sanitized value per guest
  KVM: arm64: Use arm64_ftr_bits to sanitise ID register writes
  KVM: arm64: Use generic sanitisation for ID_(AA64)DFR0_EL1
  KVM: arm64: Use generic sanitisation for ID_AA64PFR0_EL1

Oliver Upton (6):
  KVM: arm64: Separate out feature sanitisation and initialisation
  KVM: arm64: Relax invariance of KVM_ARM_VCPU_POWER_OFF
  KVM: arm64: Make vCPU feature flags consistent VM-wide
  KVM: arm64: Rewrite IMPDEF PMU version as NI
  KVM: arm64: Handle ID register reads using the VM-wide values
  KVM: arm64: Rip out the vestiges of the 'old' ID register scheme

 arch/arm64/include/asm/cpufeature.h  |   1 +
 arch/arm64/include/asm/kvm_emulate.h |   7 +-
 arch/arm64/include/asm/kvm_host.h    |  45 +--
 arch/arm64/kernel/cpufeature.c       |   2 +-
 arch/arm64/kvm/arm.c                 | 134 +++++---
 arch/arm64/kvm/reset.c               |  58 ----
 arch/arm64/kvm/sys_regs.c            | 493 +++++++++++++++++++--------
 arch/arm64/kvm/sys_regs.h            |  22 +-
 include/kvm/arm_pmu.h                |   8 +-
 9 files changed, 478 insertions(+), 292 deletions(-)


base-commit: 7877cb91f1081754a1487c144d85dc0d2e2e7fc4
-- 
2.41.0.162.gfafddb0af9-goog


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

             reply	other threads:[~2023-06-09 19:01 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-09 19:00 Oliver Upton [this message]
2023-06-09 19:00 ` [PATCH v12 01/11] KVM: arm64: Separate out feature sanitisation and initialisation Oliver Upton
2023-06-09 19:00 ` [PATCH v12 02/11] KVM: arm64: Relax invariance of KVM_ARM_VCPU_POWER_OFF Oliver Upton
2023-06-09 19:00 ` [PATCH v12 03/11] KVM: arm64: Make vCPU feature flags consistent VM-wide Oliver Upton
2023-06-09 19:00 ` [PATCH v12 04/11] KVM: arm64: Rewrite IMPDEF PMU version as NI Oliver Upton
2023-06-09 19:00 ` [PATCH v12 05/11] KVM: arm64: Reuse fields of sys_reg_desc for idreg Oliver Upton
2023-06-09 19:00 ` [PATCH v12 06/11] KVM: arm64: Save ID registers' sanitized value per guest Oliver Upton
2023-06-09 19:00 ` [PATCH v12 07/11] KVM: arm64: Use arm64_ftr_bits to sanitise ID register writes Oliver Upton
2023-06-15 12:38   ` Marc Zyngier
2023-06-15 12:45     ` Oliver Upton
2023-06-09 19:00 ` [PATCH v12 08/11] KVM: arm64: Use generic sanitisation for ID_(AA64)DFR0_EL1 Oliver Upton
2023-06-09 19:00 ` [PATCH v12 09/11] KVM: arm64: Use generic sanitisation for ID_AA64PFR0_EL1 Oliver Upton
2023-06-09 19:00 ` [PATCH v12 10/11] KVM: arm64: Handle ID register reads using the VM-wide values Oliver Upton
2023-06-09 19:00 ` [PATCH v12 11/11] KVM: arm64: Rip out the vestiges of the 'old' ID register scheme Oliver Upton
2023-06-09 19:08 ` [PATCH v12 00/11] Support writable CPU ID registers from userspace Oliver Upton
2023-06-15 13:20 ` Oliver Upton
2023-06-15 13:30 ` 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=20230609190054.1542113-1-oliver.upton@linux.dev \
    --to=oliver.upton@linux.dev \
    --cc=catalin.marinas@arm.com \
    --cc=cohuck@redhat.com \
    --cc=james.morse@arm.com \
    --cc=jingzhangos@google.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=maz@kernel.org \
    --cc=shameerali.kolothum.thodi@huawei.com \
    --cc=surajjs@amazon.com \
    --cc=suzuki.poulose@arm.com \
    --cc=tabba@google.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 NNTP newsgroup(s).