All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tao Su <tao1.su@linux.intel.com>
To: Sean Christopherson <seanjc@google.com>
Cc: kvm@vger.kernel.org, pbonzini@redhat.com, xiaoyao.li@intel.com
Subject: Re: [PATCH] KVM: x86: Advertise AMX-COMPLEX CPUID to userspace
Date: Thu, 3 Aug 2023 11:26:21 +0800	[thread overview]
Message-ID: <ZMseXTL80yxUQxa0@linux.bj.intel.com> (raw)
In-Reply-To: <ZMroatylDm1b5+WJ@google.com>

On Wed, Aug 02, 2023 at 04:36:10PM -0700, Sean Christopherson wrote:
> On Wed, Aug 02, 2023, Tao Su wrote:
> > Latest Intel platform GraniteRapids-D introduces AMX-COMPLEX, which adds
> > two instructions to perform matrix multiplication of two tiles containing
> > complex elements and accumulate the results into a packed single precision
> > tile.
> > 
> > AMX-COMPLEX is enumerated via CPUID.(EAX=7,ECX=1):EDX[bit 8]
> > 
> > Since there are no new VMX controls or additional host enabling required
> > for guests to use this feature, advertise the CPUID to userspace.
> 
> Nit, I would rather justify this (last paragraph) with something like:
> 
>   Advertise AMX_COMPLEX if it's supported in hardware.  There are no VMX
>   controls for the feature, i.e. the instructions can't be interecepted, and
>   KVM advertises base AMX in CPUID if AMX is supported in hardware, even if
>   KVM doesn't advertise AMX as being supported in XCR0, e.g. because the
>   process didn't opt-in to allocating tile data.
> 
> If the above is accurate and there are no objections, I'll fixup the changelog
> when applying.

Totally agree.

> 
> Side topic, this does make me wonder if advertising AMX when XTILE_DATA isn't
> permitted is a bad idea.  But no one has complained, and chasing down all the
> dependent AMX features would get annoying, so I'm inclined to keep the status quo.

From the description of AMX exception, there is no CPUID checking and #UD will be produced
if XCR0[18:17] != 0b11. Since user applications should check both the XCR0 and CPUIDs
before using related AMX instructions, I don't think there should be bad effects in keeping
the status quo.

Thanks,
Tao

  parent reply	other threads:[~2023-08-03  3:29 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-02  2:29 [PATCH] KVM: x86: Advertise AMX-COMPLEX CPUID to userspace Tao Su
2023-08-02  7:40 ` Xiaoyao Li
2023-08-02 23:36 ` Sean Christopherson
2023-08-03  3:12   ` Xiaoyao Li
2023-08-03  3:26   ` Tao Su [this message]
2023-08-03 21:04   ` Paolo Bonzini
2023-08-04  0:40 ` Sean Christopherson
2023-08-04  6:58   ` Tao Su

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=ZMseXTL80yxUQxa0@linux.bj.intel.com \
    --to=tao1.su@linux.intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=xiaoyao.li@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.