Re: [PATCH 2/3] KVM: uapi: Remove KVM_DEV_TYPE_ARM_PV_TIME in kvm_device_type

[Steven Price]

On 17/08/2020 09:43, zhukeqian wrote:
> Hi Marc,
>
> On 2020/8/17 15:39, Marc Zyngier wrote:
> > On 2020-08-17 04:37, Keqian Zhu wrote:
> > > ARM64 PV-time ST is configured by userspace through vCPU attribute,
> > > and KVM_DEV_TYPE_ARM_PV_TIME is unused.
> > >
> > > Signed-off-by: Keqian Zhu <zhukeqian1@xxxxxxxxxx>
> > > ---
> > >   include/uapi/linux/kvm.h       | 2 --
> > >   tools/include/uapi/linux/kvm.h | 2 --
> > >   2 files changed, 4 deletions(-)
> > >
> > > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> > > index 4fdf303..9a6b97e 100644
> > > --- a/include/uapi/linux/kvm.h
> > > +++ b/include/uapi/linux/kvm.h
> > > @@ -1258,8 +1258,6 @@ enum kvm_device_type {
> > >   #define KVM_DEV_TYPE_ARM_VGIC_ITS    KVM_DEV_TYPE_ARM_VGIC_ITS
> > >       KVM_DEV_TYPE_XIVE,
> > >   #define KVM_DEV_TYPE_XIVE        KVM_DEV_TYPE_XIVE
> > > -    KVM_DEV_TYPE_ARM_PV_TIME,
> > > -#define KVM_DEV_TYPE_ARM_PV_TIME    KVM_DEV_TYPE_ARM_PV_TIME
> > >       KVM_DEV_TYPE_MAX,
> > >   };
> > >
> > > diff --git a/tools/include/uapi/linux/kvm.h b/tools/include/uapi/linux/kvm.h
> > > index 4fdf303..9a6b97e 100644
> > > --- a/tools/include/uapi/linux/kvm.h
> > > +++ b/tools/include/uapi/linux/kvm.h
> > > @@ -1258,8 +1258,6 @@ enum kvm_device_type {
> > >   #define KVM_DEV_TYPE_ARM_VGIC_ITS    KVM_DEV_TYPE_ARM_VGIC_ITS
> > >       KVM_DEV_TYPE_XIVE,
> > >   #define KVM_DEV_TYPE_XIVE        KVM_DEV_TYPE_XIVE
> > > -    KVM_DEV_TYPE_ARM_PV_TIME,
> > > -#define KVM_DEV_TYPE_ARM_PV_TIME    KVM_DEV_TYPE_ARM_PV_TIME
> > >       KVM_DEV_TYPE_MAX,
> > >   };
> >
> > No. You can't drop anything from UAPI, used or not. Doing so will
> > break the compilation of any userspace that, for any reason, references
> > this value. We cannot reuse this value in the future either, as it would
> > create a we wouldn't know which device to create.
> >
> > It is pretty unfortunate that PV time has turned into such a train wreck,
> > but that's what we have now, and it has to stay.
> Well, I see. It is a sad thing indeed.

Sorry about that, this got refactored so many times I guess I lost track 
of what was actually needed and this hunk remained when it should have 
been removed.

I would hope that I'm the only one who has any userspace code which uses 
this, but I guess we should still be cautious since this has been in 
several releases now.

Steve