[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACw3F51xRWr5LXz4-JhK+mjizY7D7Oa+GrJ-OZHktfPzFGKeiw@mail.gmail.com>
Date: Fri, 11 Jul 2025 16:58:57 -0700
From: Jiaqi Yan <jiaqiyan@...gle.com>
To: Oliver Upton <oliver.upton@...ux.dev>
Cc: maz@...nel.org, joey.gouly@....com, suzuki.poulose@....com,
yuzenghui@...wei.com, catalin.marinas@....com, will@...nel.org,
pbonzini@...hat.com, corbet@....net, shuah@...nel.org, kvm@...r.kernel.org,
kvmarm@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
linux-kselftest@...r.kernel.org, duenwen@...gle.com, rananta@...gle.com,
jthoughton@...gle.com
Subject: Re: [PATCH v2 3/6] KVM: arm64: Allow userspace to inject external
instruction aborts
On Fri, Jul 11, 2025 at 12:42 PM Oliver Upton <oliver.upton@...ux.dev> wrote:
>
> On Wed, Jun 04, 2025 at 05:08:58AM +0000, Jiaqi Yan wrote:
> > From: Raghavendra Rao Ananta <rananta@...gle.com>
> >
> > When KVM returns to userspace for KVM_EXIT_ARM_SEA, the userspace is
> > encouraged to inject the abort into the guest via KVM_SET_VCPU_EVENTS.
> >
> > KVM_SET_VCPU_EVENTS currently only allows injecting external data aborts.
> > However, the synchronous external abort that caused KVM_EXIT_ARM_SEA
> > is possible to be an instruction abort. Userspace is already able to
> > tell if an abort is due to data or instruction via kvm_run.arm_sea.esr,
> > by checking its Exception Class value.
> >
> > Extend the KVM_SET_VCPU_EVENTS ioctl to allow injecting instruction
> > abort into the guest.
> >
> > Signed-off-by: Raghavendra Rao Ananta <rananta@...gle.com>
> > Signed-off-by: Jiaqi Yan <jiaqiyan@...gle.com>
>
> Hmm. Since we expose an ESR value to userspace I get the feeling that we
> should allow the user to supply an ISS for the external abort, similar
> to what we already do for SErrors.
Oh, I will create something in v3, by extending kvm_vcpu_events to
something like:
struct {
__u8 serror_pending;
__u8 serror_has_esr;
__u8 ext_dabt_pending;
__u8 ext_iabt_pending;
__u8 ext_abt_has_esr; // <= new
/* Align it to 8 bytes */
__u8 pad[3];
union {
__u64 serror_esr;
__u64 ext_abt_esr; // <= new
};
} exception;
One question about the naming since we cannot change it once
committed. Taking the existing SError injection as example, although
the name in kvm_vcpu_events is serror_has_esr, it is essentially just
the ISS fields of the ESR (which is also written in virt/kvm/api.rst).
Why named after "esr" instead of "iss"? The only reason I can think of
is, KVM wants to leave the room to accept more fields than ISS from
userspace. Does this reason apply to external aborts? Asking in case
if "iss" is a better name in kvm_vcpu_events, maybe for external
aborts, we should use ext_abt_has_iss?
>
> Thanks,
> Oliver
Powered by blists - more mailing lists