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.
Paolo
I wonder whether it's cleaner to do it still via prctl() if we really want to
enhance this part. But as you said then it needs a mechanism to know
KVM's supported_xcr0 (and if KVM is not loaded then no guest permission
support at all)...
