[RFC PATCH v3 00/29] KVM: arm64: Make CPU ID registers writable by userspace
Reiji Watanabe
reijiw at google.com
Wed Nov 24 08:44:36 PST 2021
Hi Alex,
> > > The API documentation for KVM_ARM_VCPU_INIT states:
> > >
> > > "Userspace can call this function multiple times for a given vcpu,
> > > including after the vcpu has been run. This will reset the vcpu to its
> > > initial state. All calls to this function after the initial call must use
> > > the same target and same set of feature flags, otherwise EINVAL will be
> > > returned."
> > >
> > > The consequences of that, according to my understanding:
> > >
> > > 1. Any changes to the VCPU features made by KVM are observable by
> > > userspace.
> > >
> > > 2. The features in KVM weren't designed and implemented to be disabled
> > > after being enabled.
> > >
> > > With that in mind, I have two questions:
> > >
> > > 1. What happens when userspace disables a feature via the ID registers
> > > which is set in vcpu->arch.features? Does the feature bit get cleared from
> > > vcpu->arch.features? Does it stay set? If it gets cleared, is it now
> > > possible for userspace to call KVM_ARM_VCPU_INIT again with a different set
> > > of VCPU features (it doesn't look possible to me after looking at the
> > > code). If it stays set, what does it mean when userspace calls
> > > KVM_ARM_VCPU_INIT with a different set of features enabled than what is
> > > present in the ID registers? Should the ID registers be changed to match
> > > the features that userspace set in the last KVM_ARM_VCPU_INIT call (it
> > > looks to me that the ID registers are not changed)?
> >
> > KVM will not allow userspace to set the ID register value that conflicts
> > with CPU features that are configured by the initial KVM_ARM_VCPU_INIT
> > (or there are a few more APIs).
> > KVM_SET_ONE_REG for such requests will fail.
> >
> >
> > > 2. What happens to vcpu->arch.features when userspace enables a feature via
> > > the ID registers which is not present in the bitmap?
> >
> > The answer for this question is basically the same as above.
> > Userspace is not allowed to enable a feature via the ID registers
> > which is not present in the bit map.
> >
> > The cover lever included a brief explanation of this, but I will
> > try to improve the explanation:-)
>
> So the ID registers are used to set the version of a feature which is present in
> the VCPU features bitmap, not to enable or a disable a VCPU feature. Thank you
> for the explanation!
Yes, that is correct for the CPU features that can be enabled by
KVM_ARM_VCPU_INIT (or KVM_ENABLE_CAP).
For the other CPU features that are indicated in ID registers on
the host, userspace can disable (hide) the features (or lower the
level of features) for the guest by updating its ID registers.
Thanks,
Reiji
More information about the linux-arm-kernel
mailing list