From: Alexandr Iarygin <alexandr.iarygin@profitbricks.com>
To: Babu Moger <babu.moger@amd.com>,
mst@redhat.com, marcel@redhat.com, pbonzini@redhat.com,
rth@twiddle.net, ehabkost@redhat.com, mtosatti@redhat.com
Cc: kash@tripleback.net,
Alexandr Iarygin <alexandr.iarygin@profitbricks.com>,
qemu-devel@nongnu.org, kvm@vger.kernel.org
Subject: Re: [PATCH v5 4/9] i386: Add new property to control cache info
Date: Mon, 09 Apr 2018 18:59:58 +0200 [thread overview]
Message-ID: <867epg48oh.fsf@profitbricks.com> (raw)
In-Reply-To: <1522186271-27743-5-git-send-email-babu.moger@amd.com>
Hello,
Babu Moger <babu.moger@amd.com> writes:
> This will be used to control the cache information.
> By default new information will be displayed. If user
> passes "-cpu legacy-cache" then older information will
> be displayed even if the hardware supports new information.
>
> Signed-off-by: Babu Moger <babu.moger@amd.com>
> ---
> include/hw/i386/pc.h | 6 +++++-
> target/i386/cpu.c | 1 +
> target/i386/cpu.h | 5 +++++
> 3 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> index ffee841..9cda1ab 100644
> --- a/include/hw/i386/pc.h
> +++ b/include/hw/i386/pc.h
> @@ -327,7 +327,11 @@ bool e820_get_entry(int, uint32_t, uint64_t *, uint64_t *);
> .driver = "q35-pcihost",\
> .property = "x-pci-hole64-fix",\
> .value = "off",\
> - },
> + },{\
> + .driver = TYPE_X86_CPU,\
> + .property = "legacy-cache",\
> + .value = "off",\
> + },\
Should be "on". Also note that this introduces extra '\' at the end.
>
> #define PC_COMPAT_2_9 \
> HW_COMPAT_2_9 \
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 67faa53..f4fbe3a 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -5132,6 +5132,7 @@ static Property x86_cpu_properties[] = {
> false),
> DEFINE_PROP_BOOL("vmware-cpuid-freq", X86CPU, vmware_cpuid_freq, true),
> DEFINE_PROP_BOOL("tcg-cpuid", X86CPU, expose_tcg, true),
> + DEFINE_PROP_BOOL("legacy-cache", X86CPU, legacy_cache, false),
I'm wondering the reason why Intel L1 caches aren't shared per threads,
L2 not shared per threads/cores etc? I mean, changing that will also
require new compat flag with very similar name.
>
> /*
> * From "Requirements for Implementing the Microsoft
> diff --git a/target/i386/cpu.h b/target/i386/cpu.h
> index 806c34b..bbe13f2 100644
> --- a/target/i386/cpu.h
> +++ b/target/i386/cpu.h
> @@ -1394,6 +1394,11 @@ struct X86CPU {
> */
> bool enable_l3_cache;
>
> + /* Compatibility bits for old machine types.
> + * If true present the old cache topology information
> + */
> + bool legacy_cache;
> +
> /* Compatibility bits for old machine types: */
> bool enable_cpuid_0xb;
>
> --
> 1.8.3.1
WARNING: multiple messages have this Message-ID (diff)
From: Alexandr Iarygin <alexandr.iarygin@profitbricks.com>
To: Babu Moger <babu.moger@amd.com>,
mst@redhat.com, marcel@redhat.com, pbonzini@redhat.com,
rth@twiddle.net, ehabkost@redhat.com, mtosatti@redhat.com
Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org, kash@tripleback.net,
Alexandr Iarygin <alexandr.iarygin@profitbricks.com>
Subject: Re: [Qemu-devel] [PATCH v5 4/9] i386: Add new property to control cache info
Date: Mon, 09 Apr 2018 18:59:58 +0200 [thread overview]
Message-ID: <867epg48oh.fsf@profitbricks.com> (raw)
In-Reply-To: <1522186271-27743-5-git-send-email-babu.moger@amd.com>
Hello,
Babu Moger <babu.moger@amd.com> writes:
> This will be used to control the cache information.
> By default new information will be displayed. If user
> passes "-cpu legacy-cache" then older information will
> be displayed even if the hardware supports new information.
>
> Signed-off-by: Babu Moger <babu.moger@amd.com>
> ---
> include/hw/i386/pc.h | 6 +++++-
> target/i386/cpu.c | 1 +
> target/i386/cpu.h | 5 +++++
> 3 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> index ffee841..9cda1ab 100644
> --- a/include/hw/i386/pc.h
> +++ b/include/hw/i386/pc.h
> @@ -327,7 +327,11 @@ bool e820_get_entry(int, uint32_t, uint64_t *, uint64_t *);
> .driver = "q35-pcihost",\
> .property = "x-pci-hole64-fix",\
> .value = "off",\
> - },
> + },{\
> + .driver = TYPE_X86_CPU,\
> + .property = "legacy-cache",\
> + .value = "off",\
> + },\
Should be "on". Also note that this introduces extra '\' at the end.
>
> #define PC_COMPAT_2_9 \
> HW_COMPAT_2_9 \
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 67faa53..f4fbe3a 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -5132,6 +5132,7 @@ static Property x86_cpu_properties[] = {
> false),
> DEFINE_PROP_BOOL("vmware-cpuid-freq", X86CPU, vmware_cpuid_freq, true),
> DEFINE_PROP_BOOL("tcg-cpuid", X86CPU, expose_tcg, true),
> + DEFINE_PROP_BOOL("legacy-cache", X86CPU, legacy_cache, false),
I'm wondering the reason why Intel L1 caches aren't shared per threads,
L2 not shared per threads/cores etc? I mean, changing that will also
require new compat flag with very similar name.
>
> /*
> * From "Requirements for Implementing the Microsoft
> diff --git a/target/i386/cpu.h b/target/i386/cpu.h
> index 806c34b..bbe13f2 100644
> --- a/target/i386/cpu.h
> +++ b/target/i386/cpu.h
> @@ -1394,6 +1394,11 @@ struct X86CPU {
> */
> bool enable_l3_cache;
>
> + /* Compatibility bits for old machine types.
> + * If true present the old cache topology information
> + */
> + bool legacy_cache;
> +
> /* Compatibility bits for old machine types: */
> bool enable_cpuid_0xb;
>
> --
> 1.8.3.1
next prev parent reply other threads:[~2018-04-09 16:59 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-27 21:31 [PATCH v5 0/9] i386: Enable TOPOEXT to support hyperthreading on AMD CPU Babu Moger
2018-03-27 21:31 ` [Qemu-devel] " Babu Moger
2018-03-27 21:31 ` [PATCH v5 1/9] i386: Helpers to encode cache information consistently Babu Moger
2018-03-27 21:31 ` [Qemu-devel] " Babu Moger
2018-03-27 21:31 ` [PATCH v5 2/9] i386: Add cache information in X86CPUDefinition Babu Moger
2018-03-27 21:31 ` [Qemu-devel] " Babu Moger
2018-03-27 21:31 ` [PATCH v5 3/9] i386: Initialize cache information for EPYC family processors Babu Moger
2018-03-27 21:31 ` [Qemu-devel] " Babu Moger
2018-03-27 21:31 ` [PATCH v5 4/9] i386: Add new property to control cache info Babu Moger
2018-03-27 21:31 ` [Qemu-devel] " Babu Moger
2018-04-09 16:59 ` Alexandr Iarygin [this message]
2018-04-09 16:59 ` Alexandr Iarygin
2018-04-09 19:51 ` Moger, Babu
2018-04-09 19:51 ` [Qemu-devel] " Moger, Babu
2018-04-09 20:07 ` Eduardo Habkost
2018-04-09 20:07 ` [Qemu-devel] " Eduardo Habkost
2018-03-27 21:31 ` [PATCH v5 5/9] i386: Use the statically loaded cache definitions Babu Moger
2018-03-27 21:31 ` [Qemu-devel] " Babu Moger
2018-03-27 21:31 ` [PATCH v5 6/9] i386: Populate AMD Processor Cache Information for cpuid 0x8000001D Babu Moger
2018-03-27 21:31 ` [Qemu-devel] " Babu Moger
2018-03-27 21:31 ` [PATCH v5 7/9] i386: Add support for CPUID_8000_001E for AMD Babu Moger
2018-03-27 21:31 ` [Qemu-devel] " Babu Moger
2018-03-27 21:31 ` [PATCH v5 8/9] i386: Enable TOPOEXT feature on AMD EPYC CPU Babu Moger
2018-03-27 21:31 ` [Qemu-devel] " Babu Moger
2018-03-27 21:31 ` [PATCH v5 9/9] i386: Remove generic SMT thread check Babu Moger
2018-03-27 21:31 ` [Qemu-devel] " Babu Moger
2018-04-09 2:58 ` [PATCH v5 0/9] i386: Enable TOPOEXT to support hyperthreading on AMD CPU Moger, Babu
2018-04-09 2:58 ` [Qemu-devel] " Moger, Babu
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=867epg48oh.fsf@profitbricks.com \
--to=alexandr.iarygin@profitbricks.com \
--cc=babu.moger@amd.com \
--cc=ehabkost@redhat.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.