Linux Documentation
 help / color / mirror / Atom feed
From: Jiaqi Yan <jiaqiyan@google.com>
To: maz@kernel.org, oliver.upton@linux.dev
Cc: joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com,
	 catalin.marinas@arm.com, will@kernel.org, pbonzini@redhat.com,
	corbet@lwn.net,  shuah@kernel.org, kvm@vger.kernel.org,
	kvmarm@lists.linux.dev,  linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,  linux-doc@vger.kernel.org,
	linux-kselftest@vger.kernel.org,  rananta@google.com,
	Jiaqi Yan <jiaqiyan@google.com>
Subject: [PATCH v1 0/4] A couple of improvements for VMM to inject external abort to guest
Date: Thu, 31 Jul 2025 21:20:00 +0000	[thread overview]
Message-ID: <20250731212004.1437336-1-jiaqiyan@google.com> (raw)

There are several situations where VMM is involved when handling
synchronous external instruction or data aborts, and often VMM
needs to inject external aborts to guest. In addition to manipulating
individual registers with KVM_SET_ONE_REG API, an easier way is to
use the KVM_SET_VCPU_EVENTS API.

This patchset adds two new features to the KVM_SET_VCPU_EVENTS API.
1. Extend KVM_SET_VCPU_EVENTS to support external instruction abort.
2. Allow userspace to emulate ESR_ELx.ISS by supplying ESR_ELx.
   In this way, we can also allow userspace to emulate ESR_ELx.ISS2
   in future.

The UAPI change for #1 is straightforward. However, I would appreciate
some feedback on the ABI change for #2:

  struct kvm_vcpu_events {
    struct {
        __u8 serror_pending;
        __u8 serror_has_esr;
        __u8 ext_dabt_pending;
        __u8 ext_iabt_pending;
        __u8 ext_abt_has_esr;
        __u8 pad[3];
        __u64 serror_esr;
        __u64 ext_abt_esr;  // <= +8 bytes
      } exception;
    __u32 reserved[10];     // <= -8 bytes
  };

The offset to kvm_vcpu_events.reserved changes, and the size of
exception changes. I think we can't say userspace will never access
reserved, or they will never use sizeof(exception). Theoretically this
is an ABI break and I want to call it out and ask if a new ABI is needed
for feature #2. For example, is it worthy to introduce exception_v2
or kvm_vcpu_events_v2.

Based on commit 7b8346bd9fce6 ("KVM: arm64: Don't attempt vLPI mappings
when vPE allocation is disabled")

Jiaqi Yan (3):
  KVM: arm64: Allow userspace to supply ESR when injecting SEA
  KVM: selftests: Test injecting external abort with ISS
  Documentation: kvm: update UAPI for injecting SEA

Raghavendra Rao Ananta (1):
  KVM: arm64: Allow userspace to inject external instruction abort

 Documentation/virt/kvm/api.rst                |  48 +++--
 arch/arm64/include/asm/kvm_emulate.h          |   9 +-
 arch/arm64/include/uapi/asm/kvm.h             |   7 +-
 arch/arm64/kvm/arm.c                          |   1 +
 arch/arm64/kvm/emulate-nested.c               |   6 +-
 arch/arm64/kvm/guest.c                        |  42 ++--
 arch/arm64/kvm/inject_fault.c                 |  16 +-
 include/uapi/linux/kvm.h                      |   1 +
 tools/arch/arm64/include/uapi/asm/kvm.h       |   7 +-
 .../selftests/kvm/arm64/external_aborts.c     | 191 +++++++++++++++---
 .../testing/selftests/kvm/arm64/inject_iabt.c |  98 +++++++++
 11 files changed, 352 insertions(+), 74 deletions(-)
 create mode 100644 tools/testing/selftests/kvm/arm64/inject_iabt.c

-- 
2.50.1.565.gc32cd1483b-goog


             reply	other threads:[~2025-07-31 21:20 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-31 21:20 Jiaqi Yan [this message]
2025-07-31 21:20 ` [PATCH v1 1/4] KVM: arm64: Allow userspace to inject external instruction abort Jiaqi Yan
2025-07-31 21:20 ` [PATCH v1 2/4] KVM: arm64: Allow userspace to supply ESR when injecting SEA Jiaqi Yan
2025-07-31 21:20 ` [PATCH v1 3/4] KVM: selftests: Test injecting external abort with ISS Jiaqi Yan
2025-07-31 21:20 ` [PATCH v1 4/4] Documentation: kvm: update UAPI for injecting SEA Jiaqi Yan

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=20250731212004.1437336-1-jiaqiyan@google.com \
    --to=jiaqiyan@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=corbet@lwn.net \
    --cc=joey.gouly@arm.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=oliver.upton@linux.dev \
    --cc=pbonzini@redhat.com \
    --cc=rananta@google.com \
    --cc=shuah@kernel.org \
    --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