Re: [PATCH v2 1/6] KVM: x86: Clear all supported MPX xfeatures if they are not all set

["Chang S. Bae" <chang.seok.bae@intel.com>]

On 1/13/2023 6:43 AM, Aaron Lewis wrote:
> 
> I'd still like to clean up CPUID.(EAX=0DH,ECX=0):EAX.XTILECFG[17] by
> keeping it consistent with CPUID.(EAX=0DH,ECX=0):EAX.XTILEDATA[18] in
> the guest, but it's not clear to me what the best way to do that is.
> The crux of the issue is that xstate_get_guest_group_perm() returns
> partial support for AMX when userspace doesn't call
> prctl(ARCH_REQ_XCOMP_GUEST_PERM), I.e. the guest CPUID will report
> XTILECFG=1 and XTILEDATA=0 in that case.  In that situation, XTILECFG
> should be cleared for it to be consistent.  I can see two ways of
> potentially doing that:
> 
> 1. We can ensure that perm->__state_perm never stores partial support.
> 
> 2. We can sanitize the bits in xstate_get_guest_group_perm() before
> they are returned, to ensure KVM never sees partial support.
> 
> I like the idea of #1, but if that has negative effects on the host or
> XFD I'm open to #2.  Though, XFD has its own field, so I thought that
> wouldn't be an issue.  Would it work to set __state_perm and/or
> default_features (what originally sets __state_perm) to a consistent
> view, so partial support is never returned from
> xstate_get_guest_group_perm()?

FWIW, I was trying to clarify that ARCH_GET_XCOMP_GUEST_PERM is a 
variant of ARCH_GET_XCOMP_PERM in the documentation [1]. So, I guess #1 
will have some side-effect (at least confusion) for this semantics.

There may be some ways to transform the permission bits to the 
XCR0-capable bits. For instance, when considering this permission 
support in host, the highest feature number was considered to denote the 
rest feature bits [2].

Thanks,
Chang

[1] 
https://lore.kernel.org/lkml/20220922195810.23248-5-chang.seok.bae@intel.com/
[2] https://lore.kernel.org/lkml/878rz7fyhe.ffs@tglx/