From: Tao Su <tao1.su@linux.intel.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel@nongnu.org, mtosatti@redhat.com, xiaoyao.li@intel.com,
xuelian.guo@intel.com
Subject: Re: [PATCH 1/6] target/i386: Add AVX512 state when AVX10 is supported
Date: Tue, 29 Oct 2024 17:29:44 +0800 [thread overview]
Message-ID: <ZyCrCEmNbzjWVFHp@linux.bj.intel.com> (raw)
In-Reply-To: <f31b8bd3-07f1-4661-ae11-fc7fd2d6a90d@redhat.com>
On Tue, Oct 29, 2024 at 09:49:39AM +0100, Paolo Bonzini wrote:
> On 10/28/24 10:25, Tao Su wrote:
> > On Mon, Oct 28, 2024 at 09:41:14AM +0100, Paolo Bonzini wrote:
> > > On 10/28/24 03:45, Tao Su wrote:
> > > > AVX10 state enumeration in CPUID leaf D and enabling in XCR0 register
> > > > are identical to AVX512 state regardless of the supported vector lengths.
> > > >
> > > > Given that some E-cores will support AVX10 but not support AVX512, add
> > > > AVX512 state components to guest when AVX10 is enabled.
> > > >
> > > > Tested-by: Xuelian Guo <xuelian.guo@intel.com>
> > > > Signed-off-by: Tao Su <tao1.su@linux.intel.com>
> > > > ---
> > > > target/i386/cpu.c | 14 ++++++++++++++
> > > > target/i386/cpu.h | 2 ++
> > > > 2 files changed, 16 insertions(+)
> > > >
> > > > diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> > > > index 1ff1af032e..d845ff5e4e 100644
> > > > --- a/target/i386/cpu.c
> > > > +++ b/target/i386/cpu.c
> > > > @@ -7177,6 +7177,13 @@ static void x86_cpu_reset_hold(Object *obj, ResetType type)
> > > > }
> > > > if (env->features[esa->feature] & esa->bits) {
> > > > xcr0 |= 1ull << i;
> > > > + continue;
> > > > + }
> > > > + if (i == XSTATE_OPMASK_BIT || i == XSTATE_ZMM_Hi256_BIT ||
> > > > + i == XSTATE_Hi16_ZMM_BIT) {
> > >
> > > Can you confirm that XSTATE_ZMM_Hi256_BIT depends on AVX10 and not
> > > AVX10-512?
> > >
> >
> > Sorry, I should attach AVX10.2 spec [*].
> >
> > In 3.1.3, spec said Intel AVX10 state enumeration in CPUID leaf 0xD and
> > enabling in XCR0 register are identical to Intel AVX-512 regardless of the
> > maximum vector length supported.
> >
> > So XSTATE_ZMM_Hi256_BIT doesn't depend on AVX10-512.
> >
> > [*] https://cdrdv2.intel.com/v1/dl/getContent/828965
>
> Ok, thanks.
>
> Another related issue is that kvm_cpu_xsave_init() is using esa->feature and
> esa->bits, which misses these three features.
Yes, it has issue if AVX512F is not reported but AVX10 is reported, thanks for
pointing out!
>
> I think we need to change the code to not look at esa->feature at all. I'll
> send a v2 of your series.
>
Yes, ExtSaveArea can't set more feature bits, which makes the code a bit ugly.
Looking forward to the better implementation :-)
next prev parent reply other threads:[~2024-10-29 9:35 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-28 2:45 [PATCH 0/6] Add AVX10.1 CPUID support and GraniteRapids-v2 model Tao Su
2024-10-28 2:45 ` [PATCH 1/6] target/i386: Add AVX512 state when AVX10 is supported Tao Su
2024-10-28 8:41 ` Paolo Bonzini
2024-10-28 9:25 ` Tao Su
2024-10-29 8:49 ` Paolo Bonzini
2024-10-29 9:29 ` Tao Su [this message]
2024-10-28 15:12 ` Xiaoyao Li
2024-10-28 2:45 ` [PATCH 2/6] target/i386: add avx10-version property Tao Su
2024-10-28 15:10 ` Xiaoyao Li
2024-10-29 6:14 ` Tao Su
2024-10-28 2:45 ` [PATCH 3/6] target/i386: Add CPUID.24 leaf for AVX10 Tao Su
2024-10-28 15:04 ` Xiaoyao Li
2024-10-29 6:13 ` Tao Su
2024-10-29 8:25 ` Paolo Bonzini
2024-10-29 14:29 ` Tao Su
2024-10-28 2:45 ` [PATCH 4/6] target/i386: Add feature dependencies " Tao Su
2024-10-28 8:45 ` Paolo Bonzini
2024-10-28 10:02 ` Tao Su
2024-10-28 10:45 ` Paolo Bonzini
2024-10-28 12:23 ` Tao Su
2024-10-28 14:48 ` Xiaoyao Li
2024-10-28 14:50 ` Paolo Bonzini
2024-10-28 15:08 ` Xiaoyao Li
2024-10-29 14:47 ` Zhao Liu
2024-10-29 14:36 ` Tao Su
2024-10-28 2:45 ` [PATCH 5/6] target/i386: Add support for AVX10 in CPUID enumeration Tao Su
2024-10-28 2:45 ` [PATCH 6/6] target/i386: Introduce GraniteRapids-v2 model Tao Su
2024-10-29 14:58 ` Zhao Liu
2024-10-30 1:28 ` 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=ZyCrCEmNbzjWVFHp@linux.bj.intel.com \
--to=tao1.su@linux.intel.com \
--cc=mtosatti@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=xiaoyao.li@intel.com \
--cc=xuelian.guo@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.