> From: Paolo Bonzini <pbonzini@xxxxxxxxxx> > Sent: Tuesday, January 25, 2022 4:28 PM > > On 1/25/22 02:54, Tian, Kevin wrote: > >> The extra complication is that > arch_prctl(ARCH_REQ_XCOMP_GUEST_PERM) > >> changes what host userspace can/can't do. It would be easier if we > >> could just say that KVM_GET_SUPPORTED_CPUID returns "the most" that > >> userspace can do, but we already have the contract that userspace can > >> take KVM_GET_SUPPORTED_CPUID and pass it straight to > KVM_SET_CPUID2. > >> > >> Therefore, KVM_GET_SUPPORTED_CPUID must limit its returned values > to > >> what has already been enabled. > >> > >> While reviewing the QEMU part of AMX support (this morning), I also > >> noticed that there is no equivalent for guest permissions of > >> ARCH_GET_XCOMP_SUPP. This needs to know KVM's supported_xcr0, so > it's > >> probably best realized as a new KVM_CHECK_EXTENSION rather than as > an > >> arch_prctl. > >> > > Would that lead to a weird situation where although KVM says no support > > of guest permissions while the user can still request them via prctl()? > > This is already the case for the current implementation of > KVM_GET_SUPPORTED_CPUID. > fair enough.
