| Message ID | 20220616212210.3182-3-chang.seok.bae@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Documentation/x86: Update the dynamic XSTATE doc | expand |
On 6/16/22 14:22, Chang S. Bae wrote: > +In addition, a couple of extended options are provided for a VCPU thread. > +The VCPU XSTATE permission is separately controlled. > + > +-ARCH_GET_XCOMP_GUEST_PERM > + > + arch_prctl(ARCH_GET_XCOMP_GUEST_PERM, &features); > + > + ARCH_GET_XCOMP_GUEST_PERM is a variant of ARCH_GET_XCOMP_PERM. So it > + provides the same semantics and functionality but for VCPU. This touches on the "what", but not the "why". Could you explain in here both why this is needed and why an app might want to use it?
On 6/16/2022 3:49 PM, Dave Hansen wrote: > On 6/16/22 14:22, Chang S. Bae wrote: >> +In addition, a couple of extended options are provided for a VCPU thread. >> +The VCPU XSTATE permission is separately controlled. >> + >> +-ARCH_GET_XCOMP_GUEST_PERM >> + >> + arch_prctl(ARCH_GET_XCOMP_GUEST_PERM, &features); >> + >> + ARCH_GET_XCOMP_GUEST_PERM is a variant of ARCH_GET_XCOMP_PERM. So it >> + provides the same semantics and functionality but for VCPU. > > This touches on the "what", but not the "why". Could you explain in > here both why this is needed and why an app might want to use it? [ while studying on this a bit further, found a few things here ] They (ARCH_{REQ|GET}_XCOMP_GUEST_PERM) provide a userspace VMM to request & check guest permission. In general, KVM looks to have an API as a set of ioctls [1]. A guest VMM uses KVM_GET_DEVICE_ATTR::KVM_X86_XCOMP_GUEST_SUPP to query the available features [2][3]. ARCH_GET_XCOMP_SUPP is not usable here because KVM wants to control those exposed features [4] (via KVM_SUPPORTED_XCR0). But oddly this mask does not appear to be actively referenced by those two arch_prctl options. I can see this ioctl attribute is currently disconnected from these arch_prctl options. Also I failed to find the documentation about this KVM_X86_XCOMP_GUEST_SUPP interface: $ git grep KVM_X86_XCOMP_GUEST_SUPP ./Documentation/ $ I guess people will be confused with having these two options only. I think documenting this has to come along with these missing pieces (and potential fix). So I'm inclined to drop this one at the moment. Thanks, Chang [1] https://kernel.org/doc/html/latest/virt/kvm/index.html [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/kvm/lib/x86_64/processor.c#n641 [3] https://github.com/qemu/qemu/blob/58b53669e87fed0d70903e05cd42079fbbdbc195/target/i386/kvm/kvm.c#L428 [4] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/kvm/x86.c#n9008
On 6/23/2022 4:55 PM, Chang S. Bae wrote: > On 6/16/2022 3:49 PM, Dave Hansen wrote: >> >> This touches on the "what", but not the "why". Could you explain in >> here both why this is needed and why an app might want to use it? > > [ while studying on this a bit further, found a few things here ] > > They (ARCH_{REQ|GET}_XCOMP_GUEST_PERM) provide a userspace VMM to > request & check guest permission. > > In general, KVM looks to have an API as a set of ioctls [1]. A guest VMM > uses KVM_GET_DEVICE_ATTR::KVM_X86_XCOMP_GUEST_SUPP to query the > available features [2][3]. ARCH_GET_XCOMP_SUPP is not usable here > because KVM wants to control those exposed features [4] (via > KVM_SUPPORTED_XCR0). > > But oddly this mask does not appear to be actively referenced by those > two arch_prctl options. I can see this ioctl attribute is currently > disconnected from these arch_prctl options. > > Also I failed to find the documentation about this > KVM_X86_XCOMP_GUEST_SUPP interface: > > $ git grep KVM_X86_XCOMP_GUEST_SUPP ./Documentation/ > $ > > I guess people will be confused with having these two options only. I > think documenting this has to come along with these missing pieces (and > potential fix). So I'm inclined to drop this one at the moment. Posted this series as following up this: https://lore.kernel.org/lkml/20220823231402.7839-1-chang.seok.bae@intel.com/ Thanks, Chang
diff --git a/Documentation/x86/xstate.rst b/Documentation/x86/xstate.rst index 9597e6caa30e..55cbce580853 100644 --- a/Documentation/x86/xstate.rst +++ b/Documentation/x86/xstate.rst @@ -64,6 +64,27 @@ the handler allocates a larger xstate buffer for the task so the large state can be context switched. In the unlikely cases that the allocation fails, the kernel sends SIGSEGV. +In addition, a couple of extended options are provided for a VCPU thread. +The VCPU XSTATE permission is separately controlled. + +-ARCH_GET_XCOMP_GUEST_PERM + + arch_prctl(ARCH_GET_XCOMP_GUEST_PERM, &features); + + ARCH_GET_XCOMP_GUEST_PERM is a variant of ARCH_GET_XCOMP_PERM. So it + provides the same semantics and functionality but for VCPU. + +-ARCH_REQ_XCOMP_GUEST_PERM + + arch_prctl(ARCH_REQ_XCOMP_GUEST_PERM, feature_nr); + + ARCH_REQ_XCOMP_GUEST_PERM is a variant of ARCH_REQ_XCOMP_PERM. Like the + above, it has the same semantics for VCPU permission. It performs a + similar functionality but with a constraint. Permission is frozen when the + first VCPU is created. So any attempt to change permission after that + point is rejected. Thus, permission has to be requested before the first + VCPU creation. + AMX TILE_DATA enabling example ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Commit 980fe2fddcff ("x86/fpu: Extend fpu_xstate_prctl() with guest permissions") extends a couple of arch_prctl(2) options for VCPU threads. Add description for them. Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Yang Zhong <yang.zhong@intel.com> Cc: kvm@vger.kernel.org Cc: linux-doc@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- Documentation/x86/xstate.rst | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+)