From: Eduardo Habkost <ehabkost@redhat.com>
To: "Moger, Babu" <Babu.Moger@amd.com>
Cc: "geoff@hostfission.com" <geoff@hostfission.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"mst@redhat.com" <mst@redhat.com>,
"kash@tripleback.net" <kash@tripleback.net>,
"mtosatti@redhat.com" <mtosatti@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"marcel@redhat.com" <marcel@redhat.com>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"rth@twiddle.net" <rth@twiddle.net>
Subject: Re: [PATCH v7 5/9] i386: Use the statically loaded cache definitions
Date: Tue, 8 May 2018 11:12:01 -0300 [thread overview]
Message-ID: <20180508141201.GI25013@localhost.localdomain> (raw)
In-Reply-To: <BL0PR12MB2468EFDC6A05DB20E253E965959B0@BL0PR12MB2468.namprd12.prod.outlook.com>
On Mon, May 07, 2018 at 11:39:45PM +0000, Moger, Babu wrote:
>
>
> > -----Original Message-----
> > From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> > Sent: Monday, May 7, 2018 2:38 PM
> > To: Moger, Babu <Babu.Moger@amd.com>
> > Cc: mst@redhat.com; marcel@redhat.com; pbonzini@redhat.com;
> > rth@twiddle.net; mtosatti@redhat.com; geoff@hostfission.com;
> > kash@tripleback.net; qemu-devel@nongnu.org; kvm@vger.kernel.org
> > Subject: Re: [Qemu-devel] [PATCH v7 5/9] i386: Use the statically loaded
> > cache definitions
> >
> > On Thu, Apr 26, 2018 at 11:26:45AM -0500, Babu Moger wrote:
> > > Use the statically loaded cache definitions if available
> > > and legacy-cache parameter is not set.
> > >
> > > Signed-off-by: Babu Moger <babu.moger@amd.com>
> > > Tested-by: Geoffrey McRae <geoff@hostfission.com>
> >
> > Now that I'm looking at the rest of the code, this seems
> > incomplete:
> >
> > What about CPUID[2], CPUID[4]? They are still referring to the
> > old legacy cache structs.
>
> There is no change in CPUID[2], CPUID[4] behavior. It is intel specific. It did not change. So, we don't need to change that.
> In case it changes in future, we can add it later. AMD does not use CPUID[2] and CPUID[4].
Right, now I see that CPUID 2h-4h are reserved on AMD.
However, X86CPUDefinition::cache_info is not documented as
AMD-specific, so developers changing the code CPU model table in
the future would expect it to affect all cache CPUID leaves.
We could document it as AMD-specific, but it's simpler to just
make it affect all CPUID leaves.
>
> >
> > If their corresponding code isn't updated to use env->cache_info,
> > those leaves will be inconsistent with CPUID[0x8000005] and
> > CPUID[0x80000006].
> >
> > > ---
> > > target/i386/cpu.c | 22 +++++++++++++++++-----
> > > 1 file changed, 17 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> > > index a27b658..56d2f0b 100644
> > > --- a/target/i386/cpu.c
> > > +++ b/target/i386/cpu.c
> > > @@ -3941,8 +3941,13 @@ void cpu_x86_cpuid(CPUX86State *env,
> > uint32_t index, uint32_t count,
> > > (L1_ITLB_2M_ASSOC << 8) | (L1_ITLB_2M_ENTRIES);
> > > *ebx = (L1_DTLB_4K_ASSOC << 24) | (L1_DTLB_4K_ENTRIES << 16) | \
> > > (L1_ITLB_4K_ASSOC << 8) | (L1_ITLB_4K_ENTRIES);
> > > - *ecx = encode_cache_cpuid80000005(&l1d_cache_amd);
> > > - *edx = encode_cache_cpuid80000005(&l1i_cache_amd);
> > > + if (env->cache_info.valid && !cpu->legacy_cache) {
> > > + *ecx = encode_cache_cpuid80000005(&env-
> > >cache_info.l1d_cache);
> > > + *edx = encode_cache_cpuid80000005(&env-
> > >cache_info.l1i_cache);
> > > + } else {
> > > + *ecx = encode_cache_cpuid80000005(&l1d_cache_amd);
> > > + *edx = encode_cache_cpuid80000005(&l1i_cache_amd);
> > > + }
> > > break;
> > > case 0x80000006:
> > > /* cache info (L2 cache) */
> > > @@ -3958,9 +3963,16 @@ void cpu_x86_cpuid(CPUX86State *env,
> > uint32_t index, uint32_t count,
> > > (L2_DTLB_4K_ENTRIES << 16) | \
> > > (AMD_ENC_ASSOC(L2_ITLB_4K_ASSOC) << 12) | \
> > > (L2_ITLB_4K_ENTRIES);
> > > - encode_cache_cpuid80000006(&l2_cache_amd,
> > > - cpu->enable_l3_cache ? &l3_cache : NULL,
> > > - ecx, edx);
> > > + if (env->cache_info.valid && !cpu->legacy_cache) {
> > > + encode_cache_cpuid80000006(&env->cache_info.l2_cache,
> > > + cpu->enable_l3_cache ?
> > > + &env->cache_info.l3_cache : NULL,
> > > + ecx, edx);
> > > + } else {
> > > + encode_cache_cpuid80000006(&l2_cache_amd,
> > > + cpu->enable_l3_cache ? &l3_cache : NULL,
> > > + ecx, edx);
> > > + }
> > > break;
> > > case 0x80000007:
> > > *eax = 0;
> > > --
> > > 2.7.4
> > >
> > >
> >
> > --
> > Eduardo
--
Eduardo
WARNING: multiple messages have this Message-ID (diff)
From: Eduardo Habkost <ehabkost@redhat.com>
To: "Moger, Babu" <Babu.Moger@amd.com>
Cc: "mst@redhat.com" <mst@redhat.com>,
"marcel@redhat.com" <marcel@redhat.com>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"rth@twiddle.net" <rth@twiddle.net>,
"mtosatti@redhat.com" <mtosatti@redhat.com>,
"geoff@hostfission.com" <geoff@hostfission.com>,
"kash@tripleback.net" <kash@tripleback.net>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: [Qemu-devel] [PATCH v7 5/9] i386: Use the statically loaded cache definitions
Date: Tue, 8 May 2018 11:12:01 -0300 [thread overview]
Message-ID: <20180508141201.GI25013@localhost.localdomain> (raw)
In-Reply-To: <BL0PR12MB2468EFDC6A05DB20E253E965959B0@BL0PR12MB2468.namprd12.prod.outlook.com>
On Mon, May 07, 2018 at 11:39:45PM +0000, Moger, Babu wrote:
>
>
> > -----Original Message-----
> > From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> > Sent: Monday, May 7, 2018 2:38 PM
> > To: Moger, Babu <Babu.Moger@amd.com>
> > Cc: mst@redhat.com; marcel@redhat.com; pbonzini@redhat.com;
> > rth@twiddle.net; mtosatti@redhat.com; geoff@hostfission.com;
> > kash@tripleback.net; qemu-devel@nongnu.org; kvm@vger.kernel.org
> > Subject: Re: [Qemu-devel] [PATCH v7 5/9] i386: Use the statically loaded
> > cache definitions
> >
> > On Thu, Apr 26, 2018 at 11:26:45AM -0500, Babu Moger wrote:
> > > Use the statically loaded cache definitions if available
> > > and legacy-cache parameter is not set.
> > >
> > > Signed-off-by: Babu Moger <babu.moger@amd.com>
> > > Tested-by: Geoffrey McRae <geoff@hostfission.com>
> >
> > Now that I'm looking at the rest of the code, this seems
> > incomplete:
> >
> > What about CPUID[2], CPUID[4]? They are still referring to the
> > old legacy cache structs.
>
> There is no change in CPUID[2], CPUID[4] behavior. It is intel specific. It did not change. So, we don't need to change that.
> In case it changes in future, we can add it later. AMD does not use CPUID[2] and CPUID[4].
Right, now I see that CPUID 2h-4h are reserved on AMD.
However, X86CPUDefinition::cache_info is not documented as
AMD-specific, so developers changing the code CPU model table in
the future would expect it to affect all cache CPUID leaves.
We could document it as AMD-specific, but it's simpler to just
make it affect all CPUID leaves.
>
> >
> > If their corresponding code isn't updated to use env->cache_info,
> > those leaves will be inconsistent with CPUID[0x8000005] and
> > CPUID[0x80000006].
> >
> > > ---
> > > target/i386/cpu.c | 22 +++++++++++++++++-----
> > > 1 file changed, 17 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> > > index a27b658..56d2f0b 100644
> > > --- a/target/i386/cpu.c
> > > +++ b/target/i386/cpu.c
> > > @@ -3941,8 +3941,13 @@ void cpu_x86_cpuid(CPUX86State *env,
> > uint32_t index, uint32_t count,
> > > (L1_ITLB_2M_ASSOC << 8) | (L1_ITLB_2M_ENTRIES);
> > > *ebx = (L1_DTLB_4K_ASSOC << 24) | (L1_DTLB_4K_ENTRIES << 16) | \
> > > (L1_ITLB_4K_ASSOC << 8) | (L1_ITLB_4K_ENTRIES);
> > > - *ecx = encode_cache_cpuid80000005(&l1d_cache_amd);
> > > - *edx = encode_cache_cpuid80000005(&l1i_cache_amd);
> > > + if (env->cache_info.valid && !cpu->legacy_cache) {
> > > + *ecx = encode_cache_cpuid80000005(&env-
> > >cache_info.l1d_cache);
> > > + *edx = encode_cache_cpuid80000005(&env-
> > >cache_info.l1i_cache);
> > > + } else {
> > > + *ecx = encode_cache_cpuid80000005(&l1d_cache_amd);
> > > + *edx = encode_cache_cpuid80000005(&l1i_cache_amd);
> > > + }
> > > break;
> > > case 0x80000006:
> > > /* cache info (L2 cache) */
> > > @@ -3958,9 +3963,16 @@ void cpu_x86_cpuid(CPUX86State *env,
> > uint32_t index, uint32_t count,
> > > (L2_DTLB_4K_ENTRIES << 16) | \
> > > (AMD_ENC_ASSOC(L2_ITLB_4K_ASSOC) << 12) | \
> > > (L2_ITLB_4K_ENTRIES);
> > > - encode_cache_cpuid80000006(&l2_cache_amd,
> > > - cpu->enable_l3_cache ? &l3_cache : NULL,
> > > - ecx, edx);
> > > + if (env->cache_info.valid && !cpu->legacy_cache) {
> > > + encode_cache_cpuid80000006(&env->cache_info.l2_cache,
> > > + cpu->enable_l3_cache ?
> > > + &env->cache_info.l3_cache : NULL,
> > > + ecx, edx);
> > > + } else {
> > > + encode_cache_cpuid80000006(&l2_cache_amd,
> > > + cpu->enable_l3_cache ? &l3_cache : NULL,
> > > + ecx, edx);
> > > + }
> > > break;
> > > case 0x80000007:
> > > *eax = 0;
> > > --
> > > 2.7.4
> > >
> > >
> >
> > --
> > Eduardo
--
Eduardo
next prev parent reply other threads:[~2018-05-08 14:12 UTC|newest]
Thread overview: 88+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-26 16:26 [PATCH v7 0/9] i386: Enable TOPOEXT to support hyperthreading on AMD CPU Babu Moger
2018-04-26 16:26 ` [Qemu-devel] " Babu Moger
2018-04-26 16:26 ` [PATCH v7 1/9] i386: Helpers to encode cache information consistently Babu Moger
2018-04-26 16:26 ` [Qemu-devel] " Babu Moger
2018-05-07 19:05 ` Eduardo Habkost
2018-05-07 19:05 ` [Qemu-devel] " Eduardo Habkost
2018-05-07 21:14 ` Moger, Babu
2018-05-07 21:14 ` [Qemu-devel] " Moger, Babu
2018-05-07 21:27 ` Eduardo Habkost
2018-05-07 21:27 ` [Qemu-devel] " Eduardo Habkost
2018-05-07 22:47 ` Moger, Babu
2018-05-07 22:47 ` [Qemu-devel] " Moger, Babu
2018-05-08 18:40 ` Moger, Babu
2018-05-08 18:40 ` [Qemu-devel] " Moger, Babu
2018-05-08 19:07 ` Eduardo Habkost
2018-05-08 19:07 ` [Qemu-devel] " Eduardo Habkost
2018-05-08 19:34 ` Moger, Babu
2018-05-08 19:34 ` [Qemu-devel] " Moger, Babu
2018-04-26 16:26 ` [PATCH v7 2/9] i386: Add cache information in X86CPUDefinition Babu Moger
2018-04-26 16:26 ` [Qemu-devel] " Babu Moger
2018-05-07 19:09 ` Eduardo Habkost
2018-05-07 19:09 ` [Qemu-devel] " Eduardo Habkost
2018-05-07 22:56 ` Moger, Babu
2018-05-07 22:56 ` [Qemu-devel] " Moger, Babu
2018-04-26 16:26 ` [PATCH v7 3/9] i386: Initialize cache information for EPYC family processors Babu Moger
2018-04-26 16:26 ` [Qemu-devel] " Babu Moger
2018-05-07 20:22 ` Eduardo Habkost
2018-05-07 20:22 ` [Qemu-devel] " Eduardo Habkost
2018-04-26 16:26 ` [PATCH v7 4/9] i386: Add new property to control cache info Babu Moger
2018-04-26 16:26 ` [Qemu-devel] " Babu Moger
2018-05-07 19:14 ` Eduardo Habkost
2018-05-07 19:14 ` [Qemu-devel] " Eduardo Habkost
2018-05-07 23:29 ` Moger, Babu
2018-05-07 23:29 ` [Qemu-devel] " Moger, Babu
2018-05-08 14:25 ` Eduardo Habkost
2018-05-08 14:25 ` [Qemu-devel] " Eduardo Habkost
2018-05-08 17:26 ` Moger, Babu
2018-05-08 17:26 ` [Qemu-devel] " Moger, Babu
2018-05-08 18:33 ` Eduardo Habkost
2018-05-08 18:33 ` [Qemu-devel] " Eduardo Habkost
2018-05-08 18:44 ` Moger, Babu
2018-05-08 18:44 ` [Qemu-devel] " Moger, Babu
2018-04-26 16:26 ` [PATCH v7 5/9] i386: Use the statically loaded cache definitions Babu Moger
2018-04-26 16:26 ` [Qemu-devel] " Babu Moger
2018-05-07 19:15 ` Eduardo Habkost
2018-05-07 19:15 ` [Qemu-devel] " Eduardo Habkost
2018-05-07 23:32 ` Moger, Babu
2018-05-07 23:32 ` [Qemu-devel] " Moger, Babu
2018-05-07 19:37 ` Eduardo Habkost
2018-05-07 19:37 ` [Qemu-devel] " Eduardo Habkost
2018-05-07 23:39 ` Moger, Babu
2018-05-07 23:39 ` [Qemu-devel] " Moger, Babu
2018-05-08 14:12 ` Eduardo Habkost [this message]
2018-05-08 14:12 ` Eduardo Habkost
2018-05-08 17:08 ` Moger, Babu
2018-05-08 17:08 ` [Qemu-devel] " Moger, Babu
2018-04-26 16:26 ` [PATCH v7 6/9] i386: Populate AMD Processor Cache Information for cpuid 0x8000001D Babu Moger
2018-04-26 16:26 ` [Qemu-devel] " Babu Moger
2018-05-07 21:06 ` Eduardo Habkost
2018-05-07 21:06 ` [Qemu-devel] " Eduardo Habkost
2018-05-08 16:41 ` Moger, Babu
2018-05-08 16:41 ` [Qemu-devel] " Moger, Babu
2018-04-26 16:26 ` [PATCH v7 7/9] i386: Add support for CPUID_8000_001E for AMD Babu Moger
2018-04-26 16:26 ` [Qemu-devel] " Babu Moger
2018-05-07 19:39 ` Eduardo Habkost
2018-05-07 19:39 ` [Qemu-devel] " Eduardo Habkost
2018-05-07 23:44 ` Moger, Babu
2018-05-07 23:44 ` [Qemu-devel] " Moger, Babu
2018-05-08 14:16 ` Eduardo Habkost
2018-05-08 14:16 ` [Qemu-devel] " Eduardo Habkost
2018-05-08 15:02 ` Moger, Babu
2018-05-08 15:02 ` [Qemu-devel] " Moger, Babu
2018-05-11 14:12 ` Eduardo Habkost
2018-05-11 14:12 ` [Qemu-devel] " Eduardo Habkost
2018-05-11 14:44 ` Moger, Babu
2018-05-11 14:44 ` [Qemu-devel] " Moger, Babu
2018-05-11 14:59 ` Eduardo Habkost
2018-05-11 14:59 ` [Qemu-devel] " Eduardo Habkost
2018-04-26 16:26 ` [PATCH v7 8/9] i386: Enable TOPOEXT feature on AMD EPYC CPU Babu Moger
2018-04-26 16:26 ` [Qemu-devel] " Babu Moger
2018-05-07 21:07 ` Eduardo Habkost
2018-05-07 21:07 ` [Qemu-devel] " Eduardo Habkost
2018-04-26 16:26 ` [PATCH v7 9/9] i386: Remove generic SMT thread check Babu Moger
2018-04-26 16:26 ` [Qemu-devel] " Babu Moger
2018-05-07 21:14 ` Eduardo Habkost
2018-05-07 21:14 ` [Qemu-devel] " Eduardo Habkost
2018-04-26 20:49 ` [PATCH v7 0/9] i386: Enable TOPOEXT to support hyperthreading on AMD CPU geoff--- via Qemu-devel
2018-04-26 20:49 ` [Qemu-devel] " geoff
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=20180508141201.GI25013@localhost.localdomain \
--to=ehabkost@redhat.com \
--cc=Babu.Moger@amd.com \
--cc=geoff@hostfission.com \
--cc=kash@tripleback.net \
--cc=kvm@vger.kernel.org \
--cc=marcel@redhat.com \
--cc=mst@redhat.com \
--cc=mtosatti@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/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.