On Thu, Nov 4, 2021 at 9:41 AM Oliver Upton <oupton@xxxxxxxxxx> wrote: > > 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 :) Thank you for the suggestion. Yes, that sounds better. I will change the name as you suggested. Regards, Reiji _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
