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@xxxxxxxxx/
[2] https://lore.kernel.org/lkml/878rz7fyhe.ffs@tglx/
