On Fri, Jul 11, 2025 at 12:42 PM Oliver Upton oliver.upton@linux.dev wrote:
On Wed, Jun 04, 2025 at 05:08:58AM +0000, Jiaqi Yan wrote:
From: Raghavendra Rao Ananta rananta@google.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@google.com Signed-off-by: Jiaqi Yan jiaqiyan@google.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