On Tue, Nov 02, 2021 at 11:25:10PM -0700, Reiji Watanabe wrote: > Introduce a new capability KVM_CAP_ARM_ID_REG_WRITABLE to indicate > that ID registers are writable by userspace. > > Signed-off-by: Reiji Watanabe <reijiw@xxxxxxxxxx> > --- > Documentation/virt/kvm/api.rst | 8 ++++++++ > arch/arm64/kvm/arm.c | 1 + > include/uapi/linux/kvm.h | 1 + > 3 files changed, 10 insertions(+) > > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst > index a6729c8cf063..f7dfb5127310 100644 > --- a/Documentation/virt/kvm/api.rst > +++ b/Documentation/virt/kvm/api.rst > @@ -7265,3 +7265,11 @@ The argument to KVM_ENABLE_CAP is also a bitmask, and must be a subset > of the result of KVM_CHECK_EXTENSION. KVM will forward to userspace > the hypercalls whose corresponding bit is in the argument, and return > ENOSYS for the others. > + > +8.35 KVM_CAP_ARM_ID_REG_WRITABLE > +-------------------------------- ID registers are technically already writable, KVM just rejects any value other than what it derives from sanitising the host ID registers. I agree that the nuance being added warrants a KVM_CAP, as it informs userspace it can deliberately configure ID registers with a more limited value than what KVM returns. KVM_CAP_ARM_ID_REG_CONFIGURABLE maybe? Naming is hard :) -- Thanks, Oliver
