From: Yang Zhong <yang.zhong@intel.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: yang.zhong@intel.com, "Christopherson, ,
Sean" <seanjc@google.com>,
"jing2.liu@linux.intel.com" <jing2.liu@linux.intel.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"Wang, Wei W" <wei.w.wang@intel.com>,
"Zeng, Guang" <guang.zeng@intel.com>,
"pbonzini@redhat.com" <pbonzini@redhat.com>
Subject: Re: [RFC PATCH 3/7] x86: Grant AMX permission for guest
Date: Tue, 11 Jan 2022 14:46:51 +0800 [thread overview]
Message-ID: <20220111064651.GB10991@yangzhon-Virtual> (raw)
In-Reply-To: <BN9PR11MB5276050198EED261C480B6B28C509@BN9PR11MB5276.namprd11.prod.outlook.com>
On Mon, Jan 10, 2022 at 04:36:13PM +0800, Tian, Kevin wrote:
> > From: Zhong, Yang <yang.zhong@intel.com>
> > Sent: Friday, January 7, 2022 5:32 PM
> >
> > Kernel mechanism for dynamically enabled XSAVE features
>
> there is no definition of "dynamically-enabled XSAVE features).
>
Thanks!
> > asks userspace VMM requesting guest permission if it wants
> > to expose the features. Only with the permission, kernel
> > can try to enable the features when detecting the intention
> > from guest in runtime.
> >
> > Qemu should request the permission for guest only once
> > before the first vCPU is created. KVM checks the guest
> > permission when Qemu advertises the features, and the
> > advertising operation fails w/o permission.
>
> what about below?
>
> "Kernel allocates 4K xstate buffer by default. For XSAVE features
> which require large state component (e.g. AMX), Linux kernel
> dynamically expands the xstate buffer only after the process has
> acquired the necessary permissions. Those are called dynamically-
> enabled XSAVE features (or dynamic xfeatures).
>
> There are separate permissions for native tasks and guests.
>
> Qemu should request the guest permissions for dynamic xfeatures
> which will be exposed to the guest. This only needs to be done
> once before the first vcpu is created."
This is clearer. Will update this in new version, thanks!
>
> >
> > Signed-off-by: Yang Zhong <yang.zhong@intel.com>
> > Signed-off-by: Jing Liu <jing2.liu@intel.com>
> > ---
> > target/i386/cpu.h | 7 +++++++
> > hw/i386/x86.c | 28 ++++++++++++++++++++++++++++
> > 2 files changed, 35 insertions(+)
> >
> > diff --git a/target/i386/cpu.h b/target/i386/cpu.h
> > index 768a8218be..79023fe723 100644
> > --- a/target/i386/cpu.h
> > +++ b/target/i386/cpu.h
> > @@ -549,6 +549,13 @@ typedef enum X86Seg {
> > #define XSTATE_ZMM_Hi256_MASK (1ULL << XSTATE_ZMM_Hi256_BIT)
> > #define XSTATE_Hi16_ZMM_MASK (1ULL << XSTATE_Hi16_ZMM_BIT)
> > #define XSTATE_PKRU_MASK (1ULL << XSTATE_PKRU_BIT)
> > +#define XSTATE_XTILE_CFG_MASK (1ULL << XSTATE_XTILE_CFG_BIT)
> > +#define XSTATE_XTILE_DATA_MASK (1ULL << XSTATE_XTILE_DATA_BIT)
> > +#define XFEATURE_XTILE_MASK (XSTATE_XTILE_CFG_MASK \
> > + | XSTATE_XTILE_DATA_MASK)
> > +
> > +#define ARCH_GET_XCOMP_GUEST_PERM 0x1024
> > +#define ARCH_REQ_XCOMP_GUEST_PERM 0x1025
> >
> > /* CPUID feature words */
> > typedef enum FeatureWord {
> > diff --git a/hw/i386/x86.c b/hw/i386/x86.c
> > index b84840a1bb..0a204c375e 100644
> > --- a/hw/i386/x86.c
> > +++ b/hw/i386/x86.c
> > @@ -41,6 +41,8 @@
> > #include "sysemu/cpu-timers.h"
> > #include "trace.h"
> >
> > +#include <sys/syscall.h>
> > +
> > #include "hw/i386/x86.h"
> > #include "target/i386/cpu.h"
> > #include "hw/i386/topology.h"
> > @@ -117,6 +119,30 @@ out:
> > object_unref(cpu);
> > }
> >
> > +static void x86_xsave_req_perm(void)
> > +{
> > + unsigned long bitmask;
> > +
> > + long rc = syscall(SYS_arch_prctl, ARCH_REQ_XCOMP_GUEST_PERM,
> > + XSTATE_XTILE_DATA_BIT);
>
> Should we do it based on the cpuid for the first vcpu?
This permission is requested before vcpu init, so put it in
x86_cpus_init(). If the host kernel does not include AMX changes, or
the latest kernel(include AMX) install on previous generation x86
platform, this syscall() will directly return. I ever put this
permission request in the vcpu create function, but it's hard
to find a good location to handle this. As for cpuid, you mean
I need check host cpuid info? to check if this host cpu can support
AMX? thanks!
Yang
>
> > + if (rc) {
> > + /*
> > + * The older kernel version(<5.15) can't support
> > + * ARCH_REQ_XCOMP_GUEST_PERM and directly return.
> > + */
> > + return;
> > + }
> > +
> > + rc = syscall(SYS_arch_prctl, ARCH_GET_XCOMP_GUEST_PERM, &bitmask);
> > + if (rc) {
> > + error_report("prctl(ARCH_GET_XCOMP_GUEST_PERM) error: %ld", rc);
> > + } else if (!(bitmask & XFEATURE_XTILE_MASK)) {
> > + error_report("prctl(ARCH_REQ_XCOMP_GUEST_PERM) failure "
> > + "and bitmask=0x%lx", bitmask);
> > + exit(EXIT_FAILURE);
> > + }
> > +}
> > +
> > void x86_cpus_init(X86MachineState *x86ms, int default_cpu_version)
> > {
> > int i;
> > @@ -124,6 +150,8 @@ void x86_cpus_init(X86MachineState *x86ms, int
> > default_cpu_version)
> > MachineState *ms = MACHINE(x86ms);
> > MachineClass *mc = MACHINE_GET_CLASS(x86ms);
> >
> > + /* Request AMX pemission for guest */
> > + x86_xsave_req_perm();
> > x86_cpu_set_default_version(default_cpu_version);
> >
> > /*
next prev parent reply other threads:[~2022-01-11 7:19 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-07 9:31 [RFC PATCH 0/7] AMX support in Qemu Yang Zhong
2022-01-07 9:31 ` [RFC PATCH 1/7] x86: Fix the 64-byte boundary enumeration for extended state Yang Zhong
2022-01-10 8:20 ` Tian, Kevin
2022-01-11 2:22 ` Yang Zhong
2022-01-18 12:37 ` Paolo Bonzini
2022-01-21 7:14 ` Yang Zhong
2022-01-07 9:31 ` [RFC PATCH 2/7] x86: Add AMX XTILECFG and XTILEDATA components Yang Zhong
2022-01-10 8:23 ` Tian, Kevin
2022-01-11 2:32 ` Yang Zhong
2022-01-18 12:39 ` Paolo Bonzini
2022-01-21 7:15 ` Yang Zhong
2022-01-07 9:31 ` [RFC PATCH 3/7] x86: Grant AMX permission for guest Yang Zhong
2022-01-10 8:36 ` Tian, Kevin
2022-01-11 6:46 ` Yang Zhong [this message]
2022-01-18 12:52 ` Paolo Bonzini
2022-01-18 13:06 ` Paolo Bonzini
2022-01-21 7:21 ` Yang Zhong
2022-01-07 9:31 ` [RFC PATCH 4/7] x86: Add XFD faulting bit for state components Yang Zhong
2022-01-10 8:38 ` Tian, Kevin
2022-01-11 5:32 ` Yang Zhong
2022-01-18 12:52 ` Paolo Bonzini
2022-01-21 7:18 ` Yang Zhong
2022-01-07 9:31 ` [RFC PATCH 5/7] x86: Add AMX CPUIDs enumeration Yang Zhong
2022-01-07 9:31 ` [RFC PATCH 6/7] x86: Use new XSAVE ioctls handling Yang Zhong
2022-01-10 8:40 ` Tian, Kevin
2022-01-10 9:47 ` Zeng Guang
2022-01-11 2:30 ` Tian, Kevin
2022-01-11 4:29 ` Zeng Guang
2022-01-12 2:51 ` Zeng Guang
2022-01-12 4:34 ` Wang, Wei W
2022-01-07 9:31 ` [RFC PATCH 7/7] x86: Support XFD and AMX xsave data migration Yang Zhong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220111064651.GB10991@yangzhon-Virtual \
--to=yang.zhong@intel.com \
--cc=guang.zeng@intel.com \
--cc=jing2.liu@linux.intel.com \
--cc=kevin.tian@intel.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=seanjc@google.com \
--cc=wei.w.wang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).