On Mon, Jun 29, 2020 at 11:32:08AM +0100, Mark Rutland wrote:
> On Mon, Jun 29, 2020 at 07:18:40PM +1000, Gavin Shan wrote:
> > kvm/arm32 isn't supported since commit 541ad0150ca4 ("arm: Remove
> > 32bit KVM host support"). So HSR isn't meaningful since then. This
> > renames HSR to ESR accordingly. This shouldn't cause any functional
> > changes:
> >
> > * Rename kvm_vcpu_get_hsr() to kvm_vcpu_get_esr() to make the
> > function names self-explanatory.
> > * Rename variables from @hsr to @esr to make them self-explanatory.
> >
> > Signed-off-by: Gavin Shan <gs...@redhat.com>
>
> At a high-level, I agree that we should move to the `esr` naming to
> match the architecture and minimize surprise. However, I think there are
> some ABI changes here, which *are* funcitonal changes, and those need to
> be avoided.
>
> [...]
>
> > diff --git a/arch/arm64/include/uapi/asm/kvm.h
> > b/arch/arm64/include/uapi/asm/kvm.h
> > index ba85bb23f060..d54345573a88 100644
> > --- a/arch/arm64/include/uapi/asm/kvm.h
> > +++ b/arch/arm64/include/uapi/asm/kvm.h
> > @@ -140,7 +140,7 @@ struct kvm_guest_debug_arch {
> > };
> >
> > struct kvm_debug_exit_arch {
> > - __u32 hsr;
> > + __u32 esr;
> > __u64 far; /* used for watchpoints */
> > };
>
> This is userspace ABI, and changing this *will* break userspace. This
> *is* a functional change.
To be slightly clearer: while the structure isn't changed, any userspace
software consuming this header will fail to build after this change,
beacause there will no longer be a field called `hsr`.
Existing binaries will almost certianly not care, but regardless this is
a regression (when building userspce) that I don't think we can permit.
Thanks,
Mark.
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
