* [PATCH v7 0/9] i386: Enable TOPOEXT to support hyperthreading on AMD CPU
@ 2018-04-26 16:26 ` Babu Moger
0 siblings, 0 replies; 88+ messages in thread
From: Babu Moger @ 2018-04-26 16:26 UTC (permalink / raw)
To: mst, marcel, pbonzini, rth, ehabkost, mtosatti
Cc: geoff, babu.moger, kash, qemu-devel, kvm
This series enables the TOPOEXT feature for AMD CPUs. This is required to
support hyperthreading on kvm guests.
This addresses the issues reported in these bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1481253
https://bugs.launchpad.net/qemu/+bug/1703506
v7:
Rebased on top of latest tree after 2.12 release and done few basic tests. There are
no changes except for few minor hunks. Hopefully this gets pulled into 2.13 release.
Please review, let me know of any feedback.
v6:
1.Fixed problem with patch#4(Add new property to control cache info). The parameter
legacy_cache should be "on" by default on machine type "pc-q35-2.10". This was
found by Alexandr Iarygin.
2.Fixed the l3 cache size for EPYC based machines(patch#3). Also, fixed the number of
logical processors sharing the cache(patch#6). Only L3 cache is shared by multiple
cores but not L1 or L2. This was a bug while decoding. This was found by Geoffrey McRae
and he verified the fix.
v5:
In this series I tried to address the feedback from Eduardo Habkost.
The discussion thread is here.
https://patchwork.kernel.org/patch/10299745/
The previous thread is here.
http://patchwork.ozlabs.org/cover/884885/
Reason for these changes.
The cache properties for AMD family of processors have changed from
previous releases. We don't want to display the new information on the
old family of processors as this might cause compatibility issues.
Changes:
1.Based the patches on top of Eduardo's(patch#1) patch.
Changed few things.
Moved the Cache definitions to cpu.h file.
Changed the CPUID_4 names to generic names.
2.Added a new propery "legacy-cache" in cpu object(patch#2). This can be
used to display the old property even if the host supports the new cache
properties.
3.Added cache information in X86CPUDefinition and CPUX86State
4.Patch 6-7 changed quite a bit from previous version does to new approach.
5.Addressed few issues with CPUID_8000_001d and CPUID_8000_001E.
v4:
1.Removed the checks under cpuid 0x8000001D leaf(patch #2). These check are
not necessary. Found this during internal review.
2.Added CPUID_EXT3_TOPOEXT feature for all the 17 family(patch #4). This was
found by Kash Pande during his testing.
3.Removed th hardcoded cpuid xlevel and dynamically extended if CPUID_EXT3_TOPOEXT
is supported(Suggested by Brijesh Singh).
v3:
1.Removed the patch #1. Radim mentioned that original typo problem is in
linux kernel header. qemu is just copying those files.
2.In previous version, I used the cpuid 4 definitions for AMDs cpuid leaf
0x8000001D. CPUID 4 is very intel specific and we dont want to expose those
details under AMD. I have renamed some of these definitions as generic.
These changes are in patch#1. Radim, let me know if this is what you intended.
3.Added assert to for core_id(Suggested by Radim Krčmář).
4.Changed the if condition under "L3 cache info"(Suggested by Gary Hook).
5.Addressed few more text correction and code cleanup(Suggested by Thomas Lendacky).
v2:
Fixed few more minor issues per Gary Hook's comments. Thank you Gary.
Removed the patch#1. We need to handle the instruction cache associativity
seperately. It varies based on the cpu family. I will comeback to that later.
Added two more typo corrections in patch#1 and patch#5.
v1:
Stanislav Lanci posted few patches earlier.
https://patchwork.kernel.org/patch/10040903/
Rebased his patches with few changes.
1.Spit the patches into two, separating cpuid functions
0x8000001D and 0x8000001E (Patch 2 and 3).
2.Removed the generic non-intel check and made a separate patch
with some changes(Patch 5).
3.Fixed L3_N_SETS_AMD(from 4096 to 8192) based on CPUID_Fn8000001D_ECX_x03.
Added 2 more patches.
Patch 1. Fixes cache associativity.
Patch 4. Adds TOPOEXT feature on AMD EPYC CPU.
Babu Moger (8):
i386: Add cache information in X86CPUDefinition
i386: Initialize cache information for EPYC family processors
i386: Add new property to control cache info
i386: Use the statically loaded cache definitions
i386: Populate AMD Processor Cache Information for cpuid 0x8000001D
i386: Add support for CPUID_8000_001E for AMD
i386: Enable TOPOEXT feature on AMD EPYC CPU
i386: Remove generic SMT thread check
Eduardo Habkost (1):
i386: Helpers to encode cache information consistently
include/hw/i386/pc.h | 4 +
target/i386/cpu.c | 736 ++++++++++++++++++++++++++++++++++++++++++---------
target/i386/cpu.h | 66 +++++
target/i386/kvm.c | 29 +-
4 files changed, 702 insertions(+), 133 deletions(-)
--
2.7.4
^ permalink raw reply [flat|nested] 88+ messages in thread
* [Qemu-devel] [PATCH v7 0/9] i386: Enable TOPOEXT to support hyperthreading on AMD CPU
@ 2018-04-26 16:26 ` Babu Moger
0 siblings, 0 replies; 88+ messages in thread
From: Babu Moger @ 2018-04-26 16:26 UTC (permalink / raw)
To: mst, marcel, pbonzini, rth, ehabkost, mtosatti
Cc: qemu-devel, kvm, kash, geoff, babu.moger
This series enables the TOPOEXT feature for AMD CPUs. This is required to
support hyperthreading on kvm guests.
This addresses the issues reported in these bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1481253
https://bugs.launchpad.net/qemu/+bug/1703506
v7:
Rebased on top of latest tree after 2.12 release and done few basic tests. There are
no changes except for few minor hunks. Hopefully this gets pulled into 2.13 release.
Please review, let me know of any feedback.
v6:
1.Fixed problem with patch#4(Add new property to control cache info). The parameter
legacy_cache should be "on" by default on machine type "pc-q35-2.10". This was
found by Alexandr Iarygin.
2.Fixed the l3 cache size for EPYC based machines(patch#3). Also, fixed the number of
logical processors sharing the cache(patch#6). Only L3 cache is shared by multiple
cores but not L1 or L2. This was a bug while decoding. This was found by Geoffrey McRae
and he verified the fix.
v5:
In this series I tried to address the feedback from Eduardo Habkost.
The discussion thread is here.
https://patchwork.kernel.org/patch/10299745/
The previous thread is here.
http://patchwork.ozlabs.org/cover/884885/
Reason for these changes.
The cache properties for AMD family of processors have changed from
previous releases. We don't want to display the new information on the
old family of processors as this might cause compatibility issues.
Changes:
1.Based the patches on top of Eduardo's(patch#1) patch.
Changed few things.
Moved the Cache definitions to cpu.h file.
Changed the CPUID_4 names to generic names.
2.Added a new propery "legacy-cache" in cpu object(patch#2). This can be
used to display the old property even if the host supports the new cache
properties.
3.Added cache information in X86CPUDefinition and CPUX86State
4.Patch 6-7 changed quite a bit from previous version does to new approach.
5.Addressed few issues with CPUID_8000_001d and CPUID_8000_001E.
v4:
1.Removed the checks under cpuid 0x8000001D leaf(patch #2). These check are
not necessary. Found this during internal review.
2.Added CPUID_EXT3_TOPOEXT feature for all the 17 family(patch #4). This was
found by Kash Pande during his testing.
3.Removed th hardcoded cpuid xlevel and dynamically extended if CPUID_EXT3_TOPOEXT
is supported(Suggested by Brijesh Singh).
v3:
1.Removed the patch #1. Radim mentioned that original typo problem is in
linux kernel header. qemu is just copying those files.
2.In previous version, I used the cpuid 4 definitions for AMDs cpuid leaf
0x8000001D. CPUID 4 is very intel specific and we dont want to expose those
details under AMD. I have renamed some of these definitions as generic.
These changes are in patch#1. Radim, let me know if this is what you intended.
3.Added assert to for core_id(Suggested by Radim Krčmář).
4.Changed the if condition under "L3 cache info"(Suggested by Gary Hook).
5.Addressed few more text correction and code cleanup(Suggested by Thomas Lendacky).
v2:
Fixed few more minor issues per Gary Hook's comments. Thank you Gary.
Removed the patch#1. We need to handle the instruction cache associativity
seperately. It varies based on the cpu family. I will comeback to that later.
Added two more typo corrections in patch#1 and patch#5.
v1:
Stanislav Lanci posted few patches earlier.
https://patchwork.kernel.org/patch/10040903/
Rebased his patches with few changes.
1.Spit the patches into two, separating cpuid functions
0x8000001D and 0x8000001E (Patch 2 and 3).
2.Removed the generic non-intel check and made a separate patch
with some changes(Patch 5).
3.Fixed L3_N_SETS_AMD(from 4096 to 8192) based on CPUID_Fn8000001D_ECX_x03.
Added 2 more patches.
Patch 1. Fixes cache associativity.
Patch 4. Adds TOPOEXT feature on AMD EPYC CPU.
Babu Moger (8):
i386: Add cache information in X86CPUDefinition
i386: Initialize cache information for EPYC family processors
i386: Add new property to control cache info
i386: Use the statically loaded cache definitions
i386: Populate AMD Processor Cache Information for cpuid 0x8000001D
i386: Add support for CPUID_8000_001E for AMD
i386: Enable TOPOEXT feature on AMD EPYC CPU
i386: Remove generic SMT thread check
Eduardo Habkost (1):
i386: Helpers to encode cache information consistently
include/hw/i386/pc.h | 4 +
target/i386/cpu.c | 736 ++++++++++++++++++++++++++++++++++++++++++---------
target/i386/cpu.h | 66 +++++
target/i386/kvm.c | 29 +-
4 files changed, 702 insertions(+), 133 deletions(-)
--
2.7.4
^ permalink raw reply [flat|nested] 88+ messages in thread
* [PATCH v7 1/9] i386: Helpers to encode cache information consistently
2018-04-26 16:26 ` [Qemu-devel] " Babu Moger
@ 2018-04-26 16:26 ` Babu Moger
-1 siblings, 0 replies; 88+ messages in thread
From: Babu Moger @ 2018-04-26 16:26 UTC (permalink / raw)
To: mst, marcel, pbonzini, rth, ehabkost, mtosatti
Cc: geoff, babu.moger, kash, qemu-devel, kvm
From: Eduardo Habkost <ehabkost@redhat.com>
Instead of having a collection of macros that need to be used in
complex expressions to build CPUID data, define a CPUCacheInfo
struct that can hold information about a given cache. Helper
functions will take a CPUCacheInfo struct as input to encode
CPUID leaves for a cache.
This will help us ensure consistency between cache information
CPUID leaves, and make the existing inconsistencies in CPUID info
more visible.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Babu Moger <babu.moger@amd.com>
Tested-by: Geoffrey McRae <geoff@hostfission.com>
---
target/i386/cpu.c | 495 ++++++++++++++++++++++++++++++++++++++++--------------
target/i386/cpu.h | 53 ++++++
2 files changed, 424 insertions(+), 124 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index a20fe26..b6c1592 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -56,33 +56,240 @@
#include "disas/capstone.h"
+/* Helpers for building CPUID[2] descriptors: */
+
+struct CPUID2CacheDescriptorInfo {
+ enum CacheType type;
+ int level;
+ int size;
+ int line_size;
+ int associativity;
+};
-/* Cache topology CPUID constants: */
+#define KiB 1024
+#define MiB (1024 * 1024)
-/* CPUID Leaf 2 Descriptors */
+/*
+ * Known CPUID 2 cache descriptors.
+ * From Intel SDM Volume 2A, CPUID instruction
+ */
+struct CPUID2CacheDescriptorInfo cpuid2_cache_descriptors[] = {
+ [0x06] = { .level = 1, .type = ICACHE, .size = 8 * KiB,
+ .associativity = 4, .line_size = 32, },
+ [0x08] = { .level = 1, .type = ICACHE, .size = 16 * KiB,
+ .associativity = 4, .line_size = 32, },
+ [0x09] = { .level = 1, .type = ICACHE, .size = 32 * KiB,
+ .associativity = 4, .line_size = 64, },
+ [0x0A] = { .level = 1, .type = DCACHE, .size = 8 * KiB,
+ .associativity = 2, .line_size = 32, },
+ [0x0C] = { .level = 1, .type = DCACHE, .size = 16 * KiB,
+ .associativity = 4, .line_size = 32, },
+ [0x0D] = { .level = 1, .type = DCACHE, .size = 16 * KiB,
+ .associativity = 4, .line_size = 64, },
+ [0x0E] = { .level = 1, .type = DCACHE, .size = 24 * KiB,
+ .associativity = 6, .line_size = 64, },
+ [0x1D] = { .level = 2, .type = UNIFIED_CACHE, .size = 128 * KiB,
+ .associativity = 2, .line_size = 64, },
+ [0x21] = { .level = 2, .type = UNIFIED_CACHE, .size = 256 * KiB,
+ .associativity = 8, .line_size = 64, },
+ /* lines per sector is not supported cpuid2_cache_descriptor(),
+ * so descriptors 0x22, 0x23 are not included
+ */
+ [0x24] = { .level = 2, .type = UNIFIED_CACHE, .size = 1 * MiB,
+ .associativity = 16, .line_size = 64, },
+ /* lines per sector is not supported cpuid2_cache_descriptor(),
+ * so descriptors 0x25, 0x20 are not included
+ */
+ [0x2C] = { .level = 1, .type = DCACHE, .size = 32 * KiB,
+ .associativity = 8, .line_size = 64, },
+ [0x30] = { .level = 1, .type = ICACHE, .size = 32 * KiB,
+ .associativity = 8, .line_size = 64, },
+ [0x41] = { .level = 2, .type = UNIFIED_CACHE, .size = 128 * KiB,
+ .associativity = 4, .line_size = 32, },
+ [0x42] = { .level = 2, .type = UNIFIED_CACHE, .size = 256 * KiB,
+ .associativity = 4, .line_size = 32, },
+ [0x43] = { .level = 2, .type = UNIFIED_CACHE, .size = 512 * KiB,
+ .associativity = 4, .line_size = 32, },
+ [0x44] = { .level = 2, .type = UNIFIED_CACHE, .size = 1 * MiB,
+ .associativity = 4, .line_size = 32, },
+ [0x45] = { .level = 2, .type = UNIFIED_CACHE, .size = 2 * MiB,
+ .associativity = 4, .line_size = 32, },
+ [0x46] = { .level = 3, .type = UNIFIED_CACHE, .size = 4 * MiB,
+ .associativity = 4, .line_size = 64, },
+ [0x47] = { .level = 3, .type = UNIFIED_CACHE, .size = 8 * MiB,
+ .associativity = 8, .line_size = 64, },
+ [0x48] = { .level = 2, .type = UNIFIED_CACHE, .size = 3 * MiB,
+ .associativity = 12, .line_size = 64, },
+ /* Descriptor 0x49 depends on CPU family/model, so it is not included */
+ [0x4A] = { .level = 3, .type = UNIFIED_CACHE, .size = 6 * MiB,
+ .associativity = 12, .line_size = 64, },
+ [0x4B] = { .level = 3, .type = UNIFIED_CACHE, .size = 8 * MiB,
+ .associativity = 16, .line_size = 64, },
+ [0x4C] = { .level = 3, .type = UNIFIED_CACHE, .size = 12 * MiB,
+ .associativity = 12, .line_size = 64, },
+ [0x4D] = { .level = 3, .type = UNIFIED_CACHE, .size = 16 * MiB,
+ .associativity = 16, .line_size = 64, },
+ [0x4E] = { .level = 2, .type = UNIFIED_CACHE, .size = 6 * MiB,
+ .associativity = 24, .line_size = 64, },
+ [0x60] = { .level = 1, .type = DCACHE, .size = 16 * KiB,
+ .associativity = 8, .line_size = 64, },
+ [0x66] = { .level = 1, .type = DCACHE, .size = 8 * KiB,
+ .associativity = 4, .line_size = 64, },
+ [0x67] = { .level = 1, .type = DCACHE, .size = 16 * KiB,
+ .associativity = 4, .line_size = 64, },
+ [0x68] = { .level = 1, .type = DCACHE, .size = 32 * KiB,
+ .associativity = 4, .line_size = 64, },
+ [0x78] = { .level = 2, .type = UNIFIED_CACHE, .size = 1 * MiB,
+ .associativity = 4, .line_size = 64, },
+ /* lines per sector is not supported cpuid2_cache_descriptor(),
+ * so descriptors 0x79, 0x7A, 0x7B, 0x7C are not included.
+ */
+ [0x7D] = { .level = 2, .type = UNIFIED_CACHE, .size = 2 * MiB,
+ .associativity = 8, .line_size = 64, },
+ [0x7F] = { .level = 2, .type = UNIFIED_CACHE, .size = 512 * KiB,
+ .associativity = 2, .line_size = 64, },
+ [0x80] = { .level = 2, .type = UNIFIED_CACHE, .size = 512 * KiB,
+ .associativity = 8, .line_size = 64, },
+ [0x82] = { .level = 2, .type = UNIFIED_CACHE, .size = 256 * KiB,
+ .associativity = 8, .line_size = 32, },
+ [0x83] = { .level = 2, .type = UNIFIED_CACHE, .size = 512 * KiB,
+ .associativity = 8, .line_size = 32, },
+ [0x84] = { .level = 2, .type = UNIFIED_CACHE, .size = 1 * MiB,
+ .associativity = 8, .line_size = 32, },
+ [0x85] = { .level = 2, .type = UNIFIED_CACHE, .size = 2 * MiB,
+ .associativity = 8, .line_size = 32, },
+ [0x86] = { .level = 2, .type = UNIFIED_CACHE, .size = 512 * KiB,
+ .associativity = 4, .line_size = 64, },
+ [0x87] = { .level = 2, .type = UNIFIED_CACHE, .size = 1 * MiB,
+ .associativity = 8, .line_size = 64, },
+ [0xD0] = { .level = 3, .type = UNIFIED_CACHE, .size = 512 * KiB,
+ .associativity = 4, .line_size = 64, },
+ [0xD1] = { .level = 3, .type = UNIFIED_CACHE, .size = 1 * MiB,
+ .associativity = 4, .line_size = 64, },
+ [0xD2] = { .level = 3, .type = UNIFIED_CACHE, .size = 2 * MiB,
+ .associativity = 4, .line_size = 64, },
+ [0xD6] = { .level = 3, .type = UNIFIED_CACHE, .size = 1 * MiB,
+ .associativity = 8, .line_size = 64, },
+ [0xD7] = { .level = 3, .type = UNIFIED_CACHE, .size = 2 * MiB,
+ .associativity = 8, .line_size = 64, },
+ [0xD8] = { .level = 3, .type = UNIFIED_CACHE, .size = 4 * MiB,
+ .associativity = 8, .line_size = 64, },
+ [0xDC] = { .level = 3, .type = UNIFIED_CACHE, .size = 1.5 * MiB,
+ .associativity = 12, .line_size = 64, },
+ [0xDD] = { .level = 3, .type = UNIFIED_CACHE, .size = 3 * MiB,
+ .associativity = 12, .line_size = 64, },
+ [0xDE] = { .level = 3, .type = UNIFIED_CACHE, .size = 6 * MiB,
+ .associativity = 12, .line_size = 64, },
+ [0xE2] = { .level = 3, .type = UNIFIED_CACHE, .size = 2 * MiB,
+ .associativity = 16, .line_size = 64, },
+ [0xE3] = { .level = 3, .type = UNIFIED_CACHE, .size = 4 * MiB,
+ .associativity = 16, .line_size = 64, },
+ [0xE4] = { .level = 3, .type = UNIFIED_CACHE, .size = 8 * MiB,
+ .associativity = 16, .line_size = 64, },
+ [0xEA] = { .level = 3, .type = UNIFIED_CACHE, .size = 12 * MiB,
+ .associativity = 24, .line_size = 64, },
+ [0xEB] = { .level = 3, .type = UNIFIED_CACHE, .size = 18 * MiB,
+ .associativity = 24, .line_size = 64, },
+ [0xEC] = { .level = 3, .type = UNIFIED_CACHE, .size = 24 * MiB,
+ .associativity = 24, .line_size = 64, },
+};
+
+/*
+ * "CPUID leaf 2 does not report cache descriptor information,
+ * use CPUID leaf 4 to query cache parameters"
+ */
+#define CACHE_DESCRIPTOR_UNAVAILABLE 0xFF
-#define CPUID_2_L1D_32KB_8WAY_64B 0x2c
-#define CPUID_2_L1I_32KB_8WAY_64B 0x30
-#define CPUID_2_L2_2MB_8WAY_64B 0x7d
-#define CPUID_2_L3_16MB_16WAY_64B 0x4d
+/*
+ * Return a CPUID 2 cache descriptor for a given cache.
+ * If no known descriptor is found, return CACHE_DESCRIPTOR_UNAVAILABLE
+ */
+static uint8_t cpuid2_cache_descriptor(CPUCacheInfo *cache)
+{
+ int i;
+
+ assert(cache->size > 0);
+ assert(cache->level > 0);
+ assert(cache->line_size > 0);
+ assert(cache->associativity > 0);
+ for (i = 0; i < ARRAY_SIZE(cpuid2_cache_descriptors); i++) {
+ struct CPUID2CacheDescriptorInfo *d = &cpuid2_cache_descriptors[i];
+ if (d->level == cache->level && d->type == cache->type &&
+ d->size == cache->size && d->line_size == cache->line_size &&
+ d->associativity == cache->associativity) {
+ return i;
+ }
+ }
+ return CACHE_DESCRIPTOR_UNAVAILABLE;
+}
/* CPUID Leaf 4 constants: */
/* EAX: */
-#define CPUID_4_TYPE_DCACHE 1
-#define CPUID_4_TYPE_ICACHE 2
-#define CPUID_4_TYPE_UNIFIED 3
+#define CACHE_TYPE_D 1
+#define CACHE_TYPE_I 2
+#define CACHE_TYPE_UNIFIED 3
-#define CPUID_4_LEVEL(l) ((l) << 5)
+#define CACHE_LEVEL(l) (l << 5)
-#define CPUID_4_SELF_INIT_LEVEL (1 << 8)
-#define CPUID_4_FULLY_ASSOC (1 << 9)
+#define CACHE_SELF_INIT_LEVEL (1 << 8)
/* EDX: */
-#define CPUID_4_NO_INVD_SHARING (1 << 0)
-#define CPUID_4_INCLUSIVE (1 << 1)
-#define CPUID_4_COMPLEX_IDX (1 << 2)
+#define CACHE_NO_INVD_SHARING (1 << 0)
+#define CACHE_INCLUSIVE (1 << 1)
+#define CACHE_COMPLEX_IDX (1 << 2)
+
+/* Encode CacheType for CPUID[4].EAX */
+#define CACHE_TYPE(t) (((t) == DCACHE) ? CACHE_TYPE_D : \
+ ((t) == ICACHE) ? CACHE_TYPE_I : \
+ ((t) == UNIFIED_CACHE) ? CACHE_TYPE_UNIFIED : \
+ 0 /* Invalid value */)
+
+
+/* Encode cache info for CPUID[4] */
+static void encode_cache_cpuid4(CPUCacheInfo *cache,
+ int num_apic_ids, int num_cores,
+ uint32_t *eax, uint32_t *ebx,
+ uint32_t *ecx, uint32_t *edx)
+{
+ assert(cache->size == cache->line_size * cache->associativity *
+ cache->partitions * cache->sets);
+
+ assert(num_apic_ids > 0);
+ *eax = CACHE_TYPE(cache->type) |
+ CACHE_LEVEL(cache->level) |
+ (cache->self_init ? CACHE_SELF_INIT_LEVEL : 0) |
+ ((num_cores - 1) << 26) |
+ ((num_apic_ids - 1) << 14);
+
+ assert(cache->line_size > 0);
+ assert(cache->partitions > 0);
+ assert(cache->associativity > 0);
+ /* We don't implement fully-associative caches */
+ assert(cache->associativity < cache->sets);
+ *ebx = (cache->line_size - 1) |
+ ((cache->partitions - 1) << 12) |
+ ((cache->associativity - 1) << 22);
+
+ assert(cache->sets > 0);
+ *ecx = cache->sets - 1;
+
+ *edx = (cache->no_invd_sharing ? CACHE_NO_INVD_SHARING : 0) |
+ (cache->inclusive ? CACHE_INCLUSIVE : 0) |
+ (cache->complex_indexing ? CACHE_COMPLEX_IDX : 0);
+}
+
+/* Encode cache info for CPUID[0x80000005].ECX or CPUID[0x80000005].EDX */
+static uint32_t encode_cache_cpuid80000005(CPUCacheInfo *cache)
+{
+ assert(cache->size % 1024 == 0);
+ assert(cache->lines_per_tag > 0);
+ assert(cache->associativity > 0);
+ assert(cache->line_size > 0);
+ return ((cache->size / 1024) << 24) | (cache->associativity << 16) |
+ (cache->lines_per_tag << 8) | (cache->line_size);
+}
#define ASSOC_FULL 0xFF
@@ -100,57 +307,140 @@
a == ASSOC_FULL ? 0xF : \
0 /* invalid value */)
+/*
+ * Encode cache info for CPUID[0x80000006].ECX and CPUID[0x80000006].EDX
+ * @l3 can be NULL.
+ */
+static void encode_cache_cpuid80000006(CPUCacheInfo *l2,
+ CPUCacheInfo *l3,
+ uint32_t *ecx, uint32_t *edx)
+{
+ assert(l2->size % 1024 == 0);
+ assert(l2->associativity > 0);
+ assert(l2->lines_per_tag > 0);
+ assert(l2->line_size > 0);
+ *ecx = ((l2->size / 1024) << 16) |
+ (AMD_ENC_ASSOC(l2->associativity) << 12) |
+ (l2->lines_per_tag << 8) | (l2->line_size);
+
+ if (l3) {
+ assert(l3->size % (512 * 1024) == 0);
+ assert(l3->associativity > 0);
+ assert(l3->lines_per_tag > 0);
+ assert(l3->line_size > 0);
+ *edx = ((l3->size / (512 * 1024)) << 18) |
+ (AMD_ENC_ASSOC(l3->associativity) << 12) |
+ (l3->lines_per_tag << 8) | (l3->line_size);
+ } else {
+ *edx = 0;
+ }
+}
/* Definitions of the hardcoded cache entries we expose: */
/* L1 data cache: */
-#define L1D_LINE_SIZE 64
-#define L1D_ASSOCIATIVITY 8
-#define L1D_SETS 64
-#define L1D_PARTITIONS 1
-/* Size = LINE_SIZE*ASSOCIATIVITY*SETS*PARTITIONS = 32KiB */
-#define L1D_DESCRIPTOR CPUID_2_L1D_32KB_8WAY_64B
+static CPUCacheInfo l1d_cache = {
+ .type = DCACHE,
+ .level = 1,
+ .size = 32 * KiB,
+ .self_init = 1,
+ .line_size = 64,
+ .associativity = 8,
+ .sets = 64,
+ .partitions = 1,
+ .no_invd_sharing = true,
+};
+
/*FIXME: CPUID leaf 0x80000005 is inconsistent with leaves 2 & 4 */
-#define L1D_LINES_PER_TAG 1
-#define L1D_SIZE_KB_AMD 64
-#define L1D_ASSOCIATIVITY_AMD 2
+static CPUCacheInfo l1d_cache_amd = {
+ .type = DCACHE,
+ .level = 1,
+ .size = 64 * KiB,
+ .self_init = 1,
+ .line_size = 64,
+ .associativity = 2,
+ .sets = 512,
+ .partitions = 1,
+ .lines_per_tag = 1,
+ .no_invd_sharing = true,
+};
/* L1 instruction cache: */
-#define L1I_LINE_SIZE 64
-#define L1I_ASSOCIATIVITY 8
-#define L1I_SETS 64
-#define L1I_PARTITIONS 1
-/* Size = LINE_SIZE*ASSOCIATIVITY*SETS*PARTITIONS = 32KiB */
-#define L1I_DESCRIPTOR CPUID_2_L1I_32KB_8WAY_64B
+static CPUCacheInfo l1i_cache = {
+ .type = ICACHE,
+ .level = 1,
+ .size = 32 * KiB,
+ .self_init = 1,
+ .line_size = 64,
+ .associativity = 8,
+ .sets = 64,
+ .partitions = 1,
+ .no_invd_sharing = true,
+};
+
/*FIXME: CPUID leaf 0x80000005 is inconsistent with leaves 2 & 4 */
-#define L1I_LINES_PER_TAG 1
-#define L1I_SIZE_KB_AMD 64
-#define L1I_ASSOCIATIVITY_AMD 2
+static CPUCacheInfo l1i_cache_amd = {
+ .type = ICACHE,
+ .level = 1,
+ .size = 64 * KiB,
+ .self_init = 1,
+ .line_size = 64,
+ .associativity = 2,
+ .sets = 512,
+ .partitions = 1,
+ .lines_per_tag = 1,
+ .no_invd_sharing = true,
+};
/* Level 2 unified cache: */
-#define L2_LINE_SIZE 64
-#define L2_ASSOCIATIVITY 16
-#define L2_SETS 4096
-#define L2_PARTITIONS 1
-/* Size = LINE_SIZE*ASSOCIATIVITY*SETS*PARTITIONS = 4MiB */
+static CPUCacheInfo l2_cache = {
+ .type = UNIFIED_CACHE,
+ .level = 2,
+ .size = 4 * MiB,
+ .self_init = 1,
+ .line_size = 64,
+ .associativity = 16,
+ .sets = 4096,
+ .partitions = 1,
+ .no_invd_sharing = true,
+};
+
/*FIXME: CPUID leaf 2 descriptor is inconsistent with CPUID leaf 4 */
-#define L2_DESCRIPTOR CPUID_2_L2_2MB_8WAY_64B
+static CPUCacheInfo l2_cache_cpuid2 = {
+ .type = UNIFIED_CACHE,
+ .level = 2,
+ .size = 2 * MiB,
+ .line_size = 64,
+ .associativity = 8,
+};
+
+
/*FIXME: CPUID leaf 0x80000006 is inconsistent with leaves 2 & 4 */
-#define L2_LINES_PER_TAG 1
-#define L2_SIZE_KB_AMD 512
+static CPUCacheInfo l2_cache_amd = {
+ .type = UNIFIED_CACHE,
+ .level = 2,
+ .size = 512 * KiB,
+ .line_size = 64,
+ .lines_per_tag = 1,
+ .associativity = 8,
+ .sets = 1024,
+ .partitions = 1,
+};
/* Level 3 unified cache: */
-#define L3_SIZE_KB 0 /* disabled */
-#define L3_ASSOCIATIVITY 0 /* disabled */
-#define L3_LINES_PER_TAG 0 /* disabled */
-#define L3_LINE_SIZE 0 /* disabled */
-#define L3_N_LINE_SIZE 64
-#define L3_N_ASSOCIATIVITY 16
-#define L3_N_SETS 16384
-#define L3_N_PARTITIONS 1
-#define L3_N_DESCRIPTOR CPUID_2_L3_16MB_16WAY_64B
-#define L3_N_LINES_PER_TAG 1
-#define L3_N_SIZE_KB_AMD 16384
+static CPUCacheInfo l3_cache = {
+ .type = UNIFIED_CACHE,
+ .level = 3,
+ .size = 16 * MiB,
+ .line_size = 64,
+ .associativity = 16,
+ .sets = 16384,
+ .partitions = 1,
+ .lines_per_tag = 1,
+ .self_init = true,
+ .inclusive = true,
+ .complex_indexing = true,
+};
/* TLB definitions: */
@@ -3301,85 +3591,53 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
if (!cpu->enable_l3_cache) {
*ecx = 0;
} else {
- *ecx = L3_N_DESCRIPTOR;
+ *ecx = cpuid2_cache_descriptor(&l3_cache);
}
- *edx = (L1D_DESCRIPTOR << 16) | \
- (L1I_DESCRIPTOR << 8) | \
- (L2_DESCRIPTOR);
+ *edx = (cpuid2_cache_descriptor(&l1d_cache) << 16) |
+ (cpuid2_cache_descriptor(&l1i_cache) << 8) |
+ (cpuid2_cache_descriptor(&l2_cache_cpuid2));
break;
case 4:
/* cache info: needed for Core compatibility */
if (cpu->cache_info_passthrough) {
host_cpuid(index, count, eax, ebx, ecx, edx);
+ /* QEMU gives out its own APIC IDs, never pass down bits 31..26. */
*eax &= ~0xFC000000;
+ if ((*eax & 31) && cs->nr_cores > 1) {
+ *eax |= (cs->nr_cores - 1) << 26;
+ }
} else {
*eax = 0;
switch (count) {
case 0: /* L1 dcache info */
- *eax |= CPUID_4_TYPE_DCACHE | \
- CPUID_4_LEVEL(1) | \
- CPUID_4_SELF_INIT_LEVEL;
- *ebx = (L1D_LINE_SIZE - 1) | \
- ((L1D_PARTITIONS - 1) << 12) | \
- ((L1D_ASSOCIATIVITY - 1) << 22);
- *ecx = L1D_SETS - 1;
- *edx = CPUID_4_NO_INVD_SHARING;
+ encode_cache_cpuid4(&l1d_cache,
+ 1, cs->nr_cores,
+ eax, ebx, ecx, edx);
break;
case 1: /* L1 icache info */
- *eax |= CPUID_4_TYPE_ICACHE | \
- CPUID_4_LEVEL(1) | \
- CPUID_4_SELF_INIT_LEVEL;
- *ebx = (L1I_LINE_SIZE - 1) | \
- ((L1I_PARTITIONS - 1) << 12) | \
- ((L1I_ASSOCIATIVITY - 1) << 22);
- *ecx = L1I_SETS - 1;
- *edx = CPUID_4_NO_INVD_SHARING;
+ encode_cache_cpuid4(&l1i_cache,
+ 1, cs->nr_cores,
+ eax, ebx, ecx, edx);
break;
case 2: /* L2 cache info */
- *eax |= CPUID_4_TYPE_UNIFIED | \
- CPUID_4_LEVEL(2) | \
- CPUID_4_SELF_INIT_LEVEL;
- if (cs->nr_threads > 1) {
- *eax |= (cs->nr_threads - 1) << 14;
- }
- *ebx = (L2_LINE_SIZE - 1) | \
- ((L2_PARTITIONS - 1) << 12) | \
- ((L2_ASSOCIATIVITY - 1) << 22);
- *ecx = L2_SETS - 1;
- *edx = CPUID_4_NO_INVD_SHARING;
+ encode_cache_cpuid4(&l2_cache,
+ cs->nr_threads, cs->nr_cores,
+ eax, ebx, ecx, edx);
break;
case 3: /* L3 cache info */
- if (!cpu->enable_l3_cache) {
- *eax = 0;
- *ebx = 0;
- *ecx = 0;
- *edx = 0;
+ pkg_offset = apicid_pkg_offset(cs->nr_cores, cs->nr_threads);
+ if (cpu->enable_l3_cache) {
+ encode_cache_cpuid4(&l3_cache,
+ (1 << pkg_offset), cs->nr_cores,
+ eax, ebx, ecx, edx);
break;
}
- *eax |= CPUID_4_TYPE_UNIFIED | \
- CPUID_4_LEVEL(3) | \
- CPUID_4_SELF_INIT_LEVEL;
- pkg_offset = apicid_pkg_offset(cs->nr_cores, cs->nr_threads);
- *eax |= ((1 << pkg_offset) - 1) << 14;
- *ebx = (L3_N_LINE_SIZE - 1) | \
- ((L3_N_PARTITIONS - 1) << 12) | \
- ((L3_N_ASSOCIATIVITY - 1) << 22);
- *ecx = L3_N_SETS - 1;
- *edx = CPUID_4_INCLUSIVE | CPUID_4_COMPLEX_IDX;
- break;
+ /* fall through */
default: /* end of info */
- *eax = 0;
- *ebx = 0;
- *ecx = 0;
- *edx = 0;
+ *eax = *ebx = *ecx = *edx = 0;
break;
}
}
-
- /* QEMU gives out its own APIC IDs, never pass down bits 31..26. */
- if ((*eax & 31) && cs->nr_cores > 1) {
- *eax |= (cs->nr_cores - 1) << 26;
- }
break;
case 5:
/* mwait info: needed for Core compatibility */
@@ -3583,10 +3841,8 @@ 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 = (L1D_SIZE_KB_AMD << 24) | (L1D_ASSOCIATIVITY_AMD << 16) | \
- (L1D_LINES_PER_TAG << 8) | (L1D_LINE_SIZE);
- *edx = (L1I_SIZE_KB_AMD << 24) | (L1I_ASSOCIATIVITY_AMD << 16) | \
- (L1I_LINES_PER_TAG << 8) | (L1I_LINE_SIZE);
+ *ecx = encode_cache_cpuid80000005(&l1d_cache_amd);
+ *edx = encode_cache_cpuid80000005(&l1i_cache_amd);
break;
case 0x80000006:
/* cache info (L2 cache) */
@@ -3602,18 +3858,9 @@ 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);
- *ecx = (L2_SIZE_KB_AMD << 16) | \
- (AMD_ENC_ASSOC(L2_ASSOCIATIVITY) << 12) | \
- (L2_LINES_PER_TAG << 8) | (L2_LINE_SIZE);
- if (!cpu->enable_l3_cache) {
- *edx = ((L3_SIZE_KB / 512) << 18) | \
- (AMD_ENC_ASSOC(L3_ASSOCIATIVITY) << 12) | \
- (L3_LINES_PER_TAG << 8) | (L3_LINE_SIZE);
- } else {
- *edx = ((L3_N_SIZE_KB_AMD / 512) << 18) | \
- (AMD_ENC_ASSOC(L3_N_ASSOCIATIVITY) << 12) | \
- (L3_N_LINES_PER_TAG << 8) | (L3_N_LINE_SIZE);
- }
+ encode_cache_cpuid80000006(&l2_cache_amd,
+ cpu->enable_l3_cache ? &l3_cache : NULL,
+ ecx, edx);
break;
case 0x80000007:
*eax = 0;
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 1b219fa..fa03e2c 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -1044,6 +1044,59 @@ typedef enum TPRAccess {
TPR_ACCESS_WRITE,
} TPRAccess;
+/* Cache information data structures: */
+
+enum CacheType {
+ DCACHE,
+ ICACHE,
+ UNIFIED_CACHE
+};
+
+typedef struct CPUCacheInfo {
+ enum CacheType type;
+ uint8_t level;
+ /* Size in bytes */
+ uint32_t size;
+ /* Line size, in bytes */
+ uint16_t line_size;
+ /*
+ * Associativity.
+ * Note: representation of fully-associative caches is not implemented
+ */
+ uint8_t associativity;
+ /* Physical line partitions. CPUID[0x8000001D].EBX, CPUID[4].EBX */
+ uint8_t partitions;
+ /* Number of sets. CPUID[0x8000001D].ECX, CPUID[4].ECX */
+ uint32_t sets;
+ /*
+ * Lines per tag.
+ * AMD-specific: CPUID[0x80000005], CPUID[0x80000006].
+ * (Is this synonym to @partitions?)
+ */
+ uint8_t lines_per_tag;
+
+ /* Self-initializing cache */
+ bool self_init;
+ /*
+ * WBINVD/INVD is not guaranteed to act upon lower level caches of
+ * non-originating threads sharing this cache.
+ * CPUID[4].EDX[bit 0], CPUID[0x8000001D].EDX[bit 0]
+ */
+ bool no_invd_sharing;
+ /*
+ * Cache is inclusive of lower cache levels.
+ * CPUID[4].EDX[bit 1], CPUID[0x8000001D].EDX[bit 1].
+ */
+ bool inclusive;
+ /*
+ * A complex function is used to index the cache, potentially using all
+ * address bits. CPUID[4].EDX[bit 2].
+ */
+ bool complex_indexing;
+} CPUCacheInfo;
+
+
+
typedef struct CPUX86State {
/* standard registers */
target_ulong regs[CPU_NB_REGS];
--
2.7.4
^ permalink raw reply related [flat|nested] 88+ messages in thread
* [Qemu-devel] [PATCH v7 1/9] i386: Helpers to encode cache information consistently
@ 2018-04-26 16:26 ` Babu Moger
0 siblings, 0 replies; 88+ messages in thread
From: Babu Moger @ 2018-04-26 16:26 UTC (permalink / raw)
To: mst, marcel, pbonzini, rth, ehabkost, mtosatti
Cc: qemu-devel, kvm, kash, geoff, babu.moger
From: Eduardo Habkost <ehabkost@redhat.com>
Instead of having a collection of macros that need to be used in
complex expressions to build CPUID data, define a CPUCacheInfo
struct that can hold information about a given cache. Helper
functions will take a CPUCacheInfo struct as input to encode
CPUID leaves for a cache.
This will help us ensure consistency between cache information
CPUID leaves, and make the existing inconsistencies in CPUID info
more visible.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Babu Moger <babu.moger@amd.com>
Tested-by: Geoffrey McRae <geoff@hostfission.com>
---
target/i386/cpu.c | 495 ++++++++++++++++++++++++++++++++++++++++--------------
target/i386/cpu.h | 53 ++++++
2 files changed, 424 insertions(+), 124 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index a20fe26..b6c1592 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -56,33 +56,240 @@
#include "disas/capstone.h"
+/* Helpers for building CPUID[2] descriptors: */
+
+struct CPUID2CacheDescriptorInfo {
+ enum CacheType type;
+ int level;
+ int size;
+ int line_size;
+ int associativity;
+};
-/* Cache topology CPUID constants: */
+#define KiB 1024
+#define MiB (1024 * 1024)
-/* CPUID Leaf 2 Descriptors */
+/*
+ * Known CPUID 2 cache descriptors.
+ * From Intel SDM Volume 2A, CPUID instruction
+ */
+struct CPUID2CacheDescriptorInfo cpuid2_cache_descriptors[] = {
+ [0x06] = { .level = 1, .type = ICACHE, .size = 8 * KiB,
+ .associativity = 4, .line_size = 32, },
+ [0x08] = { .level = 1, .type = ICACHE, .size = 16 * KiB,
+ .associativity = 4, .line_size = 32, },
+ [0x09] = { .level = 1, .type = ICACHE, .size = 32 * KiB,
+ .associativity = 4, .line_size = 64, },
+ [0x0A] = { .level = 1, .type = DCACHE, .size = 8 * KiB,
+ .associativity = 2, .line_size = 32, },
+ [0x0C] = { .level = 1, .type = DCACHE, .size = 16 * KiB,
+ .associativity = 4, .line_size = 32, },
+ [0x0D] = { .level = 1, .type = DCACHE, .size = 16 * KiB,
+ .associativity = 4, .line_size = 64, },
+ [0x0E] = { .level = 1, .type = DCACHE, .size = 24 * KiB,
+ .associativity = 6, .line_size = 64, },
+ [0x1D] = { .level = 2, .type = UNIFIED_CACHE, .size = 128 * KiB,
+ .associativity = 2, .line_size = 64, },
+ [0x21] = { .level = 2, .type = UNIFIED_CACHE, .size = 256 * KiB,
+ .associativity = 8, .line_size = 64, },
+ /* lines per sector is not supported cpuid2_cache_descriptor(),
+ * so descriptors 0x22, 0x23 are not included
+ */
+ [0x24] = { .level = 2, .type = UNIFIED_CACHE, .size = 1 * MiB,
+ .associativity = 16, .line_size = 64, },
+ /* lines per sector is not supported cpuid2_cache_descriptor(),
+ * so descriptors 0x25, 0x20 are not included
+ */
+ [0x2C] = { .level = 1, .type = DCACHE, .size = 32 * KiB,
+ .associativity = 8, .line_size = 64, },
+ [0x30] = { .level = 1, .type = ICACHE, .size = 32 * KiB,
+ .associativity = 8, .line_size = 64, },
+ [0x41] = { .level = 2, .type = UNIFIED_CACHE, .size = 128 * KiB,
+ .associativity = 4, .line_size = 32, },
+ [0x42] = { .level = 2, .type = UNIFIED_CACHE, .size = 256 * KiB,
+ .associativity = 4, .line_size = 32, },
+ [0x43] = { .level = 2, .type = UNIFIED_CACHE, .size = 512 * KiB,
+ .associativity = 4, .line_size = 32, },
+ [0x44] = { .level = 2, .type = UNIFIED_CACHE, .size = 1 * MiB,
+ .associativity = 4, .line_size = 32, },
+ [0x45] = { .level = 2, .type = UNIFIED_CACHE, .size = 2 * MiB,
+ .associativity = 4, .line_size = 32, },
+ [0x46] = { .level = 3, .type = UNIFIED_CACHE, .size = 4 * MiB,
+ .associativity = 4, .line_size = 64, },
+ [0x47] = { .level = 3, .type = UNIFIED_CACHE, .size = 8 * MiB,
+ .associativity = 8, .line_size = 64, },
+ [0x48] = { .level = 2, .type = UNIFIED_CACHE, .size = 3 * MiB,
+ .associativity = 12, .line_size = 64, },
+ /* Descriptor 0x49 depends on CPU family/model, so it is not included */
+ [0x4A] = { .level = 3, .type = UNIFIED_CACHE, .size = 6 * MiB,
+ .associativity = 12, .line_size = 64, },
+ [0x4B] = { .level = 3, .type = UNIFIED_CACHE, .size = 8 * MiB,
+ .associativity = 16, .line_size = 64, },
+ [0x4C] = { .level = 3, .type = UNIFIED_CACHE, .size = 12 * MiB,
+ .associativity = 12, .line_size = 64, },
+ [0x4D] = { .level = 3, .type = UNIFIED_CACHE, .size = 16 * MiB,
+ .associativity = 16, .line_size = 64, },
+ [0x4E] = { .level = 2, .type = UNIFIED_CACHE, .size = 6 * MiB,
+ .associativity = 24, .line_size = 64, },
+ [0x60] = { .level = 1, .type = DCACHE, .size = 16 * KiB,
+ .associativity = 8, .line_size = 64, },
+ [0x66] = { .level = 1, .type = DCACHE, .size = 8 * KiB,
+ .associativity = 4, .line_size = 64, },
+ [0x67] = { .level = 1, .type = DCACHE, .size = 16 * KiB,
+ .associativity = 4, .line_size = 64, },
+ [0x68] = { .level = 1, .type = DCACHE, .size = 32 * KiB,
+ .associativity = 4, .line_size = 64, },
+ [0x78] = { .level = 2, .type = UNIFIED_CACHE, .size = 1 * MiB,
+ .associativity = 4, .line_size = 64, },
+ /* lines per sector is not supported cpuid2_cache_descriptor(),
+ * so descriptors 0x79, 0x7A, 0x7B, 0x7C are not included.
+ */
+ [0x7D] = { .level = 2, .type = UNIFIED_CACHE, .size = 2 * MiB,
+ .associativity = 8, .line_size = 64, },
+ [0x7F] = { .level = 2, .type = UNIFIED_CACHE, .size = 512 * KiB,
+ .associativity = 2, .line_size = 64, },
+ [0x80] = { .level = 2, .type = UNIFIED_CACHE, .size = 512 * KiB,
+ .associativity = 8, .line_size = 64, },
+ [0x82] = { .level = 2, .type = UNIFIED_CACHE, .size = 256 * KiB,
+ .associativity = 8, .line_size = 32, },
+ [0x83] = { .level = 2, .type = UNIFIED_CACHE, .size = 512 * KiB,
+ .associativity = 8, .line_size = 32, },
+ [0x84] = { .level = 2, .type = UNIFIED_CACHE, .size = 1 * MiB,
+ .associativity = 8, .line_size = 32, },
+ [0x85] = { .level = 2, .type = UNIFIED_CACHE, .size = 2 * MiB,
+ .associativity = 8, .line_size = 32, },
+ [0x86] = { .level = 2, .type = UNIFIED_CACHE, .size = 512 * KiB,
+ .associativity = 4, .line_size = 64, },
+ [0x87] = { .level = 2, .type = UNIFIED_CACHE, .size = 1 * MiB,
+ .associativity = 8, .line_size = 64, },
+ [0xD0] = { .level = 3, .type = UNIFIED_CACHE, .size = 512 * KiB,
+ .associativity = 4, .line_size = 64, },
+ [0xD1] = { .level = 3, .type = UNIFIED_CACHE, .size = 1 * MiB,
+ .associativity = 4, .line_size = 64, },
+ [0xD2] = { .level = 3, .type = UNIFIED_CACHE, .size = 2 * MiB,
+ .associativity = 4, .line_size = 64, },
+ [0xD6] = { .level = 3, .type = UNIFIED_CACHE, .size = 1 * MiB,
+ .associativity = 8, .line_size = 64, },
+ [0xD7] = { .level = 3, .type = UNIFIED_CACHE, .size = 2 * MiB,
+ .associativity = 8, .line_size = 64, },
+ [0xD8] = { .level = 3, .type = UNIFIED_CACHE, .size = 4 * MiB,
+ .associativity = 8, .line_size = 64, },
+ [0xDC] = { .level = 3, .type = UNIFIED_CACHE, .size = 1.5 * MiB,
+ .associativity = 12, .line_size = 64, },
+ [0xDD] = { .level = 3, .type = UNIFIED_CACHE, .size = 3 * MiB,
+ .associativity = 12, .line_size = 64, },
+ [0xDE] = { .level = 3, .type = UNIFIED_CACHE, .size = 6 * MiB,
+ .associativity = 12, .line_size = 64, },
+ [0xE2] = { .level = 3, .type = UNIFIED_CACHE, .size = 2 * MiB,
+ .associativity = 16, .line_size = 64, },
+ [0xE3] = { .level = 3, .type = UNIFIED_CACHE, .size = 4 * MiB,
+ .associativity = 16, .line_size = 64, },
+ [0xE4] = { .level = 3, .type = UNIFIED_CACHE, .size = 8 * MiB,
+ .associativity = 16, .line_size = 64, },
+ [0xEA] = { .level = 3, .type = UNIFIED_CACHE, .size = 12 * MiB,
+ .associativity = 24, .line_size = 64, },
+ [0xEB] = { .level = 3, .type = UNIFIED_CACHE, .size = 18 * MiB,
+ .associativity = 24, .line_size = 64, },
+ [0xEC] = { .level = 3, .type = UNIFIED_CACHE, .size = 24 * MiB,
+ .associativity = 24, .line_size = 64, },
+};
+
+/*
+ * "CPUID leaf 2 does not report cache descriptor information,
+ * use CPUID leaf 4 to query cache parameters"
+ */
+#define CACHE_DESCRIPTOR_UNAVAILABLE 0xFF
-#define CPUID_2_L1D_32KB_8WAY_64B 0x2c
-#define CPUID_2_L1I_32KB_8WAY_64B 0x30
-#define CPUID_2_L2_2MB_8WAY_64B 0x7d
-#define CPUID_2_L3_16MB_16WAY_64B 0x4d
+/*
+ * Return a CPUID 2 cache descriptor for a given cache.
+ * If no known descriptor is found, return CACHE_DESCRIPTOR_UNAVAILABLE
+ */
+static uint8_t cpuid2_cache_descriptor(CPUCacheInfo *cache)
+{
+ int i;
+
+ assert(cache->size > 0);
+ assert(cache->level > 0);
+ assert(cache->line_size > 0);
+ assert(cache->associativity > 0);
+ for (i = 0; i < ARRAY_SIZE(cpuid2_cache_descriptors); i++) {
+ struct CPUID2CacheDescriptorInfo *d = &cpuid2_cache_descriptors[i];
+ if (d->level == cache->level && d->type == cache->type &&
+ d->size == cache->size && d->line_size == cache->line_size &&
+ d->associativity == cache->associativity) {
+ return i;
+ }
+ }
+ return CACHE_DESCRIPTOR_UNAVAILABLE;
+}
/* CPUID Leaf 4 constants: */
/* EAX: */
-#define CPUID_4_TYPE_DCACHE 1
-#define CPUID_4_TYPE_ICACHE 2
-#define CPUID_4_TYPE_UNIFIED 3
+#define CACHE_TYPE_D 1
+#define CACHE_TYPE_I 2
+#define CACHE_TYPE_UNIFIED 3
-#define CPUID_4_LEVEL(l) ((l) << 5)
+#define CACHE_LEVEL(l) (l << 5)
-#define CPUID_4_SELF_INIT_LEVEL (1 << 8)
-#define CPUID_4_FULLY_ASSOC (1 << 9)
+#define CACHE_SELF_INIT_LEVEL (1 << 8)
/* EDX: */
-#define CPUID_4_NO_INVD_SHARING (1 << 0)
-#define CPUID_4_INCLUSIVE (1 << 1)
-#define CPUID_4_COMPLEX_IDX (1 << 2)
+#define CACHE_NO_INVD_SHARING (1 << 0)
+#define CACHE_INCLUSIVE (1 << 1)
+#define CACHE_COMPLEX_IDX (1 << 2)
+
+/* Encode CacheType for CPUID[4].EAX */
+#define CACHE_TYPE(t) (((t) == DCACHE) ? CACHE_TYPE_D : \
+ ((t) == ICACHE) ? CACHE_TYPE_I : \
+ ((t) == UNIFIED_CACHE) ? CACHE_TYPE_UNIFIED : \
+ 0 /* Invalid value */)
+
+
+/* Encode cache info for CPUID[4] */
+static void encode_cache_cpuid4(CPUCacheInfo *cache,
+ int num_apic_ids, int num_cores,
+ uint32_t *eax, uint32_t *ebx,
+ uint32_t *ecx, uint32_t *edx)
+{
+ assert(cache->size == cache->line_size * cache->associativity *
+ cache->partitions * cache->sets);
+
+ assert(num_apic_ids > 0);
+ *eax = CACHE_TYPE(cache->type) |
+ CACHE_LEVEL(cache->level) |
+ (cache->self_init ? CACHE_SELF_INIT_LEVEL : 0) |
+ ((num_cores - 1) << 26) |
+ ((num_apic_ids - 1) << 14);
+
+ assert(cache->line_size > 0);
+ assert(cache->partitions > 0);
+ assert(cache->associativity > 0);
+ /* We don't implement fully-associative caches */
+ assert(cache->associativity < cache->sets);
+ *ebx = (cache->line_size - 1) |
+ ((cache->partitions - 1) << 12) |
+ ((cache->associativity - 1) << 22);
+
+ assert(cache->sets > 0);
+ *ecx = cache->sets - 1;
+
+ *edx = (cache->no_invd_sharing ? CACHE_NO_INVD_SHARING : 0) |
+ (cache->inclusive ? CACHE_INCLUSIVE : 0) |
+ (cache->complex_indexing ? CACHE_COMPLEX_IDX : 0);
+}
+
+/* Encode cache info for CPUID[0x80000005].ECX or CPUID[0x80000005].EDX */
+static uint32_t encode_cache_cpuid80000005(CPUCacheInfo *cache)
+{
+ assert(cache->size % 1024 == 0);
+ assert(cache->lines_per_tag > 0);
+ assert(cache->associativity > 0);
+ assert(cache->line_size > 0);
+ return ((cache->size / 1024) << 24) | (cache->associativity << 16) |
+ (cache->lines_per_tag << 8) | (cache->line_size);
+}
#define ASSOC_FULL 0xFF
@@ -100,57 +307,140 @@
a == ASSOC_FULL ? 0xF : \
0 /* invalid value */)
+/*
+ * Encode cache info for CPUID[0x80000006].ECX and CPUID[0x80000006].EDX
+ * @l3 can be NULL.
+ */
+static void encode_cache_cpuid80000006(CPUCacheInfo *l2,
+ CPUCacheInfo *l3,
+ uint32_t *ecx, uint32_t *edx)
+{
+ assert(l2->size % 1024 == 0);
+ assert(l2->associativity > 0);
+ assert(l2->lines_per_tag > 0);
+ assert(l2->line_size > 0);
+ *ecx = ((l2->size / 1024) << 16) |
+ (AMD_ENC_ASSOC(l2->associativity) << 12) |
+ (l2->lines_per_tag << 8) | (l2->line_size);
+
+ if (l3) {
+ assert(l3->size % (512 * 1024) == 0);
+ assert(l3->associativity > 0);
+ assert(l3->lines_per_tag > 0);
+ assert(l3->line_size > 0);
+ *edx = ((l3->size / (512 * 1024)) << 18) |
+ (AMD_ENC_ASSOC(l3->associativity) << 12) |
+ (l3->lines_per_tag << 8) | (l3->line_size);
+ } else {
+ *edx = 0;
+ }
+}
/* Definitions of the hardcoded cache entries we expose: */
/* L1 data cache: */
-#define L1D_LINE_SIZE 64
-#define L1D_ASSOCIATIVITY 8
-#define L1D_SETS 64
-#define L1D_PARTITIONS 1
-/* Size = LINE_SIZE*ASSOCIATIVITY*SETS*PARTITIONS = 32KiB */
-#define L1D_DESCRIPTOR CPUID_2_L1D_32KB_8WAY_64B
+static CPUCacheInfo l1d_cache = {
+ .type = DCACHE,
+ .level = 1,
+ .size = 32 * KiB,
+ .self_init = 1,
+ .line_size = 64,
+ .associativity = 8,
+ .sets = 64,
+ .partitions = 1,
+ .no_invd_sharing = true,
+};
+
/*FIXME: CPUID leaf 0x80000005 is inconsistent with leaves 2 & 4 */
-#define L1D_LINES_PER_TAG 1
-#define L1D_SIZE_KB_AMD 64
-#define L1D_ASSOCIATIVITY_AMD 2
+static CPUCacheInfo l1d_cache_amd = {
+ .type = DCACHE,
+ .level = 1,
+ .size = 64 * KiB,
+ .self_init = 1,
+ .line_size = 64,
+ .associativity = 2,
+ .sets = 512,
+ .partitions = 1,
+ .lines_per_tag = 1,
+ .no_invd_sharing = true,
+};
/* L1 instruction cache: */
-#define L1I_LINE_SIZE 64
-#define L1I_ASSOCIATIVITY 8
-#define L1I_SETS 64
-#define L1I_PARTITIONS 1
-/* Size = LINE_SIZE*ASSOCIATIVITY*SETS*PARTITIONS = 32KiB */
-#define L1I_DESCRIPTOR CPUID_2_L1I_32KB_8WAY_64B
+static CPUCacheInfo l1i_cache = {
+ .type = ICACHE,
+ .level = 1,
+ .size = 32 * KiB,
+ .self_init = 1,
+ .line_size = 64,
+ .associativity = 8,
+ .sets = 64,
+ .partitions = 1,
+ .no_invd_sharing = true,
+};
+
/*FIXME: CPUID leaf 0x80000005 is inconsistent with leaves 2 & 4 */
-#define L1I_LINES_PER_TAG 1
-#define L1I_SIZE_KB_AMD 64
-#define L1I_ASSOCIATIVITY_AMD 2
+static CPUCacheInfo l1i_cache_amd = {
+ .type = ICACHE,
+ .level = 1,
+ .size = 64 * KiB,
+ .self_init = 1,
+ .line_size = 64,
+ .associativity = 2,
+ .sets = 512,
+ .partitions = 1,
+ .lines_per_tag = 1,
+ .no_invd_sharing = true,
+};
/* Level 2 unified cache: */
-#define L2_LINE_SIZE 64
-#define L2_ASSOCIATIVITY 16
-#define L2_SETS 4096
-#define L2_PARTITIONS 1
-/* Size = LINE_SIZE*ASSOCIATIVITY*SETS*PARTITIONS = 4MiB */
+static CPUCacheInfo l2_cache = {
+ .type = UNIFIED_CACHE,
+ .level = 2,
+ .size = 4 * MiB,
+ .self_init = 1,
+ .line_size = 64,
+ .associativity = 16,
+ .sets = 4096,
+ .partitions = 1,
+ .no_invd_sharing = true,
+};
+
/*FIXME: CPUID leaf 2 descriptor is inconsistent with CPUID leaf 4 */
-#define L2_DESCRIPTOR CPUID_2_L2_2MB_8WAY_64B
+static CPUCacheInfo l2_cache_cpuid2 = {
+ .type = UNIFIED_CACHE,
+ .level = 2,
+ .size = 2 * MiB,
+ .line_size = 64,
+ .associativity = 8,
+};
+
+
/*FIXME: CPUID leaf 0x80000006 is inconsistent with leaves 2 & 4 */
-#define L2_LINES_PER_TAG 1
-#define L2_SIZE_KB_AMD 512
+static CPUCacheInfo l2_cache_amd = {
+ .type = UNIFIED_CACHE,
+ .level = 2,
+ .size = 512 * KiB,
+ .line_size = 64,
+ .lines_per_tag = 1,
+ .associativity = 8,
+ .sets = 1024,
+ .partitions = 1,
+};
/* Level 3 unified cache: */
-#define L3_SIZE_KB 0 /* disabled */
-#define L3_ASSOCIATIVITY 0 /* disabled */
-#define L3_LINES_PER_TAG 0 /* disabled */
-#define L3_LINE_SIZE 0 /* disabled */
-#define L3_N_LINE_SIZE 64
-#define L3_N_ASSOCIATIVITY 16
-#define L3_N_SETS 16384
-#define L3_N_PARTITIONS 1
-#define L3_N_DESCRIPTOR CPUID_2_L3_16MB_16WAY_64B
-#define L3_N_LINES_PER_TAG 1
-#define L3_N_SIZE_KB_AMD 16384
+static CPUCacheInfo l3_cache = {
+ .type = UNIFIED_CACHE,
+ .level = 3,
+ .size = 16 * MiB,
+ .line_size = 64,
+ .associativity = 16,
+ .sets = 16384,
+ .partitions = 1,
+ .lines_per_tag = 1,
+ .self_init = true,
+ .inclusive = true,
+ .complex_indexing = true,
+};
/* TLB definitions: */
@@ -3301,85 +3591,53 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
if (!cpu->enable_l3_cache) {
*ecx = 0;
} else {
- *ecx = L3_N_DESCRIPTOR;
+ *ecx = cpuid2_cache_descriptor(&l3_cache);
}
- *edx = (L1D_DESCRIPTOR << 16) | \
- (L1I_DESCRIPTOR << 8) | \
- (L2_DESCRIPTOR);
+ *edx = (cpuid2_cache_descriptor(&l1d_cache) << 16) |
+ (cpuid2_cache_descriptor(&l1i_cache) << 8) |
+ (cpuid2_cache_descriptor(&l2_cache_cpuid2));
break;
case 4:
/* cache info: needed for Core compatibility */
if (cpu->cache_info_passthrough) {
host_cpuid(index, count, eax, ebx, ecx, edx);
+ /* QEMU gives out its own APIC IDs, never pass down bits 31..26. */
*eax &= ~0xFC000000;
+ if ((*eax & 31) && cs->nr_cores > 1) {
+ *eax |= (cs->nr_cores - 1) << 26;
+ }
} else {
*eax = 0;
switch (count) {
case 0: /* L1 dcache info */
- *eax |= CPUID_4_TYPE_DCACHE | \
- CPUID_4_LEVEL(1) | \
- CPUID_4_SELF_INIT_LEVEL;
- *ebx = (L1D_LINE_SIZE - 1) | \
- ((L1D_PARTITIONS - 1) << 12) | \
- ((L1D_ASSOCIATIVITY - 1) << 22);
- *ecx = L1D_SETS - 1;
- *edx = CPUID_4_NO_INVD_SHARING;
+ encode_cache_cpuid4(&l1d_cache,
+ 1, cs->nr_cores,
+ eax, ebx, ecx, edx);
break;
case 1: /* L1 icache info */
- *eax |= CPUID_4_TYPE_ICACHE | \
- CPUID_4_LEVEL(1) | \
- CPUID_4_SELF_INIT_LEVEL;
- *ebx = (L1I_LINE_SIZE - 1) | \
- ((L1I_PARTITIONS - 1) << 12) | \
- ((L1I_ASSOCIATIVITY - 1) << 22);
- *ecx = L1I_SETS - 1;
- *edx = CPUID_4_NO_INVD_SHARING;
+ encode_cache_cpuid4(&l1i_cache,
+ 1, cs->nr_cores,
+ eax, ebx, ecx, edx);
break;
case 2: /* L2 cache info */
- *eax |= CPUID_4_TYPE_UNIFIED | \
- CPUID_4_LEVEL(2) | \
- CPUID_4_SELF_INIT_LEVEL;
- if (cs->nr_threads > 1) {
- *eax |= (cs->nr_threads - 1) << 14;
- }
- *ebx = (L2_LINE_SIZE - 1) | \
- ((L2_PARTITIONS - 1) << 12) | \
- ((L2_ASSOCIATIVITY - 1) << 22);
- *ecx = L2_SETS - 1;
- *edx = CPUID_4_NO_INVD_SHARING;
+ encode_cache_cpuid4(&l2_cache,
+ cs->nr_threads, cs->nr_cores,
+ eax, ebx, ecx, edx);
break;
case 3: /* L3 cache info */
- if (!cpu->enable_l3_cache) {
- *eax = 0;
- *ebx = 0;
- *ecx = 0;
- *edx = 0;
+ pkg_offset = apicid_pkg_offset(cs->nr_cores, cs->nr_threads);
+ if (cpu->enable_l3_cache) {
+ encode_cache_cpuid4(&l3_cache,
+ (1 << pkg_offset), cs->nr_cores,
+ eax, ebx, ecx, edx);
break;
}
- *eax |= CPUID_4_TYPE_UNIFIED | \
- CPUID_4_LEVEL(3) | \
- CPUID_4_SELF_INIT_LEVEL;
- pkg_offset = apicid_pkg_offset(cs->nr_cores, cs->nr_threads);
- *eax |= ((1 << pkg_offset) - 1) << 14;
- *ebx = (L3_N_LINE_SIZE - 1) | \
- ((L3_N_PARTITIONS - 1) << 12) | \
- ((L3_N_ASSOCIATIVITY - 1) << 22);
- *ecx = L3_N_SETS - 1;
- *edx = CPUID_4_INCLUSIVE | CPUID_4_COMPLEX_IDX;
- break;
+ /* fall through */
default: /* end of info */
- *eax = 0;
- *ebx = 0;
- *ecx = 0;
- *edx = 0;
+ *eax = *ebx = *ecx = *edx = 0;
break;
}
}
-
- /* QEMU gives out its own APIC IDs, never pass down bits 31..26. */
- if ((*eax & 31) && cs->nr_cores > 1) {
- *eax |= (cs->nr_cores - 1) << 26;
- }
break;
case 5:
/* mwait info: needed for Core compatibility */
@@ -3583,10 +3841,8 @@ 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 = (L1D_SIZE_KB_AMD << 24) | (L1D_ASSOCIATIVITY_AMD << 16) | \
- (L1D_LINES_PER_TAG << 8) | (L1D_LINE_SIZE);
- *edx = (L1I_SIZE_KB_AMD << 24) | (L1I_ASSOCIATIVITY_AMD << 16) | \
- (L1I_LINES_PER_TAG << 8) | (L1I_LINE_SIZE);
+ *ecx = encode_cache_cpuid80000005(&l1d_cache_amd);
+ *edx = encode_cache_cpuid80000005(&l1i_cache_amd);
break;
case 0x80000006:
/* cache info (L2 cache) */
@@ -3602,18 +3858,9 @@ 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);
- *ecx = (L2_SIZE_KB_AMD << 16) | \
- (AMD_ENC_ASSOC(L2_ASSOCIATIVITY) << 12) | \
- (L2_LINES_PER_TAG << 8) | (L2_LINE_SIZE);
- if (!cpu->enable_l3_cache) {
- *edx = ((L3_SIZE_KB / 512) << 18) | \
- (AMD_ENC_ASSOC(L3_ASSOCIATIVITY) << 12) | \
- (L3_LINES_PER_TAG << 8) | (L3_LINE_SIZE);
- } else {
- *edx = ((L3_N_SIZE_KB_AMD / 512) << 18) | \
- (AMD_ENC_ASSOC(L3_N_ASSOCIATIVITY) << 12) | \
- (L3_N_LINES_PER_TAG << 8) | (L3_N_LINE_SIZE);
- }
+ encode_cache_cpuid80000006(&l2_cache_amd,
+ cpu->enable_l3_cache ? &l3_cache : NULL,
+ ecx, edx);
break;
case 0x80000007:
*eax = 0;
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 1b219fa..fa03e2c 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -1044,6 +1044,59 @@ typedef enum TPRAccess {
TPR_ACCESS_WRITE,
} TPRAccess;
+/* Cache information data structures: */
+
+enum CacheType {
+ DCACHE,
+ ICACHE,
+ UNIFIED_CACHE
+};
+
+typedef struct CPUCacheInfo {
+ enum CacheType type;
+ uint8_t level;
+ /* Size in bytes */
+ uint32_t size;
+ /* Line size, in bytes */
+ uint16_t line_size;
+ /*
+ * Associativity.
+ * Note: representation of fully-associative caches is not implemented
+ */
+ uint8_t associativity;
+ /* Physical line partitions. CPUID[0x8000001D].EBX, CPUID[4].EBX */
+ uint8_t partitions;
+ /* Number of sets. CPUID[0x8000001D].ECX, CPUID[4].ECX */
+ uint32_t sets;
+ /*
+ * Lines per tag.
+ * AMD-specific: CPUID[0x80000005], CPUID[0x80000006].
+ * (Is this synonym to @partitions?)
+ */
+ uint8_t lines_per_tag;
+
+ /* Self-initializing cache */
+ bool self_init;
+ /*
+ * WBINVD/INVD is not guaranteed to act upon lower level caches of
+ * non-originating threads sharing this cache.
+ * CPUID[4].EDX[bit 0], CPUID[0x8000001D].EDX[bit 0]
+ */
+ bool no_invd_sharing;
+ /*
+ * Cache is inclusive of lower cache levels.
+ * CPUID[4].EDX[bit 1], CPUID[0x8000001D].EDX[bit 1].
+ */
+ bool inclusive;
+ /*
+ * A complex function is used to index the cache, potentially using all
+ * address bits. CPUID[4].EDX[bit 2].
+ */
+ bool complex_indexing;
+} CPUCacheInfo;
+
+
+
typedef struct CPUX86State {
/* standard registers */
target_ulong regs[CPU_NB_REGS];
--
2.7.4
^ permalink raw reply related [flat|nested] 88+ messages in thread
* [PATCH v7 2/9] i386: Add cache information in X86CPUDefinition
2018-04-26 16:26 ` [Qemu-devel] " Babu Moger
@ 2018-04-26 16:26 ` Babu Moger
-1 siblings, 0 replies; 88+ messages in thread
From: Babu Moger @ 2018-04-26 16:26 UTC (permalink / raw)
To: mst, marcel, pbonzini, rth, ehabkost, mtosatti
Cc: geoff, babu.moger, kash, qemu-devel, kvm
Add cache information in X86CPUDefinition and CPUX86State.
Signed-off-by: Babu Moger <babu.moger@amd.com>
Tested-by: Geoffrey McRae <geoff@hostfission.com>
---
target/i386/cpu.c | 4 ++++
target/i386/cpu.h | 8 ++++++++
2 files changed, 12 insertions(+)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index b6c1592..a518a0f 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -1105,6 +1105,7 @@ struct X86CPUDefinition {
int stepping;
FeatureWordArray features;
const char *model_id;
+ CPUCaches cache_info;
};
static X86CPUDefinition builtin_x86_defs[] = {
@@ -3242,6 +3243,9 @@ static void x86_cpu_load_def(X86CPU *cpu, X86CPUDefinition *def, Error **errp)
env->features[w] = def->features[w];
}
+ /* Load Cache information from the X86CPUDefinition */
+ memcpy(&env->cache_info, &def->cache_info, sizeof(CPUCaches));
+
/* Special cases not set in the X86CPUDefinition structs: */
/* TODO: in-kernel irqchip for hvf */
if (kvm_enabled()) {
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index fa03e2c..1213bb7 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -1096,6 +1096,13 @@ typedef struct CPUCacheInfo {
} CPUCacheInfo;
+typedef struct CPUCaches {
+ bool valid;
+ CPUCacheInfo l1d_cache;
+ CPUCacheInfo l1i_cache;
+ CPUCacheInfo l2_cache;
+ CPUCacheInfo l3_cache;
+} CPUCaches;
typedef struct CPUX86State {
/* standard registers */
@@ -1282,6 +1289,7 @@ typedef struct CPUX86State {
/* Features that were explicitly enabled/disabled */
FeatureWordArray user_features;
uint32_t cpuid_model[12];
+ CPUCaches cache_info;
/* MTRRs */
uint64_t mtrr_fixed[11];
--
2.7.4
^ permalink raw reply related [flat|nested] 88+ messages in thread
* [Qemu-devel] [PATCH v7 2/9] i386: Add cache information in X86CPUDefinition
@ 2018-04-26 16:26 ` Babu Moger
0 siblings, 0 replies; 88+ messages in thread
From: Babu Moger @ 2018-04-26 16:26 UTC (permalink / raw)
To: mst, marcel, pbonzini, rth, ehabkost, mtosatti
Cc: qemu-devel, kvm, kash, geoff, babu.moger
Add cache information in X86CPUDefinition and CPUX86State.
Signed-off-by: Babu Moger <babu.moger@amd.com>
Tested-by: Geoffrey McRae <geoff@hostfission.com>
---
target/i386/cpu.c | 4 ++++
target/i386/cpu.h | 8 ++++++++
2 files changed, 12 insertions(+)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index b6c1592..a518a0f 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -1105,6 +1105,7 @@ struct X86CPUDefinition {
int stepping;
FeatureWordArray features;
const char *model_id;
+ CPUCaches cache_info;
};
static X86CPUDefinition builtin_x86_defs[] = {
@@ -3242,6 +3243,9 @@ static void x86_cpu_load_def(X86CPU *cpu, X86CPUDefinition *def, Error **errp)
env->features[w] = def->features[w];
}
+ /* Load Cache information from the X86CPUDefinition */
+ memcpy(&env->cache_info, &def->cache_info, sizeof(CPUCaches));
+
/* Special cases not set in the X86CPUDefinition structs: */
/* TODO: in-kernel irqchip for hvf */
if (kvm_enabled()) {
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index fa03e2c..1213bb7 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -1096,6 +1096,13 @@ typedef struct CPUCacheInfo {
} CPUCacheInfo;
+typedef struct CPUCaches {
+ bool valid;
+ CPUCacheInfo l1d_cache;
+ CPUCacheInfo l1i_cache;
+ CPUCacheInfo l2_cache;
+ CPUCacheInfo l3_cache;
+} CPUCaches;
typedef struct CPUX86State {
/* standard registers */
@@ -1282,6 +1289,7 @@ typedef struct CPUX86State {
/* Features that were explicitly enabled/disabled */
FeatureWordArray user_features;
uint32_t cpuid_model[12];
+ CPUCaches cache_info;
/* MTRRs */
uint64_t mtrr_fixed[11];
--
2.7.4
^ permalink raw reply related [flat|nested] 88+ messages in thread
* [PATCH v7 3/9] i386: Initialize cache information for EPYC family processors
2018-04-26 16:26 ` [Qemu-devel] " Babu Moger
@ 2018-04-26 16:26 ` Babu Moger
-1 siblings, 0 replies; 88+ messages in thread
From: Babu Moger @ 2018-04-26 16:26 UTC (permalink / raw)
To: mst, marcel, pbonzini, rth, ehabkost, mtosatti
Cc: geoff, babu.moger, kash, qemu-devel, kvm
Initialize pre-determined cache information for EPYC processors.
Signed-off-by: Babu Moger <babu.moger@amd.com>
Tested-by: Geoffrey McRae <geoff@hostfission.com>
---
target/i386/cpu.c | 96 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 96 insertions(+)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index a518a0f..5d88363 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -2302,6 +2302,54 @@ static X86CPUDefinition builtin_x86_defs[] = {
CPUID_6_EAX_ARAT,
.xlevel = 0x8000000A,
.model_id = "AMD EPYC Processor",
+ .cache_info.valid = 1,
+ .cache_info.l1d_cache = {
+ .type = DCACHE,
+ .level = 1,
+ .size = 32 * KiB,
+ .line_size = 64,
+ .associativity = 8,
+ .partitions = 1,
+ .sets = 64,
+ .lines_per_tag = 1,
+ .self_init = 1,
+ .no_invd_sharing = true,
+ },
+ .cache_info.l1i_cache = {
+ .type = ICACHE,
+ .level = 1,
+ .size = 64 * KiB,
+ .line_size = 64,
+ .associativity = 4,
+ .partitions = 1,
+ .sets = 256,
+ .lines_per_tag = 1,
+ .self_init = 1,
+ .no_invd_sharing = true,
+ },
+ .cache_info.l2_cache = {
+ .type = UNIFIED_CACHE,
+ .level = 2,
+ .size = 512 * KiB,
+ .line_size = 64,
+ .associativity = 8,
+ .partitions = 1,
+ .sets = 1024,
+ .lines_per_tag = 1,
+ },
+ .cache_info.l3_cache = {
+ .type = UNIFIED_CACHE,
+ .level = 3,
+ .size = 8 * MiB,
+ .line_size = 64,
+ .associativity = 16,
+ .partitions = 1,
+ .sets = 8192,
+ .lines_per_tag = 1,
+ .self_init = true,
+ .inclusive = true,
+ .complex_indexing = true,
+ },
},
{
.name = "EPYC-IBPB",
@@ -2348,6 +2396,54 @@ static X86CPUDefinition builtin_x86_defs[] = {
CPUID_6_EAX_ARAT,
.xlevel = 0x8000000A,
.model_id = "AMD EPYC Processor (with IBPB)",
+ .cache_info.valid = 1,
+ .cache_info.l1d_cache = {
+ .type = DCACHE,
+ .level = 1,
+ .size = 32 * KiB,
+ .line_size = 64,
+ .associativity = 8,
+ .partitions = 1,
+ .sets = 64,
+ .lines_per_tag = 1,
+ .self_init = 1,
+ .no_invd_sharing = true,
+ },
+ .cache_info.l1i_cache = {
+ .type = ICACHE,
+ .level = 1,
+ .size = 64 * KiB,
+ .line_size = 64,
+ .associativity = 4,
+ .partitions = 1,
+ .sets = 256,
+ .lines_per_tag = 1,
+ .self_init = 1,
+ .no_invd_sharing = true,
+ },
+ .cache_info.l2_cache = {
+ .type = UNIFIED_CACHE,
+ .level = 2,
+ .size = 512 * KiB,
+ .line_size = 64,
+ .associativity = 8,
+ .partitions = 1,
+ .sets = 1024,
+ .lines_per_tag = 1,
+ },
+ .cache_info.l3_cache = {
+ .type = UNIFIED_CACHE,
+ .level = 3,
+ .size = 8 * MiB,
+ .line_size = 64,
+ .associativity = 16,
+ .partitions = 1,
+ .sets = 8192,
+ .lines_per_tag = 1,
+ .self_init = true,
+ .inclusive = true,
+ .complex_indexing = true,
+ },
},
};
--
2.7.4
^ permalink raw reply related [flat|nested] 88+ messages in thread
* [Qemu-devel] [PATCH v7 3/9] i386: Initialize cache information for EPYC family processors
@ 2018-04-26 16:26 ` Babu Moger
0 siblings, 0 replies; 88+ messages in thread
From: Babu Moger @ 2018-04-26 16:26 UTC (permalink / raw)
To: mst, marcel, pbonzini, rth, ehabkost, mtosatti
Cc: qemu-devel, kvm, kash, geoff, babu.moger
Initialize pre-determined cache information for EPYC processors.
Signed-off-by: Babu Moger <babu.moger@amd.com>
Tested-by: Geoffrey McRae <geoff@hostfission.com>
---
target/i386/cpu.c | 96 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 96 insertions(+)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index a518a0f..5d88363 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -2302,6 +2302,54 @@ static X86CPUDefinition builtin_x86_defs[] = {
CPUID_6_EAX_ARAT,
.xlevel = 0x8000000A,
.model_id = "AMD EPYC Processor",
+ .cache_info.valid = 1,
+ .cache_info.l1d_cache = {
+ .type = DCACHE,
+ .level = 1,
+ .size = 32 * KiB,
+ .line_size = 64,
+ .associativity = 8,
+ .partitions = 1,
+ .sets = 64,
+ .lines_per_tag = 1,
+ .self_init = 1,
+ .no_invd_sharing = true,
+ },
+ .cache_info.l1i_cache = {
+ .type = ICACHE,
+ .level = 1,
+ .size = 64 * KiB,
+ .line_size = 64,
+ .associativity = 4,
+ .partitions = 1,
+ .sets = 256,
+ .lines_per_tag = 1,
+ .self_init = 1,
+ .no_invd_sharing = true,
+ },
+ .cache_info.l2_cache = {
+ .type = UNIFIED_CACHE,
+ .level = 2,
+ .size = 512 * KiB,
+ .line_size = 64,
+ .associativity = 8,
+ .partitions = 1,
+ .sets = 1024,
+ .lines_per_tag = 1,
+ },
+ .cache_info.l3_cache = {
+ .type = UNIFIED_CACHE,
+ .level = 3,
+ .size = 8 * MiB,
+ .line_size = 64,
+ .associativity = 16,
+ .partitions = 1,
+ .sets = 8192,
+ .lines_per_tag = 1,
+ .self_init = true,
+ .inclusive = true,
+ .complex_indexing = true,
+ },
},
{
.name = "EPYC-IBPB",
@@ -2348,6 +2396,54 @@ static X86CPUDefinition builtin_x86_defs[] = {
CPUID_6_EAX_ARAT,
.xlevel = 0x8000000A,
.model_id = "AMD EPYC Processor (with IBPB)",
+ .cache_info.valid = 1,
+ .cache_info.l1d_cache = {
+ .type = DCACHE,
+ .level = 1,
+ .size = 32 * KiB,
+ .line_size = 64,
+ .associativity = 8,
+ .partitions = 1,
+ .sets = 64,
+ .lines_per_tag = 1,
+ .self_init = 1,
+ .no_invd_sharing = true,
+ },
+ .cache_info.l1i_cache = {
+ .type = ICACHE,
+ .level = 1,
+ .size = 64 * KiB,
+ .line_size = 64,
+ .associativity = 4,
+ .partitions = 1,
+ .sets = 256,
+ .lines_per_tag = 1,
+ .self_init = 1,
+ .no_invd_sharing = true,
+ },
+ .cache_info.l2_cache = {
+ .type = UNIFIED_CACHE,
+ .level = 2,
+ .size = 512 * KiB,
+ .line_size = 64,
+ .associativity = 8,
+ .partitions = 1,
+ .sets = 1024,
+ .lines_per_tag = 1,
+ },
+ .cache_info.l3_cache = {
+ .type = UNIFIED_CACHE,
+ .level = 3,
+ .size = 8 * MiB,
+ .line_size = 64,
+ .associativity = 16,
+ .partitions = 1,
+ .sets = 8192,
+ .lines_per_tag = 1,
+ .self_init = true,
+ .inclusive = true,
+ .complex_indexing = true,
+ },
},
};
--
2.7.4
^ permalink raw reply related [flat|nested] 88+ messages in thread
* [PATCH v7 4/9] i386: Add new property to control cache info
2018-04-26 16:26 ` [Qemu-devel] " Babu Moger
@ 2018-04-26 16:26 ` Babu Moger
-1 siblings, 0 replies; 88+ messages in thread
From: Babu Moger @ 2018-04-26 16:26 UTC (permalink / raw)
To: mst, marcel, pbonzini, rth, ehabkost, mtosatti
Cc: geoff, babu.moger, kash, qemu-devel, kvm
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.
It will be "on" for machine type "pc-q35-2.10" for compatibility.
Signed-off-by: Babu Moger <babu.moger@amd.com>
Tested-by: Geoffrey McRae <geoff@hostfission.com>
---
include/hw/i386/pc.h | 4 ++++
target/i386/cpu.c | 1 +
target/i386/cpu.h | 5 +++++
3 files changed, 10 insertions(+)
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index ffee841..d904a3c 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -327,6 +327,10 @@ 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 = "on",\
},
#define PC_COMPAT_2_9 \
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 5d88363..a27b658 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -5138,6 +5138,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),
/*
* From "Requirements for Implementing the Microsoft
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 1213bb7..852586a 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -1395,6 +1395,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;
--
2.7.4
^ permalink raw reply related [flat|nested] 88+ messages in thread
* [Qemu-devel] [PATCH v7 4/9] i386: Add new property to control cache info
@ 2018-04-26 16:26 ` Babu Moger
0 siblings, 0 replies; 88+ messages in thread
From: Babu Moger @ 2018-04-26 16:26 UTC (permalink / raw)
To: mst, marcel, pbonzini, rth, ehabkost, mtosatti
Cc: qemu-devel, kvm, kash, geoff, babu.moger
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.
It will be "on" for machine type "pc-q35-2.10" for compatibility.
Signed-off-by: Babu Moger <babu.moger@amd.com>
Tested-by: Geoffrey McRae <geoff@hostfission.com>
---
include/hw/i386/pc.h | 4 ++++
target/i386/cpu.c | 1 +
target/i386/cpu.h | 5 +++++
3 files changed, 10 insertions(+)
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index ffee841..d904a3c 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -327,6 +327,10 @@ 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 = "on",\
},
#define PC_COMPAT_2_9 \
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 5d88363..a27b658 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -5138,6 +5138,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),
/*
* From "Requirements for Implementing the Microsoft
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 1213bb7..852586a 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -1395,6 +1395,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;
--
2.7.4
^ permalink raw reply related [flat|nested] 88+ messages in thread
* [PATCH v7 5/9] i386: Use the statically loaded cache definitions
2018-04-26 16:26 ` [Qemu-devel] " Babu Moger
@ 2018-04-26 16:26 ` Babu Moger
-1 siblings, 0 replies; 88+ messages in thread
From: Babu Moger @ 2018-04-26 16:26 UTC (permalink / raw)
To: mst, marcel, pbonzini, rth, ehabkost, mtosatti
Cc: geoff, babu.moger, kash, qemu-devel, kvm
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>
---
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
^ permalink raw reply related [flat|nested] 88+ messages in thread
* [Qemu-devel] [PATCH v7 5/9] i386: Use the statically loaded cache definitions
@ 2018-04-26 16:26 ` Babu Moger
0 siblings, 0 replies; 88+ messages in thread
From: Babu Moger @ 2018-04-26 16:26 UTC (permalink / raw)
To: mst, marcel, pbonzini, rth, ehabkost, mtosatti
Cc: qemu-devel, kvm, kash, geoff, babu.moger
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>
---
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
^ permalink raw reply related [flat|nested] 88+ messages in thread
* [PATCH v7 6/9] i386: Populate AMD Processor Cache Information for cpuid 0x8000001D
2018-04-26 16:26 ` [Qemu-devel] " Babu Moger
@ 2018-04-26 16:26 ` Babu Moger
-1 siblings, 0 replies; 88+ messages in thread
From: Babu Moger @ 2018-04-26 16:26 UTC (permalink / raw)
To: mst, marcel, pbonzini, rth, ehabkost, mtosatti
Cc: geoff, babu.moger, kash, qemu-devel, kvm
Add information for cpuid 0x8000001D leaf. Populate cache topology information
for different cache types(Data Cache, Instruction Cache, L2 and L3) supported
by 0x8000001D leaf. Please refer Processor Programming Reference (PPR) for AMD
Family 17h Model for more details.
Signed-off-by: Babu Moger <babu.moger@amd.com>
Tested-by: Geoffrey McRae <geoff@hostfission.com>
---
target/i386/cpu.c | 92 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
target/i386/kvm.c | 29 ++++++++++++++++--
2 files changed, 118 insertions(+), 3 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 56d2f0b..1024b09 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -307,6 +307,14 @@ static uint32_t encode_cache_cpuid80000005(CPUCacheInfo *cache)
a == ASSOC_FULL ? 0xF : \
0 /* invalid value */)
+/* Definitions used on CPUID Leaf 0x8000001D */
+/* Number of logical cores in a complex */
+#define CORES_IN_CMPLX 4
+/* Number of logical processors sharing cache */
+#define NUM_SHARING_CACHE(threads) (threads ? \
+ (((CORES_IN_CMPLX - 1) * 2) + 1) : \
+ (CORES_IN_CMPLX - 1))
+
/*
* Encode cache info for CPUID[0x80000006].ECX and CPUID[0x80000006].EDX
* @l3 can be NULL.
@@ -336,6 +344,41 @@ static void encode_cache_cpuid80000006(CPUCacheInfo *l2,
}
}
+/* Encode cache info for CPUID[8000001D] */
+static void encode_cache_cpuid8000001d(CPUCacheInfo *cache, int nr_threads,
+ uint32_t *eax, uint32_t *ebx,
+ uint32_t *ecx, uint32_t *edx)
+{
+ assert(cache->size == cache->line_size * cache->associativity *
+ cache->partitions * cache->sets);
+
+ *eax = CACHE_TYPE(cache->type) | CACHE_LEVEL(cache->level) |
+ (cache->self_init ? CACHE_SELF_INIT_LEVEL : 0);
+
+ /* L3 is shared among multiple cores */
+ if (cache->level == 3) {
+ *eax |= (NUM_SHARING_CACHE(nr_threads - 1) << 14);
+ } else {
+ *eax |= ((nr_threads - 1) << 14);
+ }
+
+ assert(cache->line_size > 0);
+ assert(cache->partitions > 0);
+ assert(cache->associativity > 0);
+ /* We don't implement fully-associative caches */
+ assert(cache->associativity < cache->sets);
+ *ebx = (cache->line_size - 1) |
+ ((cache->partitions - 1) << 12) |
+ ((cache->associativity - 1) << 22);
+
+ assert(cache->sets > 0);
+ *ecx = cache->sets - 1;
+
+ *edx = (cache->no_invd_sharing ? CACHE_NO_INVD_SHARING : 0) |
+ (cache->inclusive ? CACHE_INCLUSIVE : 0) |
+ (cache->complex_indexing ? CACHE_COMPLEX_IDX : 0);
+}
+
/* Definitions of the hardcoded cache entries we expose: */
/* L1 data cache: */
@@ -4013,6 +4056,55 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
*edx = 0;
}
break;
+ case 0x8000001D:
+ *eax = 0;
+ switch (count) {
+ case 0: /* L1 dcache info */
+ if (env->cache_info.valid && !cpu->legacy_cache) {
+ encode_cache_cpuid8000001d(&env->cache_info.l1d_cache,
+ cs->nr_threads,
+ eax, ebx, ecx, edx);
+ } else {
+ encode_cache_cpuid8000001d(&l1d_cache_amd, cs->nr_threads,
+ eax, ebx, ecx, edx);
+ }
+ break;
+ case 1: /* L1 icache info */
+ if (env->cache_info.valid && !cpu->legacy_cache) {
+ encode_cache_cpuid8000001d(&env->cache_info.l1i_cache,
+ cs->nr_threads,
+ eax, ebx, ecx, edx);
+ } else {
+ encode_cache_cpuid8000001d(&l1i_cache_amd,
+ cs->nr_threads,
+ eax, ebx, ecx, edx);
+ }
+ break;
+ case 2: /* L2 cache info */
+ if (env->cache_info.valid && !cpu->legacy_cache) {
+ encode_cache_cpuid8000001d(&env->cache_info.l2_cache,
+ cs->nr_threads,
+ eax, ebx, ecx, edx);
+ } else {
+ encode_cache_cpuid8000001d(&l2_cache_amd, cs->nr_threads,
+ eax, ebx, ecx, edx);
+ }
+ break;
+ case 3: /* L3 cache info */
+ if (env->cache_info.valid && !cpu->legacy_cache) {
+ encode_cache_cpuid8000001d(&env->cache_info.l3_cache,
+ cs->nr_threads,
+ eax, ebx, ecx, edx);
+ } else {
+ encode_cache_cpuid8000001d(&l3_cache, cs->nr_threads,
+ eax, ebx, ecx, edx);
+ }
+ break;
+ default: /* end of info */
+ *eax = *ebx = *ecx = *edx = 0;
+ break;
+ }
+ break;
case 0xC0000000:
*eax = env->cpuid_xlevel2;
*ebx = 0;
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index 6c49954..6e66f9c 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -967,9 +967,32 @@ int kvm_arch_init_vcpu(CPUState *cs)
}
c = &cpuid_data.entries[cpuid_i++];
- c->function = i;
- c->flags = 0;
- cpu_x86_cpuid(env, i, 0, &c->eax, &c->ebx, &c->ecx, &c->edx);
+ switch (i) {
+ case 0x8000001d:
+ /* Query for all AMD cache information leaves */
+ for (j = 0; ; j++) {
+ c->function = i;
+ c->flags = KVM_CPUID_FLAG_SIGNIFCANT_INDEX;
+ c->index = j;
+ cpu_x86_cpuid(env, i, j, &c->eax, &c->ebx, &c->ecx, &c->edx);
+
+ if (c->eax == 0) {
+ break;
+ }
+ if (cpuid_i == KVM_MAX_CPUID_ENTRIES) {
+ fprintf(stderr, "cpuid_data is full, no space for "
+ "cpuid(eax:0x%x,ecx:0x%x)\n", i, j);
+ abort();
+ }
+ c = &cpuid_data.entries[cpuid_i++];
+ }
+ break;
+ default:
+ c->function = i;
+ c->flags = 0;
+ cpu_x86_cpuid(env, i, 0, &c->eax, &c->ebx, &c->ecx, &c->edx);
+ break;
+ }
}
/* Call Centaur's CPUID instructions they are supported. */
--
2.7.4
^ permalink raw reply related [flat|nested] 88+ messages in thread
* [Qemu-devel] [PATCH v7 6/9] i386: Populate AMD Processor Cache Information for cpuid 0x8000001D
@ 2018-04-26 16:26 ` Babu Moger
0 siblings, 0 replies; 88+ messages in thread
From: Babu Moger @ 2018-04-26 16:26 UTC (permalink / raw)
To: mst, marcel, pbonzini, rth, ehabkost, mtosatti
Cc: qemu-devel, kvm, kash, geoff, babu.moger
Add information for cpuid 0x8000001D leaf. Populate cache topology information
for different cache types(Data Cache, Instruction Cache, L2 and L3) supported
by 0x8000001D leaf. Please refer Processor Programming Reference (PPR) for AMD
Family 17h Model for more details.
Signed-off-by: Babu Moger <babu.moger@amd.com>
Tested-by: Geoffrey McRae <geoff@hostfission.com>
---
target/i386/cpu.c | 92 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
target/i386/kvm.c | 29 ++++++++++++++++--
2 files changed, 118 insertions(+), 3 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 56d2f0b..1024b09 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -307,6 +307,14 @@ static uint32_t encode_cache_cpuid80000005(CPUCacheInfo *cache)
a == ASSOC_FULL ? 0xF : \
0 /* invalid value */)
+/* Definitions used on CPUID Leaf 0x8000001D */
+/* Number of logical cores in a complex */
+#define CORES_IN_CMPLX 4
+/* Number of logical processors sharing cache */
+#define NUM_SHARING_CACHE(threads) (threads ? \
+ (((CORES_IN_CMPLX - 1) * 2) + 1) : \
+ (CORES_IN_CMPLX - 1))
+
/*
* Encode cache info for CPUID[0x80000006].ECX and CPUID[0x80000006].EDX
* @l3 can be NULL.
@@ -336,6 +344,41 @@ static void encode_cache_cpuid80000006(CPUCacheInfo *l2,
}
}
+/* Encode cache info for CPUID[8000001D] */
+static void encode_cache_cpuid8000001d(CPUCacheInfo *cache, int nr_threads,
+ uint32_t *eax, uint32_t *ebx,
+ uint32_t *ecx, uint32_t *edx)
+{
+ assert(cache->size == cache->line_size * cache->associativity *
+ cache->partitions * cache->sets);
+
+ *eax = CACHE_TYPE(cache->type) | CACHE_LEVEL(cache->level) |
+ (cache->self_init ? CACHE_SELF_INIT_LEVEL : 0);
+
+ /* L3 is shared among multiple cores */
+ if (cache->level == 3) {
+ *eax |= (NUM_SHARING_CACHE(nr_threads - 1) << 14);
+ } else {
+ *eax |= ((nr_threads - 1) << 14);
+ }
+
+ assert(cache->line_size > 0);
+ assert(cache->partitions > 0);
+ assert(cache->associativity > 0);
+ /* We don't implement fully-associative caches */
+ assert(cache->associativity < cache->sets);
+ *ebx = (cache->line_size - 1) |
+ ((cache->partitions - 1) << 12) |
+ ((cache->associativity - 1) << 22);
+
+ assert(cache->sets > 0);
+ *ecx = cache->sets - 1;
+
+ *edx = (cache->no_invd_sharing ? CACHE_NO_INVD_SHARING : 0) |
+ (cache->inclusive ? CACHE_INCLUSIVE : 0) |
+ (cache->complex_indexing ? CACHE_COMPLEX_IDX : 0);
+}
+
/* Definitions of the hardcoded cache entries we expose: */
/* L1 data cache: */
@@ -4013,6 +4056,55 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
*edx = 0;
}
break;
+ case 0x8000001D:
+ *eax = 0;
+ switch (count) {
+ case 0: /* L1 dcache info */
+ if (env->cache_info.valid && !cpu->legacy_cache) {
+ encode_cache_cpuid8000001d(&env->cache_info.l1d_cache,
+ cs->nr_threads,
+ eax, ebx, ecx, edx);
+ } else {
+ encode_cache_cpuid8000001d(&l1d_cache_amd, cs->nr_threads,
+ eax, ebx, ecx, edx);
+ }
+ break;
+ case 1: /* L1 icache info */
+ if (env->cache_info.valid && !cpu->legacy_cache) {
+ encode_cache_cpuid8000001d(&env->cache_info.l1i_cache,
+ cs->nr_threads,
+ eax, ebx, ecx, edx);
+ } else {
+ encode_cache_cpuid8000001d(&l1i_cache_amd,
+ cs->nr_threads,
+ eax, ebx, ecx, edx);
+ }
+ break;
+ case 2: /* L2 cache info */
+ if (env->cache_info.valid && !cpu->legacy_cache) {
+ encode_cache_cpuid8000001d(&env->cache_info.l2_cache,
+ cs->nr_threads,
+ eax, ebx, ecx, edx);
+ } else {
+ encode_cache_cpuid8000001d(&l2_cache_amd, cs->nr_threads,
+ eax, ebx, ecx, edx);
+ }
+ break;
+ case 3: /* L3 cache info */
+ if (env->cache_info.valid && !cpu->legacy_cache) {
+ encode_cache_cpuid8000001d(&env->cache_info.l3_cache,
+ cs->nr_threads,
+ eax, ebx, ecx, edx);
+ } else {
+ encode_cache_cpuid8000001d(&l3_cache, cs->nr_threads,
+ eax, ebx, ecx, edx);
+ }
+ break;
+ default: /* end of info */
+ *eax = *ebx = *ecx = *edx = 0;
+ break;
+ }
+ break;
case 0xC0000000:
*eax = env->cpuid_xlevel2;
*ebx = 0;
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index 6c49954..6e66f9c 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -967,9 +967,32 @@ int kvm_arch_init_vcpu(CPUState *cs)
}
c = &cpuid_data.entries[cpuid_i++];
- c->function = i;
- c->flags = 0;
- cpu_x86_cpuid(env, i, 0, &c->eax, &c->ebx, &c->ecx, &c->edx);
+ switch (i) {
+ case 0x8000001d:
+ /* Query for all AMD cache information leaves */
+ for (j = 0; ; j++) {
+ c->function = i;
+ c->flags = KVM_CPUID_FLAG_SIGNIFCANT_INDEX;
+ c->index = j;
+ cpu_x86_cpuid(env, i, j, &c->eax, &c->ebx, &c->ecx, &c->edx);
+
+ if (c->eax == 0) {
+ break;
+ }
+ if (cpuid_i == KVM_MAX_CPUID_ENTRIES) {
+ fprintf(stderr, "cpuid_data is full, no space for "
+ "cpuid(eax:0x%x,ecx:0x%x)\n", i, j);
+ abort();
+ }
+ c = &cpuid_data.entries[cpuid_i++];
+ }
+ break;
+ default:
+ c->function = i;
+ c->flags = 0;
+ cpu_x86_cpuid(env, i, 0, &c->eax, &c->ebx, &c->ecx, &c->edx);
+ break;
+ }
}
/* Call Centaur's CPUID instructions they are supported. */
--
2.7.4
^ permalink raw reply related [flat|nested] 88+ messages in thread
* [PATCH v7 7/9] i386: Add support for CPUID_8000_001E for AMD
2018-04-26 16:26 ` [Qemu-devel] " Babu Moger
@ 2018-04-26 16:26 ` Babu Moger
-1 siblings, 0 replies; 88+ messages in thread
From: Babu Moger @ 2018-04-26 16:26 UTC (permalink / raw)
To: mst, marcel, pbonzini, rth, ehabkost, mtosatti
Cc: geoff, babu.moger, kash, qemu-devel, kvm
Populate threads/core_id/apic_ids/socket_id when CPUID_EXT3_TOPOEXT
feature is supported. This is required to support hyperthreading feature
on AMD CPUs. This is supported via CPUID_8000_001E extended functions.
Signed-off-by: Babu Moger <babu.moger@amd.com>
Tested-by: Geoffrey McRae <geoff@hostfission.com>
---
target/i386/cpu.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 1024b09..1b15023 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -315,6 +315,12 @@ static uint32_t encode_cache_cpuid80000005(CPUCacheInfo *cache)
(((CORES_IN_CMPLX - 1) * 2) + 1) : \
(CORES_IN_CMPLX - 1))
+/* Definitions used on CPUID Leaf 0x8000001E */
+#define EXTENDED_APIC_ID(threads, socket_id, core_id, thread_id) \
+ ((threads) ? \
+ ((socket_id << 6) | (core_id << 1) | thread_id) : \
+ ((socket_id << 6) | core_id))
+
/*
* Encode cache info for CPUID[0x80000006].ECX and CPUID[0x80000006].EDX
* @l3 can be NULL.
@@ -4105,6 +4111,14 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
break;
}
break;
+ case 0x8000001E:
+ assert(cpu->core_id <= 255);
+ *eax = EXTENDED_APIC_ID((cs->nr_threads - 1),
+ cpu->socket_id, cpu->core_id, cpu->thread_id);
+ *ebx = (cs->nr_threads - 1) << 8 | cpu->core_id;
+ *ecx = cpu->socket_id;
+ *edx = 0;
+ break;
case 0xC0000000:
*eax = env->cpuid_xlevel2;
*ebx = 0;
--
2.7.4
^ permalink raw reply related [flat|nested] 88+ messages in thread
* [Qemu-devel] [PATCH v7 7/9] i386: Add support for CPUID_8000_001E for AMD
@ 2018-04-26 16:26 ` Babu Moger
0 siblings, 0 replies; 88+ messages in thread
From: Babu Moger @ 2018-04-26 16:26 UTC (permalink / raw)
To: mst, marcel, pbonzini, rth, ehabkost, mtosatti
Cc: qemu-devel, kvm, kash, geoff, babu.moger
Populate threads/core_id/apic_ids/socket_id when CPUID_EXT3_TOPOEXT
feature is supported. This is required to support hyperthreading feature
on AMD CPUs. This is supported via CPUID_8000_001E extended functions.
Signed-off-by: Babu Moger <babu.moger@amd.com>
Tested-by: Geoffrey McRae <geoff@hostfission.com>
---
target/i386/cpu.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 1024b09..1b15023 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -315,6 +315,12 @@ static uint32_t encode_cache_cpuid80000005(CPUCacheInfo *cache)
(((CORES_IN_CMPLX - 1) * 2) + 1) : \
(CORES_IN_CMPLX - 1))
+/* Definitions used on CPUID Leaf 0x8000001E */
+#define EXTENDED_APIC_ID(threads, socket_id, core_id, thread_id) \
+ ((threads) ? \
+ ((socket_id << 6) | (core_id << 1) | thread_id) : \
+ ((socket_id << 6) | core_id))
+
/*
* Encode cache info for CPUID[0x80000006].ECX and CPUID[0x80000006].EDX
* @l3 can be NULL.
@@ -4105,6 +4111,14 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
break;
}
break;
+ case 0x8000001E:
+ assert(cpu->core_id <= 255);
+ *eax = EXTENDED_APIC_ID((cs->nr_threads - 1),
+ cpu->socket_id, cpu->core_id, cpu->thread_id);
+ *ebx = (cs->nr_threads - 1) << 8 | cpu->core_id;
+ *ecx = cpu->socket_id;
+ *edx = 0;
+ break;
case 0xC0000000:
*eax = env->cpuid_xlevel2;
*ebx = 0;
--
2.7.4
^ permalink raw reply related [flat|nested] 88+ messages in thread
* [PATCH v7 8/9] i386: Enable TOPOEXT feature on AMD EPYC CPU
2018-04-26 16:26 ` [Qemu-devel] " Babu Moger
@ 2018-04-26 16:26 ` Babu Moger
-1 siblings, 0 replies; 88+ messages in thread
From: Babu Moger @ 2018-04-26 16:26 UTC (permalink / raw)
To: mst, marcel, pbonzini, rth, ehabkost, mtosatti
Cc: geoff, babu.moger, kash, qemu-devel, kvm
Enable TOPOEXT feature on EPYC CPU. This is required to support
hyperthreading on VM guests. Also extend xlevel to 0x8000001E.
Signed-off-by: Babu Moger <babu.moger@amd.com>
Tested-by: Geoffrey McRae <geoff@hostfission.com>
---
target/i386/cpu.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 1b15023..6ebbef2 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -2334,7 +2334,8 @@ static X86CPUDefinition builtin_x86_defs[] = {
.features[FEAT_8000_0001_ECX] =
CPUID_EXT3_OSVW | CPUID_EXT3_3DNOWPREFETCH |
CPUID_EXT3_MISALIGNSSE | CPUID_EXT3_SSE4A | CPUID_EXT3_ABM |
- CPUID_EXT3_CR8LEG | CPUID_EXT3_SVM | CPUID_EXT3_LAHF_LM,
+ CPUID_EXT3_CR8LEG | CPUID_EXT3_SVM | CPUID_EXT3_LAHF_LM |
+ CPUID_EXT3_TOPOEXT,
.features[FEAT_7_0_EBX] =
CPUID_7_0_EBX_FSGSBASE | CPUID_7_0_EBX_BMI1 | CPUID_7_0_EBX_AVX2 |
CPUID_7_0_EBX_SMEP | CPUID_7_0_EBX_BMI2 | CPUID_7_0_EBX_RDSEED |
@@ -2426,7 +2427,8 @@ static X86CPUDefinition builtin_x86_defs[] = {
.features[FEAT_8000_0001_ECX] =
CPUID_EXT3_OSVW | CPUID_EXT3_3DNOWPREFETCH |
CPUID_EXT3_MISALIGNSSE | CPUID_EXT3_SSE4A | CPUID_EXT3_ABM |
- CPUID_EXT3_CR8LEG | CPUID_EXT3_SVM | CPUID_EXT3_LAHF_LM,
+ CPUID_EXT3_CR8LEG | CPUID_EXT3_SVM | CPUID_EXT3_LAHF_LM |
+ CPUID_EXT3_TOPOEXT,
.features[FEAT_8000_0008_EBX] =
CPUID_8000_0008_EBX_IBPB,
.features[FEAT_7_0_EBX] =
@@ -4580,6 +4582,11 @@ static void x86_cpu_expand_features(X86CPU *cpu, Error **errp)
x86_cpu_adjust_level(cpu, &env->cpuid_min_xlevel, 0x8000000A);
}
+ /* TOPOEXT feature requires 0x8000001E */
+ if (env->features[FEAT_8000_0001_ECX] & CPUID_EXT3_TOPOEXT) {
+ x86_cpu_adjust_level(cpu, &env->cpuid_min_xlevel, 0x8000001E);
+ }
+
/* SEV requires CPUID[0x8000001F] */
if (sev_enabled()) {
x86_cpu_adjust_level(cpu, &env->cpuid_min_xlevel, 0x8000001F);
--
2.7.4
^ permalink raw reply related [flat|nested] 88+ messages in thread
* [Qemu-devel] [PATCH v7 8/9] i386: Enable TOPOEXT feature on AMD EPYC CPU
@ 2018-04-26 16:26 ` Babu Moger
0 siblings, 0 replies; 88+ messages in thread
From: Babu Moger @ 2018-04-26 16:26 UTC (permalink / raw)
To: mst, marcel, pbonzini, rth, ehabkost, mtosatti
Cc: qemu-devel, kvm, kash, geoff, babu.moger
Enable TOPOEXT feature on EPYC CPU. This is required to support
hyperthreading on VM guests. Also extend xlevel to 0x8000001E.
Signed-off-by: Babu Moger <babu.moger@amd.com>
Tested-by: Geoffrey McRae <geoff@hostfission.com>
---
target/i386/cpu.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 1b15023..6ebbef2 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -2334,7 +2334,8 @@ static X86CPUDefinition builtin_x86_defs[] = {
.features[FEAT_8000_0001_ECX] =
CPUID_EXT3_OSVW | CPUID_EXT3_3DNOWPREFETCH |
CPUID_EXT3_MISALIGNSSE | CPUID_EXT3_SSE4A | CPUID_EXT3_ABM |
- CPUID_EXT3_CR8LEG | CPUID_EXT3_SVM | CPUID_EXT3_LAHF_LM,
+ CPUID_EXT3_CR8LEG | CPUID_EXT3_SVM | CPUID_EXT3_LAHF_LM |
+ CPUID_EXT3_TOPOEXT,
.features[FEAT_7_0_EBX] =
CPUID_7_0_EBX_FSGSBASE | CPUID_7_0_EBX_BMI1 | CPUID_7_0_EBX_AVX2 |
CPUID_7_0_EBX_SMEP | CPUID_7_0_EBX_BMI2 | CPUID_7_0_EBX_RDSEED |
@@ -2426,7 +2427,8 @@ static X86CPUDefinition builtin_x86_defs[] = {
.features[FEAT_8000_0001_ECX] =
CPUID_EXT3_OSVW | CPUID_EXT3_3DNOWPREFETCH |
CPUID_EXT3_MISALIGNSSE | CPUID_EXT3_SSE4A | CPUID_EXT3_ABM |
- CPUID_EXT3_CR8LEG | CPUID_EXT3_SVM | CPUID_EXT3_LAHF_LM,
+ CPUID_EXT3_CR8LEG | CPUID_EXT3_SVM | CPUID_EXT3_LAHF_LM |
+ CPUID_EXT3_TOPOEXT,
.features[FEAT_8000_0008_EBX] =
CPUID_8000_0008_EBX_IBPB,
.features[FEAT_7_0_EBX] =
@@ -4580,6 +4582,11 @@ static void x86_cpu_expand_features(X86CPU *cpu, Error **errp)
x86_cpu_adjust_level(cpu, &env->cpuid_min_xlevel, 0x8000000A);
}
+ /* TOPOEXT feature requires 0x8000001E */
+ if (env->features[FEAT_8000_0001_ECX] & CPUID_EXT3_TOPOEXT) {
+ x86_cpu_adjust_level(cpu, &env->cpuid_min_xlevel, 0x8000001E);
+ }
+
/* SEV requires CPUID[0x8000001F] */
if (sev_enabled()) {
x86_cpu_adjust_level(cpu, &env->cpuid_min_xlevel, 0x8000001F);
--
2.7.4
^ permalink raw reply related [flat|nested] 88+ messages in thread
* [PATCH v7 9/9] i386: Remove generic SMT thread check
2018-04-26 16:26 ` [Qemu-devel] " Babu Moger
@ 2018-04-26 16:26 ` Babu Moger
-1 siblings, 0 replies; 88+ messages in thread
From: Babu Moger @ 2018-04-26 16:26 UTC (permalink / raw)
To: mst, marcel, pbonzini, rth, ehabkost, mtosatti
Cc: geoff, babu.moger, kash, qemu-devel, kvm
Remove generic non-intel check while validating hyperthreading support.
Certain AMD CPUs can support hyperthreading now.
CPU family with TOPOEXT feature can support hyperthreading now.
Signed-off-by: Babu Moger <babu.moger@amd.com>
Tested-by: Geoffrey McRae <geoff@hostfission.com>
---
target/i386/cpu.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 6ebbef2..54d908f 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -4830,17 +4830,20 @@ static void x86_cpu_realizefn(DeviceState *dev, Error **errp)
qemu_init_vcpu(cs);
- /* Only Intel CPUs support hyperthreading. Even though QEMU fixes this
- * issue by adjusting CPUID_0000_0001_EBX and CPUID_8000_0008_ECX
- * based on inputs (sockets,cores,threads), it is still better to gives
+ /* Most Intel and certain AMD CPUs support hyperthreading. Even though QEMU
+ * fixes this issue by adjusting CPUID_0000_0001_EBX and CPUID_8000_0008_ECX
+ * based on inputs (sockets,cores,threads), it is still better to give
* users a warning.
*
* NOTE: the following code has to follow qemu_init_vcpu(). Otherwise
* cs->nr_threads hasn't be populated yet and the checking is incorrect.
*/
- if (!IS_INTEL_CPU(env) && cs->nr_threads > 1 && !ht_warned) {
- error_report("AMD CPU doesn't support hyperthreading. Please configure"
- " -smp options properly.");
+ if (IS_AMD_CPU(env) &&
+ !(env->features[FEAT_8000_0001_ECX] & CPUID_EXT3_TOPOEXT) &&
+ cs->nr_threads > 1 && !ht_warned) {
+ error_report("This family of AMD CPU doesn't support "
+ "hyperthreading. Please configure -smp "
+ "options properly.");
ht_warned = true;
}
--
2.7.4
^ permalink raw reply related [flat|nested] 88+ messages in thread
* [Qemu-devel] [PATCH v7 9/9] i386: Remove generic SMT thread check
@ 2018-04-26 16:26 ` Babu Moger
0 siblings, 0 replies; 88+ messages in thread
From: Babu Moger @ 2018-04-26 16:26 UTC (permalink / raw)
To: mst, marcel, pbonzini, rth, ehabkost, mtosatti
Cc: qemu-devel, kvm, kash, geoff, babu.moger
Remove generic non-intel check while validating hyperthreading support.
Certain AMD CPUs can support hyperthreading now.
CPU family with TOPOEXT feature can support hyperthreading now.
Signed-off-by: Babu Moger <babu.moger@amd.com>
Tested-by: Geoffrey McRae <geoff@hostfission.com>
---
target/i386/cpu.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 6ebbef2..54d908f 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -4830,17 +4830,20 @@ static void x86_cpu_realizefn(DeviceState *dev, Error **errp)
qemu_init_vcpu(cs);
- /* Only Intel CPUs support hyperthreading. Even though QEMU fixes this
- * issue by adjusting CPUID_0000_0001_EBX and CPUID_8000_0008_ECX
- * based on inputs (sockets,cores,threads), it is still better to gives
+ /* Most Intel and certain AMD CPUs support hyperthreading. Even though QEMU
+ * fixes this issue by adjusting CPUID_0000_0001_EBX and CPUID_8000_0008_ECX
+ * based on inputs (sockets,cores,threads), it is still better to give
* users a warning.
*
* NOTE: the following code has to follow qemu_init_vcpu(). Otherwise
* cs->nr_threads hasn't be populated yet and the checking is incorrect.
*/
- if (!IS_INTEL_CPU(env) && cs->nr_threads > 1 && !ht_warned) {
- error_report("AMD CPU doesn't support hyperthreading. Please configure"
- " -smp options properly.");
+ if (IS_AMD_CPU(env) &&
+ !(env->features[FEAT_8000_0001_ECX] & CPUID_EXT3_TOPOEXT) &&
+ cs->nr_threads > 1 && !ht_warned) {
+ error_report("This family of AMD CPU doesn't support "
+ "hyperthreading. Please configure -smp "
+ "options properly.");
ht_warned = true;
}
--
2.7.4
^ permalink raw reply related [flat|nested] 88+ messages in thread
* Re: [PATCH v7 0/9] i386: Enable TOPOEXT to support hyperthreading on AMD CPU
2018-04-26 16:26 ` [Qemu-devel] " Babu Moger
@ 2018-04-26 20:49 ` geoff
-1 siblings, 0 replies; 88+ messages in thread
From: geoff--- via Qemu-devel @ 2018-04-26 20:49 UTC (permalink / raw)
To: Babu Moger
Cc: ehabkost, kvm, mst, kash, mtosatti, qemu-devel, marcel, pbonzini, rth
Works well for me, thanks!
Tested-by: Geoffrey McRae <geoff@hostfission.com>
On 2018-04-27 02:26, Babu Moger wrote:
> This series enables the TOPOEXT feature for AMD CPUs. This is required
> to
> support hyperthreading on kvm guests.
>
> This addresses the issues reported in these bugs:
> https://bugzilla.redhat.com/show_bug.cgi?id=1481253
> https://bugs.launchpad.net/qemu/+bug/1703506
>
> v7:
> Rebased on top of latest tree after 2.12 release and done few basic
> tests. There are
> no changes except for few minor hunks. Hopefully this gets pulled
> into 2.13 release.
> Please review, let me know of any feedback.
>
> v6:
> 1.Fixed problem with patch#4(Add new property to control cache info).
> The parameter
> legacy_cache should be "on" by default on machine type "pc-q35-2.10".
> This was
> found by Alexandr Iarygin.
> 2.Fixed the l3 cache size for EPYC based machines(patch#3). Also,
> fixed the number of
> logical processors sharing the cache(patch#6). Only L3 cache is
> shared by multiple
> cores but not L1 or L2. This was a bug while decoding. This was found
> by Geoffrey McRae
> and he verified the fix.
>
> v5:
> In this series I tried to address the feedback from Eduardo Habkost.
> The discussion thread is here.
> https://patchwork.kernel.org/patch/10299745/
> The previous thread is here.
> http://patchwork.ozlabs.org/cover/884885/
>
> Reason for these changes.
> The cache properties for AMD family of processors have changed from
> previous releases. We don't want to display the new information on the
> old family of processors as this might cause compatibility issues.
>
> Changes:
> 1.Based the patches on top of Eduardo's(patch#1) patch.
> Changed few things.
> Moved the Cache definitions to cpu.h file.
> Changed the CPUID_4 names to generic names.
> 2.Added a new propery "legacy-cache" in cpu object(patch#2). This can
> be
> used to display the old property even if the host supports the new
> cache
> properties.
> 3.Added cache information in X86CPUDefinition and CPUX86State
> 4.Patch 6-7 changed quite a bit from previous version does to new
> approach.
> 5.Addressed few issues with CPUID_8000_001d and CPUID_8000_001E.
>
> v4:
> 1.Removed the checks under cpuid 0x8000001D leaf(patch #2). These check
> are
> not necessary. Found this during internal review.
> 2.Added CPUID_EXT3_TOPOEXT feature for all the 17 family(patch #4).
> This was
> found by Kash Pande during his testing.
> 3.Removed th hardcoded cpuid xlevel and dynamically extended if
> CPUID_EXT3_TOPOEXT
> is supported(Suggested by Brijesh Singh).
>
> v3:
> 1.Removed the patch #1. Radim mentioned that original typo problem is
> in
> linux kernel header. qemu is just copying those files.
> 2.In previous version, I used the cpuid 4 definitions for AMDs cpuid
> leaf
> 0x8000001D. CPUID 4 is very intel specific and we dont want to expose
> those
> details under AMD. I have renamed some of these definitions as
> generic.
> These changes are in patch#1. Radim, let me know if this is what you
> intended.
> 3.Added assert to for core_id(Suggested by Radim Krčmář).
> 4.Changed the if condition under "L3 cache info"(Suggested by Gary
> Hook).
> 5.Addressed few more text correction and code cleanup(Suggested by
> Thomas Lendacky).
>
> v2:
> Fixed few more minor issues per Gary Hook's comments. Thank you Gary.
> Removed the patch#1. We need to handle the instruction cache
> associativity
> seperately. It varies based on the cpu family. I will comeback to
> that later.
> Added two more typo corrections in patch#1 and patch#5.
>
> v1:
> Stanislav Lanci posted few patches earlier.
> https://patchwork.kernel.org/patch/10040903/
>
> Rebased his patches with few changes.
> 1.Spit the patches into two, separating cpuid functions
> 0x8000001D and 0x8000001E (Patch 2 and 3).
> 2.Removed the generic non-intel check and made a separate patch
> with some changes(Patch 5).
> 3.Fixed L3_N_SETS_AMD(from 4096 to 8192) based on
> CPUID_Fn8000001D_ECX_x03.
>
> Added 2 more patches.
> Patch 1. Fixes cache associativity.
> Patch 4. Adds TOPOEXT feature on AMD EPYC CPU.
>
>
> Babu Moger (8):
> i386: Add cache information in X86CPUDefinition
> i386: Initialize cache information for EPYC family processors
> i386: Add new property to control cache info
> i386: Use the statically loaded cache definitions
> i386: Populate AMD Processor Cache Information for cpuid 0x8000001D
> i386: Add support for CPUID_8000_001E for AMD
> i386: Enable TOPOEXT feature on AMD EPYC CPU
> i386: Remove generic SMT thread check
>
> Eduardo Habkost (1):
> i386: Helpers to encode cache information consistently
>
> include/hw/i386/pc.h | 4 +
> target/i386/cpu.c | 736
> ++++++++++++++++++++++++++++++++++++++++++---------
> target/i386/cpu.h | 66 +++++
> target/i386/kvm.c | 29 +-
> 4 files changed, 702 insertions(+), 133 deletions(-)
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [Qemu-devel] [PATCH v7 0/9] i386: Enable TOPOEXT to support hyperthreading on AMD CPU
@ 2018-04-26 20:49 ` geoff
0 siblings, 0 replies; 88+ messages in thread
From: geoff @ 2018-04-26 20:49 UTC (permalink / raw)
To: Babu Moger
Cc: mst, marcel, pbonzini, rth, ehabkost, mtosatti, qemu-devel, kvm, kash
Works well for me, thanks!
Tested-by: Geoffrey McRae <geoff@hostfission.com>
On 2018-04-27 02:26, Babu Moger wrote:
> This series enables the TOPOEXT feature for AMD CPUs. This is required
> to
> support hyperthreading on kvm guests.
>
> This addresses the issues reported in these bugs:
> https://bugzilla.redhat.com/show_bug.cgi?id=1481253
> https://bugs.launchpad.net/qemu/+bug/1703506
>
> v7:
> Rebased on top of latest tree after 2.12 release and done few basic
> tests. There are
> no changes except for few minor hunks. Hopefully this gets pulled
> into 2.13 release.
> Please review, let me know of any feedback.
>
> v6:
> 1.Fixed problem with patch#4(Add new property to control cache info).
> The parameter
> legacy_cache should be "on" by default on machine type "pc-q35-2.10".
> This was
> found by Alexandr Iarygin.
> 2.Fixed the l3 cache size for EPYC based machines(patch#3). Also,
> fixed the number of
> logical processors sharing the cache(patch#6). Only L3 cache is
> shared by multiple
> cores but not L1 or L2. This was a bug while decoding. This was found
> by Geoffrey McRae
> and he verified the fix.
>
> v5:
> In this series I tried to address the feedback from Eduardo Habkost.
> The discussion thread is here.
> https://patchwork.kernel.org/patch/10299745/
> The previous thread is here.
> http://patchwork.ozlabs.org/cover/884885/
>
> Reason for these changes.
> The cache properties for AMD family of processors have changed from
> previous releases. We don't want to display the new information on the
> old family of processors as this might cause compatibility issues.
>
> Changes:
> 1.Based the patches on top of Eduardo's(patch#1) patch.
> Changed few things.
> Moved the Cache definitions to cpu.h file.
> Changed the CPUID_4 names to generic names.
> 2.Added a new propery "legacy-cache" in cpu object(patch#2). This can
> be
> used to display the old property even if the host supports the new
> cache
> properties.
> 3.Added cache information in X86CPUDefinition and CPUX86State
> 4.Patch 6-7 changed quite a bit from previous version does to new
> approach.
> 5.Addressed few issues with CPUID_8000_001d and CPUID_8000_001E.
>
> v4:
> 1.Removed the checks under cpuid 0x8000001D leaf(patch #2). These check
> are
> not necessary. Found this during internal review.
> 2.Added CPUID_EXT3_TOPOEXT feature for all the 17 family(patch #4).
> This was
> found by Kash Pande during his testing.
> 3.Removed th hardcoded cpuid xlevel and dynamically extended if
> CPUID_EXT3_TOPOEXT
> is supported(Suggested by Brijesh Singh).
>
> v3:
> 1.Removed the patch #1. Radim mentioned that original typo problem is
> in
> linux kernel header. qemu is just copying those files.
> 2.In previous version, I used the cpuid 4 definitions for AMDs cpuid
> leaf
> 0x8000001D. CPUID 4 is very intel specific and we dont want to expose
> those
> details under AMD. I have renamed some of these definitions as
> generic.
> These changes are in patch#1. Radim, let me know if this is what you
> intended.
> 3.Added assert to for core_id(Suggested by Radim Krčmář).
> 4.Changed the if condition under "L3 cache info"(Suggested by Gary
> Hook).
> 5.Addressed few more text correction and code cleanup(Suggested by
> Thomas Lendacky).
>
> v2:
> Fixed few more minor issues per Gary Hook's comments. Thank you Gary.
> Removed the patch#1. We need to handle the instruction cache
> associativity
> seperately. It varies based on the cpu family. I will comeback to
> that later.
> Added two more typo corrections in patch#1 and patch#5.
>
> v1:
> Stanislav Lanci posted few patches earlier.
> https://patchwork.kernel.org/patch/10040903/
>
> Rebased his patches with few changes.
> 1.Spit the patches into two, separating cpuid functions
> 0x8000001D and 0x8000001E (Patch 2 and 3).
> 2.Removed the generic non-intel check and made a separate patch
> with some changes(Patch 5).
> 3.Fixed L3_N_SETS_AMD(from 4096 to 8192) based on
> CPUID_Fn8000001D_ECX_x03.
>
> Added 2 more patches.
> Patch 1. Fixes cache associativity.
> Patch 4. Adds TOPOEXT feature on AMD EPYC CPU.
>
>
> Babu Moger (8):
> i386: Add cache information in X86CPUDefinition
> i386: Initialize cache information for EPYC family processors
> i386: Add new property to control cache info
> i386: Use the statically loaded cache definitions
> i386: Populate AMD Processor Cache Information for cpuid 0x8000001D
> i386: Add support for CPUID_8000_001E for AMD
> i386: Enable TOPOEXT feature on AMD EPYC CPU
> i386: Remove generic SMT thread check
>
> Eduardo Habkost (1):
> i386: Helpers to encode cache information consistently
>
> include/hw/i386/pc.h | 4 +
> target/i386/cpu.c | 736
> ++++++++++++++++++++++++++++++++++++++++++---------
> target/i386/cpu.h | 66 +++++
> target/i386/kvm.c | 29 +-
> 4 files changed, 702 insertions(+), 133 deletions(-)
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH v7 1/9] i386: Helpers to encode cache information consistently
2018-04-26 16:26 ` [Qemu-devel] " Babu Moger
@ 2018-05-07 19:05 ` Eduardo Habkost
-1 siblings, 0 replies; 88+ messages in thread
From: Eduardo Habkost @ 2018-05-07 19:05 UTC (permalink / raw)
To: Babu Moger
Cc: geoff, kvm, mst, kash, mtosatti, qemu-devel, marcel, pbonzini, rth
Hi,
I was about to apply this because I assumed it was the same patch
I sent in March, but then I found this:
On Thu, Apr 26, 2018 at 11:26:41AM -0500, Babu Moger wrote:
> From: Eduardo Habkost <ehabkost@redhat.com>
>
> Instead of having a collection of macros that need to be used in
> complex expressions to build CPUID data, define a CPUCacheInfo
> struct that can hold information about a given cache. Helper
> functions will take a CPUCacheInfo struct as input to encode
> CPUID leaves for a cache.
>
> This will help us ensure consistency between cache information
> CPUID leaves, and make the existing inconsistencies in CPUID info
> more visible.
>
> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> Signed-off-by: Babu Moger <babu.moger@amd.com>
> Tested-by: Geoffrey McRae <geoff@hostfission.com>
[...]
> -#define L2_ASSOCIATIVITY 16
[...]
> /*FIXME: CPUID leaf 0x80000006 is inconsistent with leaves 2 & 4 */
> +static CPUCacheInfo l2_cache_amd = {
[...]
> + .associativity = 8,
[...]
> +};
[...]
> case 0x80000006:
[...]
> - *ecx = (L2_SIZE_KB_AMD << 16) | \
> - (AMD_ENC_ASSOC(L2_ASSOCIATIVITY) << 12) | \
> - (L2_LINES_PER_TAG << 8) | (L2_LINE_SIZE);
[...]
> + encode_cache_cpuid80000006(&l2_cache_amd,
> + cpu->enable_l3_cache ? &l3_cache : NULL,
> + ecx, edx);
[...]
The structs added by this patch are supposed to represent the
legacy cache sizes, and must match the old code. My original
patch set l2_cache_amd.associativity=16 because of that.
This patch changes 0x80000006 from associativity=16 to
associativity=8. Why?
--
Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [Qemu-devel] [PATCH v7 1/9] i386: Helpers to encode cache information consistently
@ 2018-05-07 19:05 ` Eduardo Habkost
0 siblings, 0 replies; 88+ messages in thread
From: Eduardo Habkost @ 2018-05-07 19:05 UTC (permalink / raw)
To: Babu Moger
Cc: mst, marcel, pbonzini, rth, mtosatti, geoff, kash, qemu-devel, kvm
Hi,
I was about to apply this because I assumed it was the same patch
I sent in March, but then I found this:
On Thu, Apr 26, 2018 at 11:26:41AM -0500, Babu Moger wrote:
> From: Eduardo Habkost <ehabkost@redhat.com>
>
> Instead of having a collection of macros that need to be used in
> complex expressions to build CPUID data, define a CPUCacheInfo
> struct that can hold information about a given cache. Helper
> functions will take a CPUCacheInfo struct as input to encode
> CPUID leaves for a cache.
>
> This will help us ensure consistency between cache information
> CPUID leaves, and make the existing inconsistencies in CPUID info
> more visible.
>
> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> Signed-off-by: Babu Moger <babu.moger@amd.com>
> Tested-by: Geoffrey McRae <geoff@hostfission.com>
[...]
> -#define L2_ASSOCIATIVITY 16
[...]
> /*FIXME: CPUID leaf 0x80000006 is inconsistent with leaves 2 & 4 */
> +static CPUCacheInfo l2_cache_amd = {
[...]
> + .associativity = 8,
[...]
> +};
[...]
> case 0x80000006:
[...]
> - *ecx = (L2_SIZE_KB_AMD << 16) | \
> - (AMD_ENC_ASSOC(L2_ASSOCIATIVITY) << 12) | \
> - (L2_LINES_PER_TAG << 8) | (L2_LINE_SIZE);
[...]
> + encode_cache_cpuid80000006(&l2_cache_amd,
> + cpu->enable_l3_cache ? &l3_cache : NULL,
> + ecx, edx);
[...]
The structs added by this patch are supposed to represent the
legacy cache sizes, and must match the old code. My original
patch set l2_cache_amd.associativity=16 because of that.
This patch changes 0x80000006 from associativity=16 to
associativity=8. Why?
--
Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH v7 2/9] i386: Add cache information in X86CPUDefinition
2018-04-26 16:26 ` [Qemu-devel] " Babu Moger
@ 2018-05-07 19:09 ` Eduardo Habkost
-1 siblings, 0 replies; 88+ messages in thread
From: Eduardo Habkost @ 2018-05-07 19:09 UTC (permalink / raw)
To: Babu Moger
Cc: geoff, kvm, mst, kash, mtosatti, qemu-devel, marcel, pbonzini, rth
On Thu, Apr 26, 2018 at 11:26:42AM -0500, Babu Moger wrote:
> Add cache information in X86CPUDefinition and CPUX86State.
>
> Signed-off-by: Babu Moger <babu.moger@amd.com>
> Tested-by: Geoffrey McRae <geoff@hostfission.com>
> ---
> target/i386/cpu.c | 4 ++++
> target/i386/cpu.h | 8 ++++++++
> 2 files changed, 12 insertions(+)
>
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index b6c1592..a518a0f 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -1105,6 +1105,7 @@ struct X86CPUDefinition {
> int stepping;
> FeatureWordArray features;
> const char *model_id;
> + CPUCaches cache_info;
> };
>
> static X86CPUDefinition builtin_x86_defs[] = {
> @@ -3242,6 +3243,9 @@ static void x86_cpu_load_def(X86CPU *cpu, X86CPUDefinition *def, Error **errp)
> env->features[w] = def->features[w];
> }
>
> + /* Load Cache information from the X86CPUDefinition */
> + memcpy(&env->cache_info, &def->cache_info, sizeof(CPUCaches));
> +
> /* Special cases not set in the X86CPUDefinition structs: */
> /* TODO: in-kernel irqchip for hvf */
> if (kvm_enabled()) {
> diff --git a/target/i386/cpu.h b/target/i386/cpu.h
> index fa03e2c..1213bb7 100644
> --- a/target/i386/cpu.h
> +++ b/target/i386/cpu.h
> @@ -1096,6 +1096,13 @@ typedef struct CPUCacheInfo {
> } CPUCacheInfo;
>
>
> +typedef struct CPUCaches {
> + bool valid;
> + CPUCacheInfo l1d_cache;
> + CPUCacheInfo l1i_cache;
> + CPUCacheInfo l2_cache;
> + CPUCacheInfo l3_cache;
> +} CPUCaches;
>
> typedef struct CPUX86State {
> /* standard registers */
> @@ -1282,6 +1289,7 @@ typedef struct CPUX86State {
> /* Features that were explicitly enabled/disabled */
> FeatureWordArray user_features;
> uint32_t cpuid_model[12];
> + CPUCaches cache_info;
Suggestion for a follow-up patch, or in case there's need to
respin this series: what about making both
X86CPUDefinition::cache_info and CPUX86State::cache_info pointers
instead of embedded structs? This way you won't need the 'valid'
field (you can just check if the pointer is NULL), and won't need
the memcpy() above.
This shouldn't block the series, though:
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
--
Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [Qemu-devel] [PATCH v7 2/9] i386: Add cache information in X86CPUDefinition
@ 2018-05-07 19:09 ` Eduardo Habkost
0 siblings, 0 replies; 88+ messages in thread
From: Eduardo Habkost @ 2018-05-07 19:09 UTC (permalink / raw)
To: Babu Moger
Cc: mst, marcel, pbonzini, rth, mtosatti, geoff, kash, qemu-devel, kvm
On Thu, Apr 26, 2018 at 11:26:42AM -0500, Babu Moger wrote:
> Add cache information in X86CPUDefinition and CPUX86State.
>
> Signed-off-by: Babu Moger <babu.moger@amd.com>
> Tested-by: Geoffrey McRae <geoff@hostfission.com>
> ---
> target/i386/cpu.c | 4 ++++
> target/i386/cpu.h | 8 ++++++++
> 2 files changed, 12 insertions(+)
>
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index b6c1592..a518a0f 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -1105,6 +1105,7 @@ struct X86CPUDefinition {
> int stepping;
> FeatureWordArray features;
> const char *model_id;
> + CPUCaches cache_info;
> };
>
> static X86CPUDefinition builtin_x86_defs[] = {
> @@ -3242,6 +3243,9 @@ static void x86_cpu_load_def(X86CPU *cpu, X86CPUDefinition *def, Error **errp)
> env->features[w] = def->features[w];
> }
>
> + /* Load Cache information from the X86CPUDefinition */
> + memcpy(&env->cache_info, &def->cache_info, sizeof(CPUCaches));
> +
> /* Special cases not set in the X86CPUDefinition structs: */
> /* TODO: in-kernel irqchip for hvf */
> if (kvm_enabled()) {
> diff --git a/target/i386/cpu.h b/target/i386/cpu.h
> index fa03e2c..1213bb7 100644
> --- a/target/i386/cpu.h
> +++ b/target/i386/cpu.h
> @@ -1096,6 +1096,13 @@ typedef struct CPUCacheInfo {
> } CPUCacheInfo;
>
>
> +typedef struct CPUCaches {
> + bool valid;
> + CPUCacheInfo l1d_cache;
> + CPUCacheInfo l1i_cache;
> + CPUCacheInfo l2_cache;
> + CPUCacheInfo l3_cache;
> +} CPUCaches;
>
> typedef struct CPUX86State {
> /* standard registers */
> @@ -1282,6 +1289,7 @@ typedef struct CPUX86State {
> /* Features that were explicitly enabled/disabled */
> FeatureWordArray user_features;
> uint32_t cpuid_model[12];
> + CPUCaches cache_info;
Suggestion for a follow-up patch, or in case there's need to
respin this series: what about making both
X86CPUDefinition::cache_info and CPUX86State::cache_info pointers
instead of embedded structs? This way you won't need the 'valid'
field (you can just check if the pointer is NULL), and won't need
the memcpy() above.
This shouldn't block the series, though:
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
--
Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH v7 4/9] i386: Add new property to control cache info
2018-04-26 16:26 ` [Qemu-devel] " Babu Moger
@ 2018-05-07 19:14 ` Eduardo Habkost
-1 siblings, 0 replies; 88+ messages in thread
From: Eduardo Habkost @ 2018-05-07 19:14 UTC (permalink / raw)
To: Babu Moger
Cc: geoff, kvm, mst, kash, mtosatti, qemu-devel, marcel, pbonzini, rth
On Thu, Apr 26, 2018 at 11:26:44AM -0500, Babu Moger wrote:
> 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.
> It will be "on" for machine type "pc-q35-2.10" for compatibility.
>
> Signed-off-by: Babu Moger <babu.moger@amd.com>
> Tested-by: Geoffrey McRae <geoff@hostfission.com>
> ---
> include/hw/i386/pc.h | 4 ++++
> target/i386/cpu.c | 1 +
> target/i386/cpu.h | 5 +++++
> 3 files changed, 10 insertions(+)
>
> diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> index ffee841..d904a3c 100644
> --- a/include/hw/i386/pc.h
> +++ b/include/hw/i386/pc.h
> @@ -327,6 +327,10 @@ 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 = "on",\
> },
>
Looks good, except that we now need pc-*-2.13 machines, and this
should be moved to PC_COMPAT_2_12.
Also, I suggest squashing this with patch 5/9, and applying it
before patch 3/9.
--
Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [Qemu-devel] [PATCH v7 4/9] i386: Add new property to control cache info
@ 2018-05-07 19:14 ` Eduardo Habkost
0 siblings, 0 replies; 88+ messages in thread
From: Eduardo Habkost @ 2018-05-07 19:14 UTC (permalink / raw)
To: Babu Moger
Cc: mst, marcel, pbonzini, rth, mtosatti, geoff, kash, qemu-devel, kvm
On Thu, Apr 26, 2018 at 11:26:44AM -0500, Babu Moger wrote:
> 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.
> It will be "on" for machine type "pc-q35-2.10" for compatibility.
>
> Signed-off-by: Babu Moger <babu.moger@amd.com>
> Tested-by: Geoffrey McRae <geoff@hostfission.com>
> ---
> include/hw/i386/pc.h | 4 ++++
> target/i386/cpu.c | 1 +
> target/i386/cpu.h | 5 +++++
> 3 files changed, 10 insertions(+)
>
> diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> index ffee841..d904a3c 100644
> --- a/include/hw/i386/pc.h
> +++ b/include/hw/i386/pc.h
> @@ -327,6 +327,10 @@ 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 = "on",\
> },
>
Looks good, except that we now need pc-*-2.13 machines, and this
should be moved to PC_COMPAT_2_12.
Also, I suggest squashing this with patch 5/9, and applying it
before patch 3/9.
--
Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH v7 5/9] i386: Use the statically loaded cache definitions
2018-04-26 16:26 ` [Qemu-devel] " Babu Moger
@ 2018-05-07 19:15 ` Eduardo Habkost
-1 siblings, 0 replies; 88+ messages in thread
From: Eduardo Habkost @ 2018-05-07 19:15 UTC (permalink / raw)
To: Babu Moger
Cc: geoff, kvm, mst, kash, mtosatti, qemu-devel, marcel, pbonzini, rth
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>
Looks good, but I suggest squashing this with patch 4/9.
Additional suggestion below:
> ---
> 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);
We could rename l1*_cache_amd and l2_cache_amd to
"legacy_*_cache_amd", to make it clear they are just legacy cache
settings.
> + 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
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [Qemu-devel] [PATCH v7 5/9] i386: Use the statically loaded cache definitions
@ 2018-05-07 19:15 ` Eduardo Habkost
0 siblings, 0 replies; 88+ messages in thread
From: Eduardo Habkost @ 2018-05-07 19:15 UTC (permalink / raw)
To: Babu Moger
Cc: mst, marcel, pbonzini, rth, mtosatti, geoff, kash, qemu-devel, kvm
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>
Looks good, but I suggest squashing this with patch 4/9.
Additional suggestion below:
> ---
> 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);
We could rename l1*_cache_amd and l2_cache_amd to
"legacy_*_cache_amd", to make it clear they are just legacy cache
settings.
> + 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
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH v7 5/9] i386: Use the statically loaded cache definitions
2018-04-26 16:26 ` [Qemu-devel] " Babu Moger
@ 2018-05-07 19:37 ` Eduardo Habkost
-1 siblings, 0 replies; 88+ messages in thread
From: Eduardo Habkost @ 2018-05-07 19:37 UTC (permalink / raw)
To: Babu Moger
Cc: geoff, kvm, mst, kash, mtosatti, qemu-devel, marcel, pbonzini, rth
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.
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
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [Qemu-devel] [PATCH v7 5/9] i386: Use the statically loaded cache definitions
@ 2018-05-07 19:37 ` Eduardo Habkost
0 siblings, 0 replies; 88+ messages in thread
From: Eduardo Habkost @ 2018-05-07 19:37 UTC (permalink / raw)
To: Babu Moger
Cc: mst, marcel, pbonzini, rth, mtosatti, geoff, kash, qemu-devel, kvm
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.
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
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH v7 7/9] i386: Add support for CPUID_8000_001E for AMD
2018-04-26 16:26 ` [Qemu-devel] " Babu Moger
@ 2018-05-07 19:39 ` Eduardo Habkost
-1 siblings, 0 replies; 88+ messages in thread
From: Eduardo Habkost @ 2018-05-07 19:39 UTC (permalink / raw)
To: Babu Moger
Cc: geoff, kvm, mst, kash, mtosatti, qemu-devel, marcel, pbonzini, rth
On Thu, Apr 26, 2018 at 11:26:47AM -0500, Babu Moger wrote:
> Populate threads/core_id/apic_ids/socket_id when CPUID_EXT3_TOPOEXT
> feature is supported. This is required to support hyperthreading feature
> on AMD CPUs. This is supported via CPUID_8000_001E extended functions.
>
> Signed-off-by: Babu Moger <babu.moger@amd.com>
> Tested-by: Geoffrey McRae <geoff@hostfission.com>
> ---
> target/i386/cpu.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 1024b09..1b15023 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -315,6 +315,12 @@ static uint32_t encode_cache_cpuid80000005(CPUCacheInfo *cache)
> (((CORES_IN_CMPLX - 1) * 2) + 1) : \
> (CORES_IN_CMPLX - 1))
>
> +/* Definitions used on CPUID Leaf 0x8000001E */
> +#define EXTENDED_APIC_ID(threads, socket_id, core_id, thread_id) \
> + ((threads) ? \
> + ((socket_id << 6) | (core_id << 1) | thread_id) : \
> + ((socket_id << 6) | core_id))
I suggest moving this to i386/topology.h.
> +
> /*
> * Encode cache info for CPUID[0x80000006].ECX and CPUID[0x80000006].EDX
> * @l3 can be NULL.
> @@ -4105,6 +4111,14 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
> break;
> }
> break;
> + case 0x8000001E:
> + assert(cpu->core_id <= 255);
Where's the code that ensures this assert() line can't be
triggered by any command-line configuration?
> + *eax = EXTENDED_APIC_ID((cs->nr_threads - 1),
> + cpu->socket_id, cpu->core_id, cpu->thread_id);
> + *ebx = (cs->nr_threads - 1) << 8 | cpu->core_id;
> + *ecx = cpu->socket_id;
> + *edx = 0;
> + break;
> case 0xC0000000:
> *eax = env->cpuid_xlevel2;
> *ebx = 0;
> --
> 2.7.4
>
>
--
Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [Qemu-devel] [PATCH v7 7/9] i386: Add support for CPUID_8000_001E for AMD
@ 2018-05-07 19:39 ` Eduardo Habkost
0 siblings, 0 replies; 88+ messages in thread
From: Eduardo Habkost @ 2018-05-07 19:39 UTC (permalink / raw)
To: Babu Moger
Cc: mst, marcel, pbonzini, rth, mtosatti, geoff, kash, qemu-devel, kvm
On Thu, Apr 26, 2018 at 11:26:47AM -0500, Babu Moger wrote:
> Populate threads/core_id/apic_ids/socket_id when CPUID_EXT3_TOPOEXT
> feature is supported. This is required to support hyperthreading feature
> on AMD CPUs. This is supported via CPUID_8000_001E extended functions.
>
> Signed-off-by: Babu Moger <babu.moger@amd.com>
> Tested-by: Geoffrey McRae <geoff@hostfission.com>
> ---
> target/i386/cpu.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 1024b09..1b15023 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -315,6 +315,12 @@ static uint32_t encode_cache_cpuid80000005(CPUCacheInfo *cache)
> (((CORES_IN_CMPLX - 1) * 2) + 1) : \
> (CORES_IN_CMPLX - 1))
>
> +/* Definitions used on CPUID Leaf 0x8000001E */
> +#define EXTENDED_APIC_ID(threads, socket_id, core_id, thread_id) \
> + ((threads) ? \
> + ((socket_id << 6) | (core_id << 1) | thread_id) : \
> + ((socket_id << 6) | core_id))
I suggest moving this to i386/topology.h.
> +
> /*
> * Encode cache info for CPUID[0x80000006].ECX and CPUID[0x80000006].EDX
> * @l3 can be NULL.
> @@ -4105,6 +4111,14 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
> break;
> }
> break;
> + case 0x8000001E:
> + assert(cpu->core_id <= 255);
Where's the code that ensures this assert() line can't be
triggered by any command-line configuration?
> + *eax = EXTENDED_APIC_ID((cs->nr_threads - 1),
> + cpu->socket_id, cpu->core_id, cpu->thread_id);
> + *ebx = (cs->nr_threads - 1) << 8 | cpu->core_id;
> + *ecx = cpu->socket_id;
> + *edx = 0;
> + break;
> case 0xC0000000:
> *eax = env->cpuid_xlevel2;
> *ebx = 0;
> --
> 2.7.4
>
>
--
Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH v7 3/9] i386: Initialize cache information for EPYC family processors
2018-04-26 16:26 ` [Qemu-devel] " Babu Moger
@ 2018-05-07 20:22 ` Eduardo Habkost
-1 siblings, 0 replies; 88+ messages in thread
From: Eduardo Habkost @ 2018-05-07 20:22 UTC (permalink / raw)
To: Babu Moger
Cc: geoff, kvm, mst, kash, mtosatti, qemu-devel, marcel, pbonzini, rth
On Thu, Apr 26, 2018 at 11:26:43AM -0500, Babu Moger wrote:
> Initialize pre-determined cache information for EPYC processors.
>
> Signed-off-by: Babu Moger <babu.moger@amd.com>
> Tested-by: Geoffrey McRae <geoff@hostfission.com>
Assuming that the cache information below was validated by people
from AMD, patch looks good to me.
> ---
> target/i386/cpu.c | 96 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 96 insertions(+)
>
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index a518a0f..5d88363 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -2302,6 +2302,54 @@ static X86CPUDefinition builtin_x86_defs[] = {
> CPUID_6_EAX_ARAT,
> .xlevel = 0x8000000A,
> .model_id = "AMD EPYC Processor",
> + .cache_info.valid = 1,
> + .cache_info.l1d_cache = {
> + .type = DCACHE,
> + .level = 1,
> + .size = 32 * KiB,
> + .line_size = 64,
> + .associativity = 8,
> + .partitions = 1,
> + .sets = 64,
> + .lines_per_tag = 1,
> + .self_init = 1,
> + .no_invd_sharing = true,
> + },
> + .cache_info.l1i_cache = {
> + .type = ICACHE,
> + .level = 1,
> + .size = 64 * KiB,
> + .line_size = 64,
> + .associativity = 4,
> + .partitions = 1,
> + .sets = 256,
> + .lines_per_tag = 1,
> + .self_init = 1,
> + .no_invd_sharing = true,
> + },
> + .cache_info.l2_cache = {
> + .type = UNIFIED_CACHE,
> + .level = 2,
> + .size = 512 * KiB,
> + .line_size = 64,
> + .associativity = 8,
> + .partitions = 1,
> + .sets = 1024,
> + .lines_per_tag = 1,
> + },
> + .cache_info.l3_cache = {
> + .type = UNIFIED_CACHE,
> + .level = 3,
> + .size = 8 * MiB,
> + .line_size = 64,
> + .associativity = 16,
> + .partitions = 1,
> + .sets = 8192,
> + .lines_per_tag = 1,
> + .self_init = true,
> + .inclusive = true,
> + .complex_indexing = true,
> + },
> },
> {
> .name = "EPYC-IBPB",
> @@ -2348,6 +2396,54 @@ static X86CPUDefinition builtin_x86_defs[] = {
> CPUID_6_EAX_ARAT,
> .xlevel = 0x8000000A,
> .model_id = "AMD EPYC Processor (with IBPB)",
> + .cache_info.valid = 1,
> + .cache_info.l1d_cache = {
> + .type = DCACHE,
> + .level = 1,
> + .size = 32 * KiB,
> + .line_size = 64,
> + .associativity = 8,
> + .partitions = 1,
> + .sets = 64,
> + .lines_per_tag = 1,
> + .self_init = 1,
> + .no_invd_sharing = true,
> + },
> + .cache_info.l1i_cache = {
> + .type = ICACHE,
> + .level = 1,
> + .size = 64 * KiB,
> + .line_size = 64,
> + .associativity = 4,
> + .partitions = 1,
> + .sets = 256,
> + .lines_per_tag = 1,
> + .self_init = 1,
> + .no_invd_sharing = true,
> + },
> + .cache_info.l2_cache = {
> + .type = UNIFIED_CACHE,
> + .level = 2,
> + .size = 512 * KiB,
> + .line_size = 64,
> + .associativity = 8,
> + .partitions = 1,
> + .sets = 1024,
> + .lines_per_tag = 1,
> + },
> + .cache_info.l3_cache = {
> + .type = UNIFIED_CACHE,
> + .level = 3,
> + .size = 8 * MiB,
> + .line_size = 64,
> + .associativity = 16,
> + .partitions = 1,
> + .sets = 8192,
> + .lines_per_tag = 1,
> + .self_init = true,
> + .inclusive = true,
> + .complex_indexing = true,
> + },
> },
> };
>
> --
> 2.7.4
>
>
--
Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [Qemu-devel] [PATCH v7 3/9] i386: Initialize cache information for EPYC family processors
@ 2018-05-07 20:22 ` Eduardo Habkost
0 siblings, 0 replies; 88+ messages in thread
From: Eduardo Habkost @ 2018-05-07 20:22 UTC (permalink / raw)
To: Babu Moger
Cc: mst, marcel, pbonzini, rth, mtosatti, geoff, kash, qemu-devel, kvm
On Thu, Apr 26, 2018 at 11:26:43AM -0500, Babu Moger wrote:
> Initialize pre-determined cache information for EPYC processors.
>
> Signed-off-by: Babu Moger <babu.moger@amd.com>
> Tested-by: Geoffrey McRae <geoff@hostfission.com>
Assuming that the cache information below was validated by people
from AMD, patch looks good to me.
> ---
> target/i386/cpu.c | 96 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 96 insertions(+)
>
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index a518a0f..5d88363 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -2302,6 +2302,54 @@ static X86CPUDefinition builtin_x86_defs[] = {
> CPUID_6_EAX_ARAT,
> .xlevel = 0x8000000A,
> .model_id = "AMD EPYC Processor",
> + .cache_info.valid = 1,
> + .cache_info.l1d_cache = {
> + .type = DCACHE,
> + .level = 1,
> + .size = 32 * KiB,
> + .line_size = 64,
> + .associativity = 8,
> + .partitions = 1,
> + .sets = 64,
> + .lines_per_tag = 1,
> + .self_init = 1,
> + .no_invd_sharing = true,
> + },
> + .cache_info.l1i_cache = {
> + .type = ICACHE,
> + .level = 1,
> + .size = 64 * KiB,
> + .line_size = 64,
> + .associativity = 4,
> + .partitions = 1,
> + .sets = 256,
> + .lines_per_tag = 1,
> + .self_init = 1,
> + .no_invd_sharing = true,
> + },
> + .cache_info.l2_cache = {
> + .type = UNIFIED_CACHE,
> + .level = 2,
> + .size = 512 * KiB,
> + .line_size = 64,
> + .associativity = 8,
> + .partitions = 1,
> + .sets = 1024,
> + .lines_per_tag = 1,
> + },
> + .cache_info.l3_cache = {
> + .type = UNIFIED_CACHE,
> + .level = 3,
> + .size = 8 * MiB,
> + .line_size = 64,
> + .associativity = 16,
> + .partitions = 1,
> + .sets = 8192,
> + .lines_per_tag = 1,
> + .self_init = true,
> + .inclusive = true,
> + .complex_indexing = true,
> + },
> },
> {
> .name = "EPYC-IBPB",
> @@ -2348,6 +2396,54 @@ static X86CPUDefinition builtin_x86_defs[] = {
> CPUID_6_EAX_ARAT,
> .xlevel = 0x8000000A,
> .model_id = "AMD EPYC Processor (with IBPB)",
> + .cache_info.valid = 1,
> + .cache_info.l1d_cache = {
> + .type = DCACHE,
> + .level = 1,
> + .size = 32 * KiB,
> + .line_size = 64,
> + .associativity = 8,
> + .partitions = 1,
> + .sets = 64,
> + .lines_per_tag = 1,
> + .self_init = 1,
> + .no_invd_sharing = true,
> + },
> + .cache_info.l1i_cache = {
> + .type = ICACHE,
> + .level = 1,
> + .size = 64 * KiB,
> + .line_size = 64,
> + .associativity = 4,
> + .partitions = 1,
> + .sets = 256,
> + .lines_per_tag = 1,
> + .self_init = 1,
> + .no_invd_sharing = true,
> + },
> + .cache_info.l2_cache = {
> + .type = UNIFIED_CACHE,
> + .level = 2,
> + .size = 512 * KiB,
> + .line_size = 64,
> + .associativity = 8,
> + .partitions = 1,
> + .sets = 1024,
> + .lines_per_tag = 1,
> + },
> + .cache_info.l3_cache = {
> + .type = UNIFIED_CACHE,
> + .level = 3,
> + .size = 8 * MiB,
> + .line_size = 64,
> + .associativity = 16,
> + .partitions = 1,
> + .sets = 8192,
> + .lines_per_tag = 1,
> + .self_init = true,
> + .inclusive = true,
> + .complex_indexing = true,
> + },
> },
> };
>
> --
> 2.7.4
>
>
--
Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH v7 6/9] i386: Populate AMD Processor Cache Information for cpuid 0x8000001D
2018-04-26 16:26 ` [Qemu-devel] " Babu Moger
@ 2018-05-07 21:06 ` Eduardo Habkost
-1 siblings, 0 replies; 88+ messages in thread
From: Eduardo Habkost @ 2018-05-07 21:06 UTC (permalink / raw)
To: Babu Moger
Cc: geoff, kvm, mst, kash, mtosatti, qemu-devel, marcel, pbonzini, rth
Hi,
Sorry for taking so long to send feedback on this series:
On Thu, Apr 26, 2018 at 11:26:46AM -0500, Babu Moger wrote:
> Add information for cpuid 0x8000001D leaf. Populate cache topology information
> for different cache types(Data Cache, Instruction Cache, L2 and L3) supported
> by 0x8000001D leaf. Please refer Processor Programming Reference (PPR) for AMD
> Family 17h Model for more details.
>
> Signed-off-by: Babu Moger <babu.moger@amd.com>
> Tested-by: Geoffrey McRae <geoff@hostfission.com>
> ---
> target/i386/cpu.c | 92 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> target/i386/kvm.c | 29 ++++++++++++++++--
> 2 files changed, 118 insertions(+), 3 deletions(-)
>
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 56d2f0b..1024b09 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -307,6 +307,14 @@ static uint32_t encode_cache_cpuid80000005(CPUCacheInfo *cache)
> a == ASSOC_FULL ? 0xF : \
> 0 /* invalid value */)
>
> +/* Definitions used on CPUID Leaf 0x8000001D */
> +/* Number of logical cores in a complex */
> +#define CORES_IN_CMPLX 4
> +/* Number of logical processors sharing cache */
> +#define NUM_SHARING_CACHE(threads) (threads ? \
> + (((CORES_IN_CMPLX - 1) * 2) + 1) : \
> + (CORES_IN_CMPLX - 1))
> +
Some questions about these macros:
* Why CORES_IN_CMPLX is a constant, and we're not using
nr_cores?
* Why "2" is a constant, and we're not using nr_threads?
* Why it's getting nr_threads-1 as argument instead of
nr_threads?
> /*
> * Encode cache info for CPUID[0x80000006].ECX and CPUID[0x80000006].EDX
> * @l3 can be NULL.
> @@ -336,6 +344,41 @@ static void encode_cache_cpuid80000006(CPUCacheInfo *l2,
> }
> }
>
> +/* Encode cache info for CPUID[8000001D] */
> +static void encode_cache_cpuid8000001d(CPUCacheInfo *cache, int nr_threads,
> + uint32_t *eax, uint32_t *ebx,
> + uint32_t *ecx, uint32_t *edx)
> +{
> + assert(cache->size == cache->line_size * cache->associativity *
> + cache->partitions * cache->sets);
> +
> + *eax = CACHE_TYPE(cache->type) | CACHE_LEVEL(cache->level) |
> + (cache->self_init ? CACHE_SELF_INIT_LEVEL : 0);
> +
> + /* L3 is shared among multiple cores */
> + if (cache->level == 3) {
> + *eax |= (NUM_SHARING_CACHE(nr_threads - 1) << 14);
Isn't it simpler to write this as:
*eax |= ((nr_cores * nr_threads) - 1) << 14;
Or, even better:
static void encode_cache_cpuid8000001d(CPUCacheInfo *cache, int nr_logical_procs,
uint32_t *eax, uint32_t *ebx,
uint32_t *ecx, uint32_t *edx)
{
/* ... */
/* No need to check cache->level here */
*eax |= (nr_logical_procs - 1) << 14;
/* ... */
}
void cpu_x86_cpuid(...)
{
/* ... */
case 0x8000001D:
switch (count) {
case 0: /* L1 dcache info */
/* legacy_cache checks omitted in example for simplicity */
encode_cache_cpuid8000001d(&env->cache_info.l1d_cache,
cs->nr_threads,
eax, ebx, ecx, edx);
break;
case 1: /* L1 icache info */
encode_cache_cpuid8000001d(&env->cache_info.l1i_cache,
cs->nr_threads,
eax, ebx, ecx, edx);
break;
case 2: /* L2 cache info */
encode_cache_cpuid8000001d(&env->cache_info.l2_cache,
cs->nr_threads,
eax, ebx, ecx, edx);
break;
case 3: /* L3 cache info */
/* L3 is shared among multiple cores */
encode_cache_cpuid8000001d(&env->cache_info.l3_cache,
cs->nr_threads * cs->nr_cores,
eax, ebx, ecx, edx);
break;
/* ... */
}
> + } else {
> + *eax |= ((nr_threads - 1) << 14);
> + }
> +
> + assert(cache->line_size > 0);
> + assert(cache->partitions > 0);
> + assert(cache->associativity > 0);
> + /* We don't implement fully-associative caches */
> + assert(cache->associativity < cache->sets);
> + *ebx = (cache->line_size - 1) |
> + ((cache->partitions - 1) << 12) |
> + ((cache->associativity - 1) << 22);
> +
> + assert(cache->sets > 0);
> + *ecx = cache->sets - 1;
> +
> + *edx = (cache->no_invd_sharing ? CACHE_NO_INVD_SHARING : 0) |
> + (cache->inclusive ? CACHE_INCLUSIVE : 0) |
> + (cache->complex_indexing ? CACHE_COMPLEX_IDX : 0);
> +}
> +
> /* Definitions of the hardcoded cache entries we expose: */
>
> /* L1 data cache: */
> @@ -4013,6 +4056,55 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
> *edx = 0;
> }
> break;
> + case 0x8000001D:
> + *eax = 0;
> + switch (count) {
> + case 0: /* L1 dcache info */
> + if (env->cache_info.valid && !cpu->legacy_cache) {
> + encode_cache_cpuid8000001d(&env->cache_info.l1d_cache,
> + cs->nr_threads,
> + eax, ebx, ecx, edx);
> + } else {
> + encode_cache_cpuid8000001d(&l1d_cache_amd, cs->nr_threads,
> + eax, ebx, ecx, edx);
> + }
> + break;
> + case 1: /* L1 icache info */
> + if (env->cache_info.valid && !cpu->legacy_cache) {
> + encode_cache_cpuid8000001d(&env->cache_info.l1i_cache,
> + cs->nr_threads,
> + eax, ebx, ecx, edx);
> + } else {
> + encode_cache_cpuid8000001d(&l1i_cache_amd,
> + cs->nr_threads,
> + eax, ebx, ecx, edx);
> + }
> + break;
> + case 2: /* L2 cache info */
> + if (env->cache_info.valid && !cpu->legacy_cache) {
> + encode_cache_cpuid8000001d(&env->cache_info.l2_cache,
> + cs->nr_threads,
> + eax, ebx, ecx, edx);
> + } else {
> + encode_cache_cpuid8000001d(&l2_cache_amd, cs->nr_threads,
> + eax, ebx, ecx, edx);
> + }
> + break;
> + case 3: /* L3 cache info */
> + if (env->cache_info.valid && !cpu->legacy_cache) {
> + encode_cache_cpuid8000001d(&env->cache_info.l3_cache,
> + cs->nr_threads,
> + eax, ebx, ecx, edx);
> + } else {
> + encode_cache_cpuid8000001d(&l3_cache, cs->nr_threads,
> + eax, ebx, ecx, edx);
> + }
> + break;
> + default: /* end of info */
> + *eax = *ebx = *ecx = *edx = 0;
> + break;
> + }
> + break;
> case 0xC0000000:
> *eax = env->cpuid_xlevel2;
> *ebx = 0;
> diff --git a/target/i386/kvm.c b/target/i386/kvm.c
> index 6c49954..6e66f9c 100644
> --- a/target/i386/kvm.c
> +++ b/target/i386/kvm.c
> @@ -967,9 +967,32 @@ int kvm_arch_init_vcpu(CPUState *cs)
> }
> c = &cpuid_data.entries[cpuid_i++];
>
> - c->function = i;
> - c->flags = 0;
> - cpu_x86_cpuid(env, i, 0, &c->eax, &c->ebx, &c->ecx, &c->edx);
> + switch (i) {
> + case 0x8000001d:
> + /* Query for all AMD cache information leaves */
> + for (j = 0; ; j++) {
> + c->function = i;
> + c->flags = KVM_CPUID_FLAG_SIGNIFCANT_INDEX;
> + c->index = j;
> + cpu_x86_cpuid(env, i, j, &c->eax, &c->ebx, &c->ecx, &c->edx);
> +
> + if (c->eax == 0) {
> + break;
> + }
> + if (cpuid_i == KVM_MAX_CPUID_ENTRIES) {
> + fprintf(stderr, "cpuid_data is full, no space for "
> + "cpuid(eax:0x%x,ecx:0x%x)\n", i, j);
> + abort();
> + }
> + c = &cpuid_data.entries[cpuid_i++];
> + }
> + break;
> + default:
> + c->function = i;
> + c->flags = 0;
> + cpu_x86_cpuid(env, i, 0, &c->eax, &c->ebx, &c->ecx, &c->edx);
> + break;
> + }
> }
>
> /* Call Centaur's CPUID instructions they are supported. */
> --
> 2.7.4
>
>
--
Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [Qemu-devel] [PATCH v7 6/9] i386: Populate AMD Processor Cache Information for cpuid 0x8000001D
@ 2018-05-07 21:06 ` Eduardo Habkost
0 siblings, 0 replies; 88+ messages in thread
From: Eduardo Habkost @ 2018-05-07 21:06 UTC (permalink / raw)
To: Babu Moger
Cc: mst, marcel, pbonzini, rth, mtosatti, geoff, kash, qemu-devel, kvm
Hi,
Sorry for taking so long to send feedback on this series:
On Thu, Apr 26, 2018 at 11:26:46AM -0500, Babu Moger wrote:
> Add information for cpuid 0x8000001D leaf. Populate cache topology information
> for different cache types(Data Cache, Instruction Cache, L2 and L3) supported
> by 0x8000001D leaf. Please refer Processor Programming Reference (PPR) for AMD
> Family 17h Model for more details.
>
> Signed-off-by: Babu Moger <babu.moger@amd.com>
> Tested-by: Geoffrey McRae <geoff@hostfission.com>
> ---
> target/i386/cpu.c | 92 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> target/i386/kvm.c | 29 ++++++++++++++++--
> 2 files changed, 118 insertions(+), 3 deletions(-)
>
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 56d2f0b..1024b09 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -307,6 +307,14 @@ static uint32_t encode_cache_cpuid80000005(CPUCacheInfo *cache)
> a == ASSOC_FULL ? 0xF : \
> 0 /* invalid value */)
>
> +/* Definitions used on CPUID Leaf 0x8000001D */
> +/* Number of logical cores in a complex */
> +#define CORES_IN_CMPLX 4
> +/* Number of logical processors sharing cache */
> +#define NUM_SHARING_CACHE(threads) (threads ? \
> + (((CORES_IN_CMPLX - 1) * 2) + 1) : \
> + (CORES_IN_CMPLX - 1))
> +
Some questions about these macros:
* Why CORES_IN_CMPLX is a constant, and we're not using
nr_cores?
* Why "2" is a constant, and we're not using nr_threads?
* Why it's getting nr_threads-1 as argument instead of
nr_threads?
> /*
> * Encode cache info for CPUID[0x80000006].ECX and CPUID[0x80000006].EDX
> * @l3 can be NULL.
> @@ -336,6 +344,41 @@ static void encode_cache_cpuid80000006(CPUCacheInfo *l2,
> }
> }
>
> +/* Encode cache info for CPUID[8000001D] */
> +static void encode_cache_cpuid8000001d(CPUCacheInfo *cache, int nr_threads,
> + uint32_t *eax, uint32_t *ebx,
> + uint32_t *ecx, uint32_t *edx)
> +{
> + assert(cache->size == cache->line_size * cache->associativity *
> + cache->partitions * cache->sets);
> +
> + *eax = CACHE_TYPE(cache->type) | CACHE_LEVEL(cache->level) |
> + (cache->self_init ? CACHE_SELF_INIT_LEVEL : 0);
> +
> + /* L3 is shared among multiple cores */
> + if (cache->level == 3) {
> + *eax |= (NUM_SHARING_CACHE(nr_threads - 1) << 14);
Isn't it simpler to write this as:
*eax |= ((nr_cores * nr_threads) - 1) << 14;
Or, even better:
static void encode_cache_cpuid8000001d(CPUCacheInfo *cache, int nr_logical_procs,
uint32_t *eax, uint32_t *ebx,
uint32_t *ecx, uint32_t *edx)
{
/* ... */
/* No need to check cache->level here */
*eax |= (nr_logical_procs - 1) << 14;
/* ... */
}
void cpu_x86_cpuid(...)
{
/* ... */
case 0x8000001D:
switch (count) {
case 0: /* L1 dcache info */
/* legacy_cache checks omitted in example for simplicity */
encode_cache_cpuid8000001d(&env->cache_info.l1d_cache,
cs->nr_threads,
eax, ebx, ecx, edx);
break;
case 1: /* L1 icache info */
encode_cache_cpuid8000001d(&env->cache_info.l1i_cache,
cs->nr_threads,
eax, ebx, ecx, edx);
break;
case 2: /* L2 cache info */
encode_cache_cpuid8000001d(&env->cache_info.l2_cache,
cs->nr_threads,
eax, ebx, ecx, edx);
break;
case 3: /* L3 cache info */
/* L3 is shared among multiple cores */
encode_cache_cpuid8000001d(&env->cache_info.l3_cache,
cs->nr_threads * cs->nr_cores,
eax, ebx, ecx, edx);
break;
/* ... */
}
> + } else {
> + *eax |= ((nr_threads - 1) << 14);
> + }
> +
> + assert(cache->line_size > 0);
> + assert(cache->partitions > 0);
> + assert(cache->associativity > 0);
> + /* We don't implement fully-associative caches */
> + assert(cache->associativity < cache->sets);
> + *ebx = (cache->line_size - 1) |
> + ((cache->partitions - 1) << 12) |
> + ((cache->associativity - 1) << 22);
> +
> + assert(cache->sets > 0);
> + *ecx = cache->sets - 1;
> +
> + *edx = (cache->no_invd_sharing ? CACHE_NO_INVD_SHARING : 0) |
> + (cache->inclusive ? CACHE_INCLUSIVE : 0) |
> + (cache->complex_indexing ? CACHE_COMPLEX_IDX : 0);
> +}
> +
> /* Definitions of the hardcoded cache entries we expose: */
>
> /* L1 data cache: */
> @@ -4013,6 +4056,55 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
> *edx = 0;
> }
> break;
> + case 0x8000001D:
> + *eax = 0;
> + switch (count) {
> + case 0: /* L1 dcache info */
> + if (env->cache_info.valid && !cpu->legacy_cache) {
> + encode_cache_cpuid8000001d(&env->cache_info.l1d_cache,
> + cs->nr_threads,
> + eax, ebx, ecx, edx);
> + } else {
> + encode_cache_cpuid8000001d(&l1d_cache_amd, cs->nr_threads,
> + eax, ebx, ecx, edx);
> + }
> + break;
> + case 1: /* L1 icache info */
> + if (env->cache_info.valid && !cpu->legacy_cache) {
> + encode_cache_cpuid8000001d(&env->cache_info.l1i_cache,
> + cs->nr_threads,
> + eax, ebx, ecx, edx);
> + } else {
> + encode_cache_cpuid8000001d(&l1i_cache_amd,
> + cs->nr_threads,
> + eax, ebx, ecx, edx);
> + }
> + break;
> + case 2: /* L2 cache info */
> + if (env->cache_info.valid && !cpu->legacy_cache) {
> + encode_cache_cpuid8000001d(&env->cache_info.l2_cache,
> + cs->nr_threads,
> + eax, ebx, ecx, edx);
> + } else {
> + encode_cache_cpuid8000001d(&l2_cache_amd, cs->nr_threads,
> + eax, ebx, ecx, edx);
> + }
> + break;
> + case 3: /* L3 cache info */
> + if (env->cache_info.valid && !cpu->legacy_cache) {
> + encode_cache_cpuid8000001d(&env->cache_info.l3_cache,
> + cs->nr_threads,
> + eax, ebx, ecx, edx);
> + } else {
> + encode_cache_cpuid8000001d(&l3_cache, cs->nr_threads,
> + eax, ebx, ecx, edx);
> + }
> + break;
> + default: /* end of info */
> + *eax = *ebx = *ecx = *edx = 0;
> + break;
> + }
> + break;
> case 0xC0000000:
> *eax = env->cpuid_xlevel2;
> *ebx = 0;
> diff --git a/target/i386/kvm.c b/target/i386/kvm.c
> index 6c49954..6e66f9c 100644
> --- a/target/i386/kvm.c
> +++ b/target/i386/kvm.c
> @@ -967,9 +967,32 @@ int kvm_arch_init_vcpu(CPUState *cs)
> }
> c = &cpuid_data.entries[cpuid_i++];
>
> - c->function = i;
> - c->flags = 0;
> - cpu_x86_cpuid(env, i, 0, &c->eax, &c->ebx, &c->ecx, &c->edx);
> + switch (i) {
> + case 0x8000001d:
> + /* Query for all AMD cache information leaves */
> + for (j = 0; ; j++) {
> + c->function = i;
> + c->flags = KVM_CPUID_FLAG_SIGNIFCANT_INDEX;
> + c->index = j;
> + cpu_x86_cpuid(env, i, j, &c->eax, &c->ebx, &c->ecx, &c->edx);
> +
> + if (c->eax == 0) {
> + break;
> + }
> + if (cpuid_i == KVM_MAX_CPUID_ENTRIES) {
> + fprintf(stderr, "cpuid_data is full, no space for "
> + "cpuid(eax:0x%x,ecx:0x%x)\n", i, j);
> + abort();
> + }
> + c = &cpuid_data.entries[cpuid_i++];
> + }
> + break;
> + default:
> + c->function = i;
> + c->flags = 0;
> + cpu_x86_cpuid(env, i, 0, &c->eax, &c->ebx, &c->ecx, &c->edx);
> + break;
> + }
> }
>
> /* Call Centaur's CPUID instructions they are supported. */
> --
> 2.7.4
>
>
--
Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH v7 8/9] i386: Enable TOPOEXT feature on AMD EPYC CPU
2018-04-26 16:26 ` [Qemu-devel] " Babu Moger
@ 2018-05-07 21:07 ` Eduardo Habkost
-1 siblings, 0 replies; 88+ messages in thread
From: Eduardo Habkost @ 2018-05-07 21:07 UTC (permalink / raw)
To: Babu Moger
Cc: geoff, kvm, mst, kash, mtosatti, qemu-devel, marcel, pbonzini, rth
On Thu, Apr 26, 2018 at 11:26:48AM -0500, Babu Moger wrote:
> Enable TOPOEXT feature on EPYC CPU. This is required to support
> hyperthreading on VM guests. Also extend xlevel to 0x8000001E.
>
> Signed-off-by: Babu Moger <babu.moger@amd.com>
> Tested-by: Geoffrey McRae <geoff@hostfission.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
--
Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [Qemu-devel] [PATCH v7 8/9] i386: Enable TOPOEXT feature on AMD EPYC CPU
@ 2018-05-07 21:07 ` Eduardo Habkost
0 siblings, 0 replies; 88+ messages in thread
From: Eduardo Habkost @ 2018-05-07 21:07 UTC (permalink / raw)
To: Babu Moger
Cc: mst, marcel, pbonzini, rth, mtosatti, geoff, kash, qemu-devel, kvm
On Thu, Apr 26, 2018 at 11:26:48AM -0500, Babu Moger wrote:
> Enable TOPOEXT feature on EPYC CPU. This is required to support
> hyperthreading on VM guests. Also extend xlevel to 0x8000001E.
>
> Signed-off-by: Babu Moger <babu.moger@amd.com>
> Tested-by: Geoffrey McRae <geoff@hostfission.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
--
Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH v7 9/9] i386: Remove generic SMT thread check
2018-04-26 16:26 ` [Qemu-devel] " Babu Moger
@ 2018-05-07 21:14 ` Eduardo Habkost
-1 siblings, 0 replies; 88+ messages in thread
From: Eduardo Habkost @ 2018-05-07 21:14 UTC (permalink / raw)
To: Babu Moger
Cc: geoff, kvm, mst, kash, mtosatti, qemu-devel, marcel, pbonzini, rth
On Thu, Apr 26, 2018 at 11:26:49AM -0500, Babu Moger wrote:
> Remove generic non-intel check while validating hyperthreading support.
> Certain AMD CPUs can support hyperthreading now.
>
> CPU family with TOPOEXT feature can support hyperthreading now.
>
> Signed-off-by: Babu Moger <babu.moger@amd.com>
> Tested-by: Geoffrey McRae <geoff@hostfission.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
> ---
> target/i386/cpu.c | 15 +++++++++------
> 1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 6ebbef2..54d908f 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -4830,17 +4830,20 @@ static void x86_cpu_realizefn(DeviceState *dev, Error **errp)
>
> qemu_init_vcpu(cs);
>
> - /* Only Intel CPUs support hyperthreading. Even though QEMU fixes this
> - * issue by adjusting CPUID_0000_0001_EBX and CPUID_8000_0008_ECX
> - * based on inputs (sockets,cores,threads), it is still better to gives
> + /* Most Intel and certain AMD CPUs support hyperthreading. Even though QEMU
> + * fixes this issue by adjusting CPUID_0000_0001_EBX and CPUID_8000_0008_ECX
> + * based on inputs (sockets,cores,threads), it is still better to give
> * users a warning.
> *
> * NOTE: the following code has to follow qemu_init_vcpu(). Otherwise
> * cs->nr_threads hasn't be populated yet and the checking is incorrect.
> */
> - if (!IS_INTEL_CPU(env) && cs->nr_threads > 1 && !ht_warned) {
> - error_report("AMD CPU doesn't support hyperthreading. Please configure"
> - " -smp options properly.");
> + if (IS_AMD_CPU(env) &&
> + !(env->features[FEAT_8000_0001_ECX] & CPUID_EXT3_TOPOEXT) &&
> + cs->nr_threads > 1 && !ht_warned) {
> + error_report("This family of AMD CPU doesn't support "
> + "hyperthreading. Please configure -smp "
> + "options properly.");
> ht_warned = true;
> }
>
> --
> 2.7.4
>
>
--
Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH v7 1/9] i386: Helpers to encode cache information consistently
2018-05-07 19:05 ` [Qemu-devel] " Eduardo Habkost
@ 2018-05-07 21:14 ` Moger, Babu
-1 siblings, 0 replies; 88+ messages in thread
From: Moger, Babu @ 2018-05-07 21:14 UTC (permalink / raw)
To: Eduardo Habkost
Cc: geoff, kvm, mst, kash, mtosatti, qemu-devel, marcel, pbonzini, rth
Eduardo,
Thanks for all the comments. Will respond to each one separately.
> -----Original Message-----
> From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> Sent: Monday, May 7, 2018 2:05 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 1/9] i386: Helpers to encode cache
> information consistently
>
> Hi,
>
> I was about to apply this because I assumed it was the same patch
> I sent in March, but then I found this:
>
> On Thu, Apr 26, 2018 at 11:26:41AM -0500, Babu Moger wrote:
> > From: Eduardo Habkost <ehabkost@redhat.com>
> >
> > Instead of having a collection of macros that need to be used in
> > complex expressions to build CPUID data, define a CPUCacheInfo
> > struct that can hold information about a given cache. Helper
> > functions will take a CPUCacheInfo struct as input to encode
> > CPUID leaves for a cache.
> >
> > This will help us ensure consistency between cache information
> > CPUID leaves, and make the existing inconsistencies in CPUID info
> > more visible.
> >
> > Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> > Signed-off-by: Babu Moger <babu.moger@amd.com>
> > Tested-by: Geoffrey McRae <geoff@hostfission.com>
> [...]
> > -#define L2_ASSOCIATIVITY 16
> [...]
> > /*FIXME: CPUID leaf 0x80000006 is inconsistent with leaves 2 & 4 */
> > +static CPUCacheInfo l2_cache_amd = {
> [...]
> > + .associativity = 8,
> [...]
> > +};
> [...]
> > case 0x80000006:
> [...]
> > - *ecx = (L2_SIZE_KB_AMD << 16) | \
> > - (AMD_ENC_ASSOC(L2_ASSOCIATIVITY) << 12) | \
> > - (L2_LINES_PER_TAG << 8) | (L2_LINE_SIZE);
> [...]
> > + encode_cache_cpuid80000006(&l2_cache_amd,
> > + cpu->enable_l3_cache ? &l3_cache : NULL,
> > + ecx, edx);
> [...]
>
> The structs added by this patch are supposed to represent the
> legacy cache sizes, and must match the old code. My original
> patch set l2_cache_amd.associativity=16 because of that.
>
> This patch changes 0x80000006 from associativity=16 to
> associativity=8. Why?
The original code had a bug here. The associativity should have been 8.
My earlier response from the thread
http://patchwork.ozlabs.org/patch/884880/
This should have been 8-way. This is a bug. Will fix.
This should have been (AMD_ENC_ASSOC(L2_ASSOCIATIVITY_AMD) << 12)
>
> --
> Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [Qemu-devel] [PATCH v7 1/9] i386: Helpers to encode cache information consistently
@ 2018-05-07 21:14 ` Moger, Babu
0 siblings, 0 replies; 88+ messages in thread
From: Moger, Babu @ 2018-05-07 21:14 UTC (permalink / raw)
To: Eduardo Habkost
Cc: mst, marcel, pbonzini, rth, mtosatti, geoff, kash, qemu-devel, kvm
Eduardo,
Thanks for all the comments. Will respond to each one separately.
> -----Original Message-----
> From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> Sent: Monday, May 7, 2018 2:05 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 1/9] i386: Helpers to encode cache
> information consistently
>
> Hi,
>
> I was about to apply this because I assumed it was the same patch
> I sent in March, but then I found this:
>
> On Thu, Apr 26, 2018 at 11:26:41AM -0500, Babu Moger wrote:
> > From: Eduardo Habkost <ehabkost@redhat.com>
> >
> > Instead of having a collection of macros that need to be used in
> > complex expressions to build CPUID data, define a CPUCacheInfo
> > struct that can hold information about a given cache. Helper
> > functions will take a CPUCacheInfo struct as input to encode
> > CPUID leaves for a cache.
> >
> > This will help us ensure consistency between cache information
> > CPUID leaves, and make the existing inconsistencies in CPUID info
> > more visible.
> >
> > Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> > Signed-off-by: Babu Moger <babu.moger@amd.com>
> > Tested-by: Geoffrey McRae <geoff@hostfission.com>
> [...]
> > -#define L2_ASSOCIATIVITY 16
> [...]
> > /*FIXME: CPUID leaf 0x80000006 is inconsistent with leaves 2 & 4 */
> > +static CPUCacheInfo l2_cache_amd = {
> [...]
> > + .associativity = 8,
> [...]
> > +};
> [...]
> > case 0x80000006:
> [...]
> > - *ecx = (L2_SIZE_KB_AMD << 16) | \
> > - (AMD_ENC_ASSOC(L2_ASSOCIATIVITY) << 12) | \
> > - (L2_LINES_PER_TAG << 8) | (L2_LINE_SIZE);
> [...]
> > + encode_cache_cpuid80000006(&l2_cache_amd,
> > + cpu->enable_l3_cache ? &l3_cache : NULL,
> > + ecx, edx);
> [...]
>
> The structs added by this patch are supposed to represent the
> legacy cache sizes, and must match the old code. My original
> patch set l2_cache_amd.associativity=16 because of that.
>
> This patch changes 0x80000006 from associativity=16 to
> associativity=8. Why?
The original code had a bug here. The associativity should have been 8.
My earlier response from the thread
http://patchwork.ozlabs.org/patch/884880/
This should have been 8-way. This is a bug. Will fix.
This should have been (AMD_ENC_ASSOC(L2_ASSOCIATIVITY_AMD) << 12)
>
> --
> Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [Qemu-devel] [PATCH v7 9/9] i386: Remove generic SMT thread check
@ 2018-05-07 21:14 ` Eduardo Habkost
0 siblings, 0 replies; 88+ messages in thread
From: Eduardo Habkost @ 2018-05-07 21:14 UTC (permalink / raw)
To: Babu Moger
Cc: mst, marcel, pbonzini, rth, mtosatti, geoff, kash, qemu-devel, kvm
On Thu, Apr 26, 2018 at 11:26:49AM -0500, Babu Moger wrote:
> Remove generic non-intel check while validating hyperthreading support.
> Certain AMD CPUs can support hyperthreading now.
>
> CPU family with TOPOEXT feature can support hyperthreading now.
>
> Signed-off-by: Babu Moger <babu.moger@amd.com>
> Tested-by: Geoffrey McRae <geoff@hostfission.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
> ---
> target/i386/cpu.c | 15 +++++++++------
> 1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 6ebbef2..54d908f 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -4830,17 +4830,20 @@ static void x86_cpu_realizefn(DeviceState *dev, Error **errp)
>
> qemu_init_vcpu(cs);
>
> - /* Only Intel CPUs support hyperthreading. Even though QEMU fixes this
> - * issue by adjusting CPUID_0000_0001_EBX and CPUID_8000_0008_ECX
> - * based on inputs (sockets,cores,threads), it is still better to gives
> + /* Most Intel and certain AMD CPUs support hyperthreading. Even though QEMU
> + * fixes this issue by adjusting CPUID_0000_0001_EBX and CPUID_8000_0008_ECX
> + * based on inputs (sockets,cores,threads), it is still better to give
> * users a warning.
> *
> * NOTE: the following code has to follow qemu_init_vcpu(). Otherwise
> * cs->nr_threads hasn't be populated yet and the checking is incorrect.
> */
> - if (!IS_INTEL_CPU(env) && cs->nr_threads > 1 && !ht_warned) {
> - error_report("AMD CPU doesn't support hyperthreading. Please configure"
> - " -smp options properly.");
> + if (IS_AMD_CPU(env) &&
> + !(env->features[FEAT_8000_0001_ECX] & CPUID_EXT3_TOPOEXT) &&
> + cs->nr_threads > 1 && !ht_warned) {
> + error_report("This family of AMD CPU doesn't support "
> + "hyperthreading. Please configure -smp "
> + "options properly.");
> ht_warned = true;
> }
>
> --
> 2.7.4
>
>
--
Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH v7 1/9] i386: Helpers to encode cache information consistently
2018-05-07 21:14 ` [Qemu-devel] " Moger, Babu
@ 2018-05-07 21:27 ` Eduardo Habkost
-1 siblings, 0 replies; 88+ messages in thread
From: Eduardo Habkost @ 2018-05-07 21:27 UTC (permalink / raw)
To: Moger, Babu
Cc: geoff, kvm, mst, kash, mtosatti, qemu-devel, marcel, pbonzini, rth
On Mon, May 07, 2018 at 09:14:27PM +0000, Moger, Babu wrote:
> Eduardo,
> Thanks for all the comments. Will respond to each one separately.
>
> > -----Original Message-----
> > From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> > Sent: Monday, May 7, 2018 2:05 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 1/9] i386: Helpers to encode cache
> > information consistently
> >
> > Hi,
> >
> > I was about to apply this because I assumed it was the same patch
> > I sent in March, but then I found this:
> >
> > On Thu, Apr 26, 2018 at 11:26:41AM -0500, Babu Moger wrote:
> > > From: Eduardo Habkost <ehabkost@redhat.com>
> > >
> > > Instead of having a collection of macros that need to be used in
> > > complex expressions to build CPUID data, define a CPUCacheInfo
> > > struct that can hold information about a given cache. Helper
> > > functions will take a CPUCacheInfo struct as input to encode
> > > CPUID leaves for a cache.
> > >
> > > This will help us ensure consistency between cache information
> > > CPUID leaves, and make the existing inconsistencies in CPUID info
> > > more visible.
> > >
> > > Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> > > Signed-off-by: Babu Moger <babu.moger@amd.com>
> > > Tested-by: Geoffrey McRae <geoff@hostfission.com>
> > [...]
> > > -#define L2_ASSOCIATIVITY 16
> > [...]
> > > /*FIXME: CPUID leaf 0x80000006 is inconsistent with leaves 2 & 4 */
> > > +static CPUCacheInfo l2_cache_amd = {
> > [...]
> > > + .associativity = 8,
> > [...]
> > > +};
> > [...]
> > > case 0x80000006:
> > [...]
> > > - *ecx = (L2_SIZE_KB_AMD << 16) | \
> > > - (AMD_ENC_ASSOC(L2_ASSOCIATIVITY) << 12) | \
> > > - (L2_LINES_PER_TAG << 8) | (L2_LINE_SIZE);
> > [...]
> > > + encode_cache_cpuid80000006(&l2_cache_amd,
> > > + cpu->enable_l3_cache ? &l3_cache : NULL,
> > > + ecx, edx);
> > [...]
> >
> > The structs added by this patch are supposed to represent the
> > legacy cache sizes, and must match the old code. My original
> > patch set l2_cache_amd.associativity=16 because of that.
> >
> > This patch changes 0x80000006 from associativity=16 to
> > associativity=8. Why?
>
> The original code had a bug here. The associativity should have been 8.
> My earlier response from the thread
> http://patchwork.ozlabs.org/patch/884880/
>
> This should have been 8-way. This is a bug. Will fix.
> This should have been (AMD_ENC_ASSOC(L2_ASSOCIATIVITY_AMD) << 12)
If we want to change the associativity, we must keep the old
values on older machine-types, which was the whole purpose of the
"legacy-cache" property.
I suggest using the new X86CPUDefinition::cache_info field if you
want to make AMD CPUs report different associativity.
--
Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [Qemu-devel] [PATCH v7 1/9] i386: Helpers to encode cache information consistently
@ 2018-05-07 21:27 ` Eduardo Habkost
0 siblings, 0 replies; 88+ messages in thread
From: Eduardo Habkost @ 2018-05-07 21:27 UTC (permalink / raw)
To: Moger, Babu
Cc: geoff, kvm, mst, kash, mtosatti, qemu-devel, marcel, pbonzini, rth
On Mon, May 07, 2018 at 09:14:27PM +0000, Moger, Babu wrote:
> Eduardo,
> Thanks for all the comments. Will respond to each one separately.
>
> > -----Original Message-----
> > From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> > Sent: Monday, May 7, 2018 2:05 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 1/9] i386: Helpers to encode cache
> > information consistently
> >
> > Hi,
> >
> > I was about to apply this because I assumed it was the same patch
> > I sent in March, but then I found this:
> >
> > On Thu, Apr 26, 2018 at 11:26:41AM -0500, Babu Moger wrote:
> > > From: Eduardo Habkost <ehabkost@redhat.com>
> > >
> > > Instead of having a collection of macros that need to be used in
> > > complex expressions to build CPUID data, define a CPUCacheInfo
> > > struct that can hold information about a given cache. Helper
> > > functions will take a CPUCacheInfo struct as input to encode
> > > CPUID leaves for a cache.
> > >
> > > This will help us ensure consistency between cache information
> > > CPUID leaves, and make the existing inconsistencies in CPUID info
> > > more visible.
> > >
> > > Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> > > Signed-off-by: Babu Moger <babu.moger@amd.com>
> > > Tested-by: Geoffrey McRae <geoff@hostfission.com>
> > [...]
> > > -#define L2_ASSOCIATIVITY 16
> > [...]
> > > /*FIXME: CPUID leaf 0x80000006 is inconsistent with leaves 2 & 4 */
> > > +static CPUCacheInfo l2_cache_amd = {
> > [...]
> > > + .associativity = 8,
> > [...]
> > > +};
> > [...]
> > > case 0x80000006:
> > [...]
> > > - *ecx = (L2_SIZE_KB_AMD << 16) | \
> > > - (AMD_ENC_ASSOC(L2_ASSOCIATIVITY) << 12) | \
> > > - (L2_LINES_PER_TAG << 8) | (L2_LINE_SIZE);
> > [...]
> > > + encode_cache_cpuid80000006(&l2_cache_amd,
> > > + cpu->enable_l3_cache ? &l3_cache : NULL,
> > > + ecx, edx);
> > [...]
> >
> > The structs added by this patch are supposed to represent the
> > legacy cache sizes, and must match the old code. My original
> > patch set l2_cache_amd.associativity=16 because of that.
> >
> > This patch changes 0x80000006 from associativity=16 to
> > associativity=8. Why?
>
> The original code had a bug here. The associativity should have been 8.
> My earlier response from the thread
> http://patchwork.ozlabs.org/patch/884880/
>
> This should have been 8-way. This is a bug. Will fix.
> This should have been (AMD_ENC_ASSOC(L2_ASSOCIATIVITY_AMD) << 12)
If we want to change the associativity, we must keep the old
values on older machine-types, which was the whole purpose of the
"legacy-cache" property.
I suggest using the new X86CPUDefinition::cache_info field if you
want to make AMD CPUs report different associativity.
--
Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH v7 1/9] i386: Helpers to encode cache information consistently
2018-05-07 21:27 ` [Qemu-devel] " Eduardo Habkost
@ 2018-05-07 22:47 ` Moger, Babu
-1 siblings, 0 replies; 88+ messages in thread
From: Moger, Babu @ 2018-05-07 22:47 UTC (permalink / raw)
To: Eduardo Habkost
Cc: geoff, kvm, mst, kash, mtosatti, qemu-devel, marcel, pbonzini, rth
> -----Original Message-----
> From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> Sent: Monday, May 7, 2018 4:27 PM
> To: Moger, Babu <Babu.Moger@amd.com>
> Cc: geoff@hostfission.com; kvm@vger.kernel.org; mst@redhat.com;
> kash@tripleback.net; mtosatti@redhat.com; qemu-devel@nongnu.org;
> marcel@redhat.com; pbonzini@redhat.com; rth@twiddle.net
> Subject: Re: [Qemu-devel] [PATCH v7 1/9] i386: Helpers to encode cache
> information consistently
>
> On Mon, May 07, 2018 at 09:14:27PM +0000, Moger, Babu wrote:
> > Eduardo,
> > Thanks for all the comments. Will respond to each one separately.
> >
> > > -----Original Message-----
> > > From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> > > Sent: Monday, May 7, 2018 2:05 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 1/9] i386: Helpers to encode cache
> > > information consistently
> > >
> > > Hi,
> > >
> > > I was about to apply this because I assumed it was the same patch
> > > I sent in March, but then I found this:
> > >
> > > On Thu, Apr 26, 2018 at 11:26:41AM -0500, Babu Moger wrote:
> > > > From: Eduardo Habkost <ehabkost@redhat.com>
> > > >
> > > > Instead of having a collection of macros that need to be used in
> > > > complex expressions to build CPUID data, define a CPUCacheInfo
> > > > struct that can hold information about a given cache. Helper
> > > > functions will take a CPUCacheInfo struct as input to encode
> > > > CPUID leaves for a cache.
> > > >
> > > > This will help us ensure consistency between cache information
> > > > CPUID leaves, and make the existing inconsistencies in CPUID info
> > > > more visible.
> > > >
> > > > Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> > > > Signed-off-by: Babu Moger <babu.moger@amd.com>
> > > > Tested-by: Geoffrey McRae <geoff@hostfission.com>
> > > [...]
> > > > -#define L2_ASSOCIATIVITY 16
> > > [...]
> > > > /*FIXME: CPUID leaf 0x80000006 is inconsistent with leaves 2 & 4 */
> > > > +static CPUCacheInfo l2_cache_amd = {
> > > [...]
> > > > + .associativity = 8,
> > > [...]
> > > > +};
> > > [...]
> > > > case 0x80000006:
> > > [...]
> > > > - *ecx = (L2_SIZE_KB_AMD << 16) | \
> > > > - (AMD_ENC_ASSOC(L2_ASSOCIATIVITY) << 12) | \
> > > > - (L2_LINES_PER_TAG << 8) | (L2_LINE_SIZE);
> > > [...]
> > > > + encode_cache_cpuid80000006(&l2_cache_amd,
> > > > + cpu->enable_l3_cache ? &l3_cache : NULL,
> > > > + ecx, edx);
> > > [...]
> > >
> > > The structs added by this patch are supposed to represent the
> > > legacy cache sizes, and must match the old code. My original
> > > patch set l2_cache_amd.associativity=16 because of that.
> > >
> > > This patch changes 0x80000006 from associativity=16 to
> > > associativity=8. Why?
> >
> > The original code had a bug here. The associativity should have been 8.
> > My earlier response from the thread
> > http://patchwork.ozlabs.org/patch/884880/
> >
> > This should have been 8-way. This is a bug. Will fix.
> > This should have been (AMD_ENC_ASSOC(L2_ASSOCIATIVITY_AMD) <<
> 12)
>
> If we want to change the associativity, we must keep the old
> values on older machine-types, which was the whole purpose of the
> "legacy-cache" property.
>
> I suggest using the new X86CPUDefinition::cache_info field if you
> want to make AMD CPUs report different associativity.
Ok. Sure. I will change it. Thanks
>
> --
> Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [Qemu-devel] [PATCH v7 1/9] i386: Helpers to encode cache information consistently
@ 2018-05-07 22:47 ` Moger, Babu
0 siblings, 0 replies; 88+ messages in thread
From: Moger, Babu @ 2018-05-07 22:47 UTC (permalink / raw)
To: Eduardo Habkost
Cc: geoff, kvm, mst, kash, mtosatti, qemu-devel, marcel, pbonzini, rth
> -----Original Message-----
> From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> Sent: Monday, May 7, 2018 4:27 PM
> To: Moger, Babu <Babu.Moger@amd.com>
> Cc: geoff@hostfission.com; kvm@vger.kernel.org; mst@redhat.com;
> kash@tripleback.net; mtosatti@redhat.com; qemu-devel@nongnu.org;
> marcel@redhat.com; pbonzini@redhat.com; rth@twiddle.net
> Subject: Re: [Qemu-devel] [PATCH v7 1/9] i386: Helpers to encode cache
> information consistently
>
> On Mon, May 07, 2018 at 09:14:27PM +0000, Moger, Babu wrote:
> > Eduardo,
> > Thanks for all the comments. Will respond to each one separately.
> >
> > > -----Original Message-----
> > > From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> > > Sent: Monday, May 7, 2018 2:05 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 1/9] i386: Helpers to encode cache
> > > information consistently
> > >
> > > Hi,
> > >
> > > I was about to apply this because I assumed it was the same patch
> > > I sent in March, but then I found this:
> > >
> > > On Thu, Apr 26, 2018 at 11:26:41AM -0500, Babu Moger wrote:
> > > > From: Eduardo Habkost <ehabkost@redhat.com>
> > > >
> > > > Instead of having a collection of macros that need to be used in
> > > > complex expressions to build CPUID data, define a CPUCacheInfo
> > > > struct that can hold information about a given cache. Helper
> > > > functions will take a CPUCacheInfo struct as input to encode
> > > > CPUID leaves for a cache.
> > > >
> > > > This will help us ensure consistency between cache information
> > > > CPUID leaves, and make the existing inconsistencies in CPUID info
> > > > more visible.
> > > >
> > > > Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> > > > Signed-off-by: Babu Moger <babu.moger@amd.com>
> > > > Tested-by: Geoffrey McRae <geoff@hostfission.com>
> > > [...]
> > > > -#define L2_ASSOCIATIVITY 16
> > > [...]
> > > > /*FIXME: CPUID leaf 0x80000006 is inconsistent with leaves 2 & 4 */
> > > > +static CPUCacheInfo l2_cache_amd = {
> > > [...]
> > > > + .associativity = 8,
> > > [...]
> > > > +};
> > > [...]
> > > > case 0x80000006:
> > > [...]
> > > > - *ecx = (L2_SIZE_KB_AMD << 16) | \
> > > > - (AMD_ENC_ASSOC(L2_ASSOCIATIVITY) << 12) | \
> > > > - (L2_LINES_PER_TAG << 8) | (L2_LINE_SIZE);
> > > [...]
> > > > + encode_cache_cpuid80000006(&l2_cache_amd,
> > > > + cpu->enable_l3_cache ? &l3_cache : NULL,
> > > > + ecx, edx);
> > > [...]
> > >
> > > The structs added by this patch are supposed to represent the
> > > legacy cache sizes, and must match the old code. My original
> > > patch set l2_cache_amd.associativity=16 because of that.
> > >
> > > This patch changes 0x80000006 from associativity=16 to
> > > associativity=8. Why?
> >
> > The original code had a bug here. The associativity should have been 8.
> > My earlier response from the thread
> > http://patchwork.ozlabs.org/patch/884880/
> >
> > This should have been 8-way. This is a bug. Will fix.
> > This should have been (AMD_ENC_ASSOC(L2_ASSOCIATIVITY_AMD) <<
> 12)
>
> If we want to change the associativity, we must keep the old
> values on older machine-types, which was the whole purpose of the
> "legacy-cache" property.
>
> I suggest using the new X86CPUDefinition::cache_info field if you
> want to make AMD CPUs report different associativity.
Ok. Sure. I will change it. Thanks
>
> --
> Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH v7 2/9] i386: Add cache information in X86CPUDefinition
2018-05-07 19:09 ` [Qemu-devel] " Eduardo Habkost
@ 2018-05-07 22:56 ` Moger, Babu
-1 siblings, 0 replies; 88+ messages in thread
From: Moger, Babu @ 2018-05-07 22:56 UTC (permalink / raw)
To: Eduardo Habkost
Cc: geoff, kvm, mst, kash, mtosatti, qemu-devel, marcel, pbonzini, rth
> -----Original Message-----
> From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> Sent: Monday, May 7, 2018 2:10 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 2/9] i386: Add cache information in
> X86CPUDefinition
>
> On Thu, Apr 26, 2018 at 11:26:42AM -0500, Babu Moger wrote:
> > Add cache information in X86CPUDefinition and CPUX86State.
> >
> > Signed-off-by: Babu Moger <babu.moger@amd.com>
> > Tested-by: Geoffrey McRae <geoff@hostfission.com>
> > ---
> > target/i386/cpu.c | 4 ++++
> > target/i386/cpu.h | 8 ++++++++
> > 2 files changed, 12 insertions(+)
> >
> > diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> > index b6c1592..a518a0f 100644
> > --- a/target/i386/cpu.c
> > +++ b/target/i386/cpu.c
> > @@ -1105,6 +1105,7 @@ struct X86CPUDefinition {
> > int stepping;
> > FeatureWordArray features;
> > const char *model_id;
> > + CPUCaches cache_info;
> > };
> >
> > static X86CPUDefinition builtin_x86_defs[] = {
> > @@ -3242,6 +3243,9 @@ static void x86_cpu_load_def(X86CPU *cpu,
> X86CPUDefinition *def, Error **errp)
> > env->features[w] = def->features[w];
> > }
> >
> > + /* Load Cache information from the X86CPUDefinition */
> > + memcpy(&env->cache_info, &def->cache_info, sizeof(CPUCaches));
> > +
> > /* Special cases not set in the X86CPUDefinition structs: */
> > /* TODO: in-kernel irqchip for hvf */
> > if (kvm_enabled()) {
> > diff --git a/target/i386/cpu.h b/target/i386/cpu.h
> > index fa03e2c..1213bb7 100644
> > --- a/target/i386/cpu.h
> > +++ b/target/i386/cpu.h
> > @@ -1096,6 +1096,13 @@ typedef struct CPUCacheInfo {
> > } CPUCacheInfo;
> >
> >
> > +typedef struct CPUCaches {
> > + bool valid;
> > + CPUCacheInfo l1d_cache;
> > + CPUCacheInfo l1i_cache;
> > + CPUCacheInfo l2_cache;
> > + CPUCacheInfo l3_cache;
> > +} CPUCaches;
> >
> > typedef struct CPUX86State {
> > /* standard registers */
> > @@ -1282,6 +1289,7 @@ typedef struct CPUX86State {
> > /* Features that were explicitly enabled/disabled */
> > FeatureWordArray user_features;
> > uint32_t cpuid_model[12];
> > + CPUCaches cache_info;
>
> Suggestion for a follow-up patch, or in case there's need to
> respin this series: what about making both
> X86CPUDefinition::cache_info and CPUX86State::cache_info pointers
> instead of embedded structs? This way you won't need the 'valid'
> field (you can just check if the pointer is NULL), and won't need
> the memcpy() above.
Sure. We can do that. Basically, initialize a static cache_info structure and use the address wherever applicable.
Will try it.
>
> This shouldn't block the series, though:
>
> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
>
> --
> Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [Qemu-devel] [PATCH v7 2/9] i386: Add cache information in X86CPUDefinition
@ 2018-05-07 22:56 ` Moger, Babu
0 siblings, 0 replies; 88+ messages in thread
From: Moger, Babu @ 2018-05-07 22:56 UTC (permalink / raw)
To: Eduardo Habkost
Cc: mst, marcel, pbonzini, rth, mtosatti, geoff, kash, qemu-devel, kvm
> -----Original Message-----
> From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> Sent: Monday, May 7, 2018 2:10 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 2/9] i386: Add cache information in
> X86CPUDefinition
>
> On Thu, Apr 26, 2018 at 11:26:42AM -0500, Babu Moger wrote:
> > Add cache information in X86CPUDefinition and CPUX86State.
> >
> > Signed-off-by: Babu Moger <babu.moger@amd.com>
> > Tested-by: Geoffrey McRae <geoff@hostfission.com>
> > ---
> > target/i386/cpu.c | 4 ++++
> > target/i386/cpu.h | 8 ++++++++
> > 2 files changed, 12 insertions(+)
> >
> > diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> > index b6c1592..a518a0f 100644
> > --- a/target/i386/cpu.c
> > +++ b/target/i386/cpu.c
> > @@ -1105,6 +1105,7 @@ struct X86CPUDefinition {
> > int stepping;
> > FeatureWordArray features;
> > const char *model_id;
> > + CPUCaches cache_info;
> > };
> >
> > static X86CPUDefinition builtin_x86_defs[] = {
> > @@ -3242,6 +3243,9 @@ static void x86_cpu_load_def(X86CPU *cpu,
> X86CPUDefinition *def, Error **errp)
> > env->features[w] = def->features[w];
> > }
> >
> > + /* Load Cache information from the X86CPUDefinition */
> > + memcpy(&env->cache_info, &def->cache_info, sizeof(CPUCaches));
> > +
> > /* Special cases not set in the X86CPUDefinition structs: */
> > /* TODO: in-kernel irqchip for hvf */
> > if (kvm_enabled()) {
> > diff --git a/target/i386/cpu.h b/target/i386/cpu.h
> > index fa03e2c..1213bb7 100644
> > --- a/target/i386/cpu.h
> > +++ b/target/i386/cpu.h
> > @@ -1096,6 +1096,13 @@ typedef struct CPUCacheInfo {
> > } CPUCacheInfo;
> >
> >
> > +typedef struct CPUCaches {
> > + bool valid;
> > + CPUCacheInfo l1d_cache;
> > + CPUCacheInfo l1i_cache;
> > + CPUCacheInfo l2_cache;
> > + CPUCacheInfo l3_cache;
> > +} CPUCaches;
> >
> > typedef struct CPUX86State {
> > /* standard registers */
> > @@ -1282,6 +1289,7 @@ typedef struct CPUX86State {
> > /* Features that were explicitly enabled/disabled */
> > FeatureWordArray user_features;
> > uint32_t cpuid_model[12];
> > + CPUCaches cache_info;
>
> Suggestion for a follow-up patch, or in case there's need to
> respin this series: what about making both
> X86CPUDefinition::cache_info and CPUX86State::cache_info pointers
> instead of embedded structs? This way you won't need the 'valid'
> field (you can just check if the pointer is NULL), and won't need
> the memcpy() above.
Sure. We can do that. Basically, initialize a static cache_info structure and use the address wherever applicable.
Will try it.
>
> This shouldn't block the series, though:
>
> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
>
> --
> Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH v7 4/9] i386: Add new property to control cache info
2018-05-07 19:14 ` [Qemu-devel] " Eduardo Habkost
@ 2018-05-07 23:29 ` Moger, Babu
-1 siblings, 0 replies; 88+ messages in thread
From: Moger, Babu @ 2018-05-07 23:29 UTC (permalink / raw)
To: Eduardo Habkost
Cc: geoff, kvm, mst, kash, mtosatti, qemu-devel, marcel, pbonzini, rth
> -----Original Message-----
> From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> Sent: Monday, May 7, 2018 2:14 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 4/9] i386: Add new property to control
> cache info
>
> On Thu, Apr 26, 2018 at 11:26:44AM -0500, Babu Moger wrote:
> > 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.
> > It will be "on" for machine type "pc-q35-2.10" for compatibility.
> >
> > Signed-off-by: Babu Moger <babu.moger@amd.com>
> > Tested-by: Geoffrey McRae <geoff@hostfission.com>
> > ---
> > include/hw/i386/pc.h | 4 ++++
> > target/i386/cpu.c | 1 +
> > target/i386/cpu.h | 5 +++++
> > 3 files changed, 10 insertions(+)
> >
> > diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> > index ffee841..d904a3c 100644
> > --- a/include/hw/i386/pc.h
> > +++ b/include/hw/i386/pc.h
> > @@ -327,6 +327,10 @@ 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 = "on",\
> > },
> >
>
> Looks good, except that we now need pc-*-2.13 machines, and this
> should be moved to PC_COMPAT_2_12.
Ok. Sure. There is no PC_COMPAT_2_12 definition now. I will add it and include this new property.
>
> Also, I suggest squashing this with patch 5/9, and applying it
> before patch 3/9.
Ok. Sure.
>
> --
> Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [Qemu-devel] [PATCH v7 4/9] i386: Add new property to control cache info
@ 2018-05-07 23:29 ` Moger, Babu
0 siblings, 0 replies; 88+ messages in thread
From: Moger, Babu @ 2018-05-07 23:29 UTC (permalink / raw)
To: Eduardo Habkost
Cc: mst, marcel, pbonzini, rth, mtosatti, geoff, kash, qemu-devel, kvm
> -----Original Message-----
> From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> Sent: Monday, May 7, 2018 2:14 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 4/9] i386: Add new property to control
> cache info
>
> On Thu, Apr 26, 2018 at 11:26:44AM -0500, Babu Moger wrote:
> > 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.
> > It will be "on" for machine type "pc-q35-2.10" for compatibility.
> >
> > Signed-off-by: Babu Moger <babu.moger@amd.com>
> > Tested-by: Geoffrey McRae <geoff@hostfission.com>
> > ---
> > include/hw/i386/pc.h | 4 ++++
> > target/i386/cpu.c | 1 +
> > target/i386/cpu.h | 5 +++++
> > 3 files changed, 10 insertions(+)
> >
> > diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> > index ffee841..d904a3c 100644
> > --- a/include/hw/i386/pc.h
> > +++ b/include/hw/i386/pc.h
> > @@ -327,6 +327,10 @@ 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 = "on",\
> > },
> >
>
> Looks good, except that we now need pc-*-2.13 machines, and this
> should be moved to PC_COMPAT_2_12.
Ok. Sure. There is no PC_COMPAT_2_12 definition now. I will add it and include this new property.
>
> Also, I suggest squashing this with patch 5/9, and applying it
> before patch 3/9.
Ok. Sure.
>
> --
> Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH v7 5/9] i386: Use the statically loaded cache definitions
2018-05-07 19:15 ` [Qemu-devel] " Eduardo Habkost
@ 2018-05-07 23:32 ` Moger, Babu
-1 siblings, 0 replies; 88+ messages in thread
From: Moger, Babu @ 2018-05-07 23:32 UTC (permalink / raw)
To: Eduardo Habkost
Cc: geoff, kvm, mst, kash, mtosatti, qemu-devel, marcel, pbonzini, rth
> -----Original Message-----
> From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> Sent: Monday, May 7, 2018 2:16 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>
>
> Looks good, but I suggest squashing this with patch 4/9.
Ok. Sure.
>
> Additional suggestion below:
>
> > ---
> > 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);
>
> We could rename l1*_cache_amd and l2_cache_amd to
> "legacy_*_cache_amd", to make it clear they are just legacy cache
> settings.
Ok. We can do that.
>
> > + 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
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [Qemu-devel] [PATCH v7 5/9] i386: Use the statically loaded cache definitions
@ 2018-05-07 23:32 ` Moger, Babu
0 siblings, 0 replies; 88+ messages in thread
From: Moger, Babu @ 2018-05-07 23:32 UTC (permalink / raw)
To: Eduardo Habkost
Cc: mst, marcel, pbonzini, rth, mtosatti, geoff, kash, qemu-devel, kvm
> -----Original Message-----
> From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> Sent: Monday, May 7, 2018 2:16 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>
>
> Looks good, but I suggest squashing this with patch 4/9.
Ok. Sure.
>
> Additional suggestion below:
>
> > ---
> > 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);
>
> We could rename l1*_cache_amd and l2_cache_amd to
> "legacy_*_cache_amd", to make it clear they are just legacy cache
> settings.
Ok. We can do that.
>
> > + 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
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH v7 5/9] i386: Use the statically loaded cache definitions
2018-05-07 19:37 ` [Qemu-devel] " Eduardo Habkost
@ 2018-05-07 23:39 ` Moger, Babu
-1 siblings, 0 replies; 88+ messages in thread
From: Moger, Babu @ 2018-05-07 23:39 UTC (permalink / raw)
To: Eduardo Habkost
Cc: geoff, kvm, mst, kash, mtosatti, qemu-devel, marcel, pbonzini, rth
> -----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].
>
> 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
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [Qemu-devel] [PATCH v7 5/9] i386: Use the statically loaded cache definitions
@ 2018-05-07 23:39 ` Moger, Babu
0 siblings, 0 replies; 88+ messages in thread
From: Moger, Babu @ 2018-05-07 23:39 UTC (permalink / raw)
To: Eduardo Habkost
Cc: mst, marcel, pbonzini, rth, mtosatti, geoff, kash, qemu-devel, kvm
> -----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].
>
> 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
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH v7 7/9] i386: Add support for CPUID_8000_001E for AMD
2018-05-07 19:39 ` [Qemu-devel] " Eduardo Habkost
@ 2018-05-07 23:44 ` Moger, Babu
-1 siblings, 0 replies; 88+ messages in thread
From: Moger, Babu @ 2018-05-07 23:44 UTC (permalink / raw)
To: Eduardo Habkost
Cc: geoff, kvm, mst, kash, mtosatti, qemu-devel, marcel, pbonzini, rth
> -----Original Message-----
> From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> Sent: Monday, May 7, 2018 2:40 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 7/9] i386: Add support for
> CPUID_8000_001E for AMD
>
> On Thu, Apr 26, 2018 at 11:26:47AM -0500, Babu Moger wrote:
> > Populate threads/core_id/apic_ids/socket_id when CPUID_EXT3_TOPOEXT
> > feature is supported. This is required to support hyperthreading feature
> > on AMD CPUs. This is supported via CPUID_8000_001E extended functions.
> >
> > Signed-off-by: Babu Moger <babu.moger@amd.com>
> > Tested-by: Geoffrey McRae <geoff@hostfission.com>
> > ---
> > target/i386/cpu.c | 14 ++++++++++++++
> > 1 file changed, 14 insertions(+)
> >
> > diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> > index 1024b09..1b15023 100644
> > --- a/target/i386/cpu.c
> > +++ b/target/i386/cpu.c
> > @@ -315,6 +315,12 @@ static uint32_t
> encode_cache_cpuid80000005(CPUCacheInfo *cache)
> > (((CORES_IN_CMPLX - 1) * 2) + 1) : \
> > (CORES_IN_CMPLX - 1))
> >
> > +/* Definitions used on CPUID Leaf 0x8000001E */
> > +#define EXTENDED_APIC_ID(threads, socket_id, core_id, thread_id) \
> > + ((threads) ? \
> > + ((socket_id << 6) | (core_id << 1) | thread_id) : \
> > + ((socket_id << 6) | core_id))
>
> I suggest moving this to i386/topology.h.
Ok. Will do that.
>
>
> > +
> > /*
> > * Encode cache info for CPUID[0x80000006].ECX and
> CPUID[0x80000006].EDX
> > * @l3 can be NULL.
> > @@ -4105,6 +4111,14 @@ void cpu_x86_cpuid(CPUX86State *env,
> uint32_t index, uint32_t count,
> > break;
> > }
> > break;
> > + case 0x8000001E:
> > + assert(cpu->core_id <= 255);
>
> Where's the code that ensures this assert() line can't be
> triggered by any command-line configuration?
I did not understand this. Can you please elaborate. Thanks
>
> > + *eax = EXTENDED_APIC_ID((cs->nr_threads - 1),
> > + cpu->socket_id, cpu->core_id, cpu->thread_id);
> > + *ebx = (cs->nr_threads - 1) << 8 | cpu->core_id;
> > + *ecx = cpu->socket_id;
> > + *edx = 0;
> > + break;
> > case 0xC0000000:
> > *eax = env->cpuid_xlevel2;
> > *ebx = 0;
> > --
> > 2.7.4
> >
> >
>
> --
> Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [Qemu-devel] [PATCH v7 7/9] i386: Add support for CPUID_8000_001E for AMD
@ 2018-05-07 23:44 ` Moger, Babu
0 siblings, 0 replies; 88+ messages in thread
From: Moger, Babu @ 2018-05-07 23:44 UTC (permalink / raw)
To: Eduardo Habkost
Cc: mst, marcel, pbonzini, rth, mtosatti, geoff, kash, qemu-devel, kvm
> -----Original Message-----
> From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> Sent: Monday, May 7, 2018 2:40 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 7/9] i386: Add support for
> CPUID_8000_001E for AMD
>
> On Thu, Apr 26, 2018 at 11:26:47AM -0500, Babu Moger wrote:
> > Populate threads/core_id/apic_ids/socket_id when CPUID_EXT3_TOPOEXT
> > feature is supported. This is required to support hyperthreading feature
> > on AMD CPUs. This is supported via CPUID_8000_001E extended functions.
> >
> > Signed-off-by: Babu Moger <babu.moger@amd.com>
> > Tested-by: Geoffrey McRae <geoff@hostfission.com>
> > ---
> > target/i386/cpu.c | 14 ++++++++++++++
> > 1 file changed, 14 insertions(+)
> >
> > diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> > index 1024b09..1b15023 100644
> > --- a/target/i386/cpu.c
> > +++ b/target/i386/cpu.c
> > @@ -315,6 +315,12 @@ static uint32_t
> encode_cache_cpuid80000005(CPUCacheInfo *cache)
> > (((CORES_IN_CMPLX - 1) * 2) + 1) : \
> > (CORES_IN_CMPLX - 1))
> >
> > +/* Definitions used on CPUID Leaf 0x8000001E */
> > +#define EXTENDED_APIC_ID(threads, socket_id, core_id, thread_id) \
> > + ((threads) ? \
> > + ((socket_id << 6) | (core_id << 1) | thread_id) : \
> > + ((socket_id << 6) | core_id))
>
> I suggest moving this to i386/topology.h.
Ok. Will do that.
>
>
> > +
> > /*
> > * Encode cache info for CPUID[0x80000006].ECX and
> CPUID[0x80000006].EDX
> > * @l3 can be NULL.
> > @@ -4105,6 +4111,14 @@ void cpu_x86_cpuid(CPUX86State *env,
> uint32_t index, uint32_t count,
> > break;
> > }
> > break;
> > + case 0x8000001E:
> > + assert(cpu->core_id <= 255);
>
> Where's the code that ensures this assert() line can't be
> triggered by any command-line configuration?
I did not understand this. Can you please elaborate. Thanks
>
> > + *eax = EXTENDED_APIC_ID((cs->nr_threads - 1),
> > + cpu->socket_id, cpu->core_id, cpu->thread_id);
> > + *ebx = (cs->nr_threads - 1) << 8 | cpu->core_id;
> > + *ecx = cpu->socket_id;
> > + *edx = 0;
> > + break;
> > case 0xC0000000:
> > *eax = env->cpuid_xlevel2;
> > *ebx = 0;
> > --
> > 2.7.4
> >
> >
>
> --
> Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH v7 5/9] i386: Use the statically loaded cache definitions
2018-05-07 23:39 ` [Qemu-devel] " Moger, Babu
@ 2018-05-08 14:12 ` Eduardo Habkost
-1 siblings, 0 replies; 88+ messages in thread
From: Eduardo Habkost @ 2018-05-08 14:12 UTC (permalink / raw)
To: Moger, Babu
Cc: geoff, kvm, mst, kash, mtosatti, qemu-devel, marcel, pbonzini, rth
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
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [Qemu-devel] [PATCH v7 5/9] i386: Use the statically loaded cache definitions
@ 2018-05-08 14:12 ` Eduardo Habkost
0 siblings, 0 replies; 88+ messages in thread
From: Eduardo Habkost @ 2018-05-08 14:12 UTC (permalink / raw)
To: Moger, Babu
Cc: mst, marcel, pbonzini, rth, mtosatti, geoff, kash, qemu-devel, kvm
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
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH v7 7/9] i386: Add support for CPUID_8000_001E for AMD
2018-05-07 23:44 ` [Qemu-devel] " Moger, Babu
@ 2018-05-08 14:16 ` Eduardo Habkost
-1 siblings, 0 replies; 88+ messages in thread
From: Eduardo Habkost @ 2018-05-08 14:16 UTC (permalink / raw)
To: Moger, Babu
Cc: geoff, kvm, mst, kash, mtosatti, qemu-devel, marcel, pbonzini, rth
On Mon, May 07, 2018 at 11:44:31PM +0000, Moger, Babu wrote:
[...]
> > > +
> > > /*
> > > * Encode cache info for CPUID[0x80000006].ECX and
> > CPUID[0x80000006].EDX
> > > * @l3 can be NULL.
> > > @@ -4105,6 +4111,14 @@ void cpu_x86_cpuid(CPUX86State *env,
> > uint32_t index, uint32_t count,
> > > break;
> > > }
> > > break;
> > > + case 0x8000001E:
> > > + assert(cpu->core_id <= 255);
> >
> > Where's the code that ensures this assert() line can't be
> > triggered by any command-line configuration?
>
> I did not understand this. Can you please elaborate. Thanks
The user must not be able to trigger an assert(), so we need to
ensure that core_id will never be larger than 255. Is there
existing code that ensures that?
>
> >
> > > + *eax = EXTENDED_APIC_ID((cs->nr_threads - 1),
> > > + cpu->socket_id, cpu->core_id, cpu->thread_id);
> > > + *ebx = (cs->nr_threads - 1) << 8 | cpu->core_id;
> > > + *ecx = cpu->socket_id;
> > > + *edx = 0;
> > > + break;
> > > case 0xC0000000:
> > > *eax = env->cpuid_xlevel2;
> > > *ebx = 0;
> > > --
> > > 2.7.4
> > >
> > >
> >
> > --
> > Eduardo
--
Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [Qemu-devel] [PATCH v7 7/9] i386: Add support for CPUID_8000_001E for AMD
@ 2018-05-08 14:16 ` Eduardo Habkost
0 siblings, 0 replies; 88+ messages in thread
From: Eduardo Habkost @ 2018-05-08 14:16 UTC (permalink / raw)
To: Moger, Babu
Cc: mst, marcel, pbonzini, rth, mtosatti, geoff, kash, qemu-devel, kvm
On Mon, May 07, 2018 at 11:44:31PM +0000, Moger, Babu wrote:
[...]
> > > +
> > > /*
> > > * Encode cache info for CPUID[0x80000006].ECX and
> > CPUID[0x80000006].EDX
> > > * @l3 can be NULL.
> > > @@ -4105,6 +4111,14 @@ void cpu_x86_cpuid(CPUX86State *env,
> > uint32_t index, uint32_t count,
> > > break;
> > > }
> > > break;
> > > + case 0x8000001E:
> > > + assert(cpu->core_id <= 255);
> >
> > Where's the code that ensures this assert() line can't be
> > triggered by any command-line configuration?
>
> I did not understand this. Can you please elaborate. Thanks
The user must not be able to trigger an assert(), so we need to
ensure that core_id will never be larger than 255. Is there
existing code that ensures that?
>
> >
> > > + *eax = EXTENDED_APIC_ID((cs->nr_threads - 1),
> > > + cpu->socket_id, cpu->core_id, cpu->thread_id);
> > > + *ebx = (cs->nr_threads - 1) << 8 | cpu->core_id;
> > > + *ecx = cpu->socket_id;
> > > + *edx = 0;
> > > + break;
> > > case 0xC0000000:
> > > *eax = env->cpuid_xlevel2;
> > > *ebx = 0;
> > > --
> > > 2.7.4
> > >
> > >
> >
> > --
> > Eduardo
--
Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH v7 4/9] i386: Add new property to control cache info
2018-04-26 16:26 ` [Qemu-devel] " Babu Moger
@ 2018-05-08 14:25 ` Eduardo Habkost
-1 siblings, 0 replies; 88+ messages in thread
From: Eduardo Habkost @ 2018-05-08 14:25 UTC (permalink / raw)
To: Babu Moger
Cc: geoff, kvm, mst, kash, mtosatti, qemu-devel, marcel, pbonzini, rth
On Thu, Apr 26, 2018 at 11:26:44AM -0500, Babu Moger wrote:
> 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.
> It will be "on" for machine type "pc-q35-2.10" for compatibility.
>
> Signed-off-by: Babu Moger <babu.moger@amd.com>
> Tested-by: Geoffrey McRae <geoff@hostfission.com>
> ---
> include/hw/i386/pc.h | 4 ++++
> target/i386/cpu.c | 1 +
> target/i386/cpu.h | 5 +++++
> 3 files changed, 10 insertions(+)
>
> diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> index ffee841..d904a3c 100644
> --- a/include/hw/i386/pc.h
> +++ b/include/hw/i386/pc.h
> @@ -327,6 +327,10 @@ 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 = "on",\
> },
>
> #define PC_COMPAT_2_9 \
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 5d88363..a27b658 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -5138,6 +5138,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),
Hmm, this can get messy if we start adding cache info to other
CPU models in future QEMU versions. e.g.: what if we add cache
info to Opteron_G3 on QEMU 2.14?
I suggest adding this to x86_cpu_load_def():
cpu->legacy_cache = !cpu->cache_info.valid;
(Or equivalent code, in case cache_info is changed to be a
pointer)
This way, only EPYC will have legacy-cache=false by now, making
it easier to write compatibility code for other CPU models in the
future.
>
> /*
> * From "Requirements for Implementing the Microsoft
> diff --git a/target/i386/cpu.h b/target/i386/cpu.h
> index 1213bb7..852586a 100644
> --- a/target/i386/cpu.h
> +++ b/target/i386/cpu.h
> @@ -1395,6 +1395,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;
>
> --
> 2.7.4
>
--
Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [Qemu-devel] [PATCH v7 4/9] i386: Add new property to control cache info
@ 2018-05-08 14:25 ` Eduardo Habkost
0 siblings, 0 replies; 88+ messages in thread
From: Eduardo Habkost @ 2018-05-08 14:25 UTC (permalink / raw)
To: Babu Moger
Cc: mst, marcel, pbonzini, rth, mtosatti, qemu-devel, kvm, kash, geoff
On Thu, Apr 26, 2018 at 11:26:44AM -0500, Babu Moger wrote:
> 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.
> It will be "on" for machine type "pc-q35-2.10" for compatibility.
>
> Signed-off-by: Babu Moger <babu.moger@amd.com>
> Tested-by: Geoffrey McRae <geoff@hostfission.com>
> ---
> include/hw/i386/pc.h | 4 ++++
> target/i386/cpu.c | 1 +
> target/i386/cpu.h | 5 +++++
> 3 files changed, 10 insertions(+)
>
> diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> index ffee841..d904a3c 100644
> --- a/include/hw/i386/pc.h
> +++ b/include/hw/i386/pc.h
> @@ -327,6 +327,10 @@ 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 = "on",\
> },
>
> #define PC_COMPAT_2_9 \
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 5d88363..a27b658 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -5138,6 +5138,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),
Hmm, this can get messy if we start adding cache info to other
CPU models in future QEMU versions. e.g.: what if we add cache
info to Opteron_G3 on QEMU 2.14?
I suggest adding this to x86_cpu_load_def():
cpu->legacy_cache = !cpu->cache_info.valid;
(Or equivalent code, in case cache_info is changed to be a
pointer)
This way, only EPYC will have legacy-cache=false by now, making
it easier to write compatibility code for other CPU models in the
future.
>
> /*
> * From "Requirements for Implementing the Microsoft
> diff --git a/target/i386/cpu.h b/target/i386/cpu.h
> index 1213bb7..852586a 100644
> --- a/target/i386/cpu.h
> +++ b/target/i386/cpu.h
> @@ -1395,6 +1395,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;
>
> --
> 2.7.4
>
--
Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH v7 7/9] i386: Add support for CPUID_8000_001E for AMD
2018-05-08 14:16 ` [Qemu-devel] " Eduardo Habkost
@ 2018-05-08 15:02 ` Moger, Babu
-1 siblings, 0 replies; 88+ messages in thread
From: Moger, Babu @ 2018-05-08 15:02 UTC (permalink / raw)
To: Eduardo Habkost
Cc: geoff, kvm, mst, kash, mtosatti, qemu-devel, marcel, pbonzini, rth
> -----Original Message-----
> From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> Sent: Tuesday, May 8, 2018 9:17 AM
> 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 7/9] i386: Add support for
> CPUID_8000_001E for AMD
>
> On Mon, May 07, 2018 at 11:44:31PM +0000, Moger, Babu wrote:
> [...]
> > > > +
> > > > /*
> > > > * Encode cache info for CPUID[0x80000006].ECX and
> > > CPUID[0x80000006].EDX
> > > > * @l3 can be NULL.
> > > > @@ -4105,6 +4111,14 @@ void cpu_x86_cpuid(CPUX86State *env,
> > > uint32_t index, uint32_t count,
> > > > break;
> > > > }
> > > > break;
> > > > + case 0x8000001E:
> > > > + assert(cpu->core_id <= 255);
> > >
> > > Where's the code that ensures this assert() line can't be
> > > triggered by any command-line configuration?
> >
> > I did not understand this. Can you please elaborate. Thanks
>
> The user must not be able to trigger an assert(), so we need to
> ensure that core_id will never be larger than 255. Is there
> existing code that ensures that?
I see that max_cpus is set to 255 and also there are checks to make sure core_id does not go above 255.
I verified it while testing. So, probably we don't need assert here. Radim asked me to add this assert.
I can remove it if no abjections.
>
> >
> > >
> > > > + *eax = EXTENDED_APIC_ID((cs->nr_threads - 1),
> > > > + cpu->socket_id, cpu->core_id, cpu->thread_id);
> > > > + *ebx = (cs->nr_threads - 1) << 8 | cpu->core_id;
> > > > + *ecx = cpu->socket_id;
> > > > + *edx = 0;
> > > > + break;
> > > > case 0xC0000000:
> > > > *eax = env->cpuid_xlevel2;
> > > > *ebx = 0;
> > > > --
> > > > 2.7.4
> > > >
> > > >
> > >
> > > --
> > > Eduardo
>
> --
> Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [Qemu-devel] [PATCH v7 7/9] i386: Add support for CPUID_8000_001E for AMD
@ 2018-05-08 15:02 ` Moger, Babu
0 siblings, 0 replies; 88+ messages in thread
From: Moger, Babu @ 2018-05-08 15:02 UTC (permalink / raw)
To: Eduardo Habkost
Cc: mst, marcel, pbonzini, rth, mtosatti, geoff, kash, qemu-devel, kvm
> -----Original Message-----
> From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> Sent: Tuesday, May 8, 2018 9:17 AM
> 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 7/9] i386: Add support for
> CPUID_8000_001E for AMD
>
> On Mon, May 07, 2018 at 11:44:31PM +0000, Moger, Babu wrote:
> [...]
> > > > +
> > > > /*
> > > > * Encode cache info for CPUID[0x80000006].ECX and
> > > CPUID[0x80000006].EDX
> > > > * @l3 can be NULL.
> > > > @@ -4105,6 +4111,14 @@ void cpu_x86_cpuid(CPUX86State *env,
> > > uint32_t index, uint32_t count,
> > > > break;
> > > > }
> > > > break;
> > > > + case 0x8000001E:
> > > > + assert(cpu->core_id <= 255);
> > >
> > > Where's the code that ensures this assert() line can't be
> > > triggered by any command-line configuration?
> >
> > I did not understand this. Can you please elaborate. Thanks
>
> The user must not be able to trigger an assert(), so we need to
> ensure that core_id will never be larger than 255. Is there
> existing code that ensures that?
I see that max_cpus is set to 255 and also there are checks to make sure core_id does not go above 255.
I verified it while testing. So, probably we don't need assert here. Radim asked me to add this assert.
I can remove it if no abjections.
>
> >
> > >
> > > > + *eax = EXTENDED_APIC_ID((cs->nr_threads - 1),
> > > > + cpu->socket_id, cpu->core_id, cpu->thread_id);
> > > > + *ebx = (cs->nr_threads - 1) << 8 | cpu->core_id;
> > > > + *ecx = cpu->socket_id;
> > > > + *edx = 0;
> > > > + break;
> > > > case 0xC0000000:
> > > > *eax = env->cpuid_xlevel2;
> > > > *ebx = 0;
> > > > --
> > > > 2.7.4
> > > >
> > > >
> > >
> > > --
> > > Eduardo
>
> --
> Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH v7 6/9] i386: Populate AMD Processor Cache Information for cpuid 0x8000001D
2018-05-07 21:06 ` [Qemu-devel] " Eduardo Habkost
@ 2018-05-08 16:41 ` Moger, Babu
-1 siblings, 0 replies; 88+ messages in thread
From: Moger, Babu @ 2018-05-08 16:41 UTC (permalink / raw)
To: Eduardo Habkost
Cc: geoff, kvm, mst, kash, mtosatti, qemu-devel, marcel, pbonzini, rth
> -----Original Message-----
> From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> Sent: Monday, May 7, 2018 4:07 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 6/9] i386: Populate AMD Processor
> Cache Information for cpuid 0x8000001D
>
> Hi,
>
> Sorry for taking so long to send feedback on this series:
>
> On Thu, Apr 26, 2018 at 11:26:46AM -0500, Babu Moger wrote:
> > Add information for cpuid 0x8000001D leaf. Populate cache topology
> information
> > for different cache types(Data Cache, Instruction Cache, L2 and L3)
> supported
> > by 0x8000001D leaf. Please refer Processor Programming Reference (PPR)
> for AMD
> > Family 17h Model for more details.
> >
> > Signed-off-by: Babu Moger <babu.moger@amd.com>
> > Tested-by: Geoffrey McRae <geoff@hostfission.com>
> > ---
> > target/i386/cpu.c | 92
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > target/i386/kvm.c | 29 ++++++++++++++++--
> > 2 files changed, 118 insertions(+), 3 deletions(-)
> >
> > diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> > index 56d2f0b..1024b09 100644
> > --- a/target/i386/cpu.c
> > +++ b/target/i386/cpu.c
> > @@ -307,6 +307,14 @@ static uint32_t
> encode_cache_cpuid80000005(CPUCacheInfo *cache)
> > a == ASSOC_FULL ? 0xF : \
> > 0 /* invalid value */)
> >
> > +/* Definitions used on CPUID Leaf 0x8000001D */
> > +/* Number of logical cores in a complex */
> > +#define CORES_IN_CMPLX 4
> > +/* Number of logical processors sharing cache */
> > +#define NUM_SHARING_CACHE(threads) (threads ? \
> > + (((CORES_IN_CMPLX - 1) * 2) + 1) : \
> > + (CORES_IN_CMPLX - 1))
> > +
>
> Some questions about these macros:
> * Why CORES_IN_CMPLX is a constant, and we're not using
> nr_cores?
This comes from the hardware design. The maximum cores in core complex is 4.
L3 cache can be shared with 8 threads with 2 threads in each core. Idea here is to mimic the
Hardware as close as possible to get the performance benefit.
You can look at the datasheet https://www.amd.com/system/files/2017-06/AMD-EPYC-Data-Sheet.pdf
and PPR https://support.amd.com/TechDocs/54945_PPR_Family_17h_Models_00h-0Fh.pdf
> * Why "2" is a constant, and we're not using nr_threads?
Yes, I can use nr_threads here. Will change it.
> * Why it's getting nr_threads-1 as argument instead of
> nr_threads?
Yes, I can make that change.
>
> > /*
> > * Encode cache info for CPUID[0x80000006].ECX and
> CPUID[0x80000006].EDX
> > * @l3 can be NULL.
> > @@ -336,6 +344,41 @@ static void
> encode_cache_cpuid80000006(CPUCacheInfo *l2,
> > }
> > }
> >
> > +/* Encode cache info for CPUID[8000001D] */
> > +static void encode_cache_cpuid8000001d(CPUCacheInfo *cache, int
> nr_threads,
> > + uint32_t *eax, uint32_t *ebx,
> > + uint32_t *ecx, uint32_t *edx)
> > +{
> > + assert(cache->size == cache->line_size * cache->associativity *
> > + cache->partitions * cache->sets);
> > +
> > + *eax = CACHE_TYPE(cache->type) | CACHE_LEVEL(cache->level) |
> > + (cache->self_init ? CACHE_SELF_INIT_LEVEL : 0);
> > +
> > + /* L3 is shared among multiple cores */
> > + if (cache->level == 3) {
> > + *eax |= (NUM_SHARING_CACHE(nr_threads - 1) << 14);
>
> Isn't it simpler to write this as:
>
> *eax |= ((nr_cores * nr_threads) - 1) << 14;
Ok. Let me try to simplify this whole code segment.
>
>
> Or, even better:
>
> static void encode_cache_cpuid8000001d(CPUCacheInfo *cache, int
> nr_logical_procs,
> uint32_t *eax, uint32_t *ebx,
> uint32_t *ecx, uint32_t *edx)
> {
> /* ... */
> /* No need to check cache->level here */
> *eax |= (nr_logical_procs - 1) << 14;
> /* ... */
> }
>
> void cpu_x86_cpuid(...)
> {
> /* ... */
> case 0x8000001D:
> switch (count) {
> case 0: /* L1 dcache info */
> /* legacy_cache checks omitted in example for simplicity */
> encode_cache_cpuid8000001d(&env->cache_info.l1d_cache,
> cs->nr_threads,
> eax, ebx, ecx, edx);
> break;
> case 1: /* L1 icache info */
> encode_cache_cpuid8000001d(&env->cache_info.l1i_cache,
> cs->nr_threads,
> eax, ebx, ecx, edx);
> break;
> case 2: /* L2 cache info */
> encode_cache_cpuid8000001d(&env->cache_info.l2_cache,
> cs->nr_threads,
> eax, ebx, ecx, edx);
> break;
> case 3: /* L3 cache info */
> /* L3 is shared among multiple cores */
> encode_cache_cpuid8000001d(&env->cache_info.l3_cache,
> cs->nr_threads * cs->nr_cores,
> eax, ebx, ecx, edx);
> break;
> /* ... */
> }
>
>
> > + } else {
> > + *eax |= ((nr_threads - 1) << 14);
> > + }
> > +
> > + assert(cache->line_size > 0);
> > + assert(cache->partitions > 0);
> > + assert(cache->associativity > 0);
> > + /* We don't implement fully-associative caches */
> > + assert(cache->associativity < cache->sets);
> > + *ebx = (cache->line_size - 1) |
> > + ((cache->partitions - 1) << 12) |
> > + ((cache->associativity - 1) << 22);
> > +
> > + assert(cache->sets > 0);
> > + *ecx = cache->sets - 1;
> > +
> > + *edx = (cache->no_invd_sharing ? CACHE_NO_INVD_SHARING : 0) |
> > + (cache->inclusive ? CACHE_INCLUSIVE : 0) |
> > + (cache->complex_indexing ? CACHE_COMPLEX_IDX : 0);
> > +}
> > +
> > /* Definitions of the hardcoded cache entries we expose: */
> >
> > /* L1 data cache: */
> > @@ -4013,6 +4056,55 @@ void cpu_x86_cpuid(CPUX86State *env,
> uint32_t index, uint32_t count,
> > *edx = 0;
> > }
> > break;
> > + case 0x8000001D:
> > + *eax = 0;
> > + switch (count) {
> > + case 0: /* L1 dcache info */
> > + if (env->cache_info.valid && !cpu->legacy_cache) {
> > + encode_cache_cpuid8000001d(&env->cache_info.l1d_cache,
> > + cs->nr_threads,
> > + eax, ebx, ecx, edx);
> > + } else {
> > + encode_cache_cpuid8000001d(&l1d_cache_amd, cs->nr_threads,
> > + eax, ebx, ecx, edx);
> > + }
> > + break;
> > + case 1: /* L1 icache info */
> > + if (env->cache_info.valid && !cpu->legacy_cache) {
> > + encode_cache_cpuid8000001d(&env->cache_info.l1i_cache,
> > + cs->nr_threads,
> > + eax, ebx, ecx, edx);
> > + } else {
> > + encode_cache_cpuid8000001d(&l1i_cache_amd,
> > + cs->nr_threads,
> > + eax, ebx, ecx, edx);
> > + }
> > + break;
> > + case 2: /* L2 cache info */
> > + if (env->cache_info.valid && !cpu->legacy_cache) {
> > + encode_cache_cpuid8000001d(&env->cache_info.l2_cache,
> > + cs->nr_threads,
> > + eax, ebx, ecx, edx);
> > + } else {
> > + encode_cache_cpuid8000001d(&l2_cache_amd, cs->nr_threads,
> > + eax, ebx, ecx, edx);
> > + }
> > + break;
> > + case 3: /* L3 cache info */
> > + if (env->cache_info.valid && !cpu->legacy_cache) {
> > + encode_cache_cpuid8000001d(&env->cache_info.l3_cache,
> > + cs->nr_threads,
> > + eax, ebx, ecx, edx);
> > + } else {
> > + encode_cache_cpuid8000001d(&l3_cache, cs->nr_threads,
> > + eax, ebx, ecx, edx);
> > + }
> > + break;
> > + default: /* end of info */
> > + *eax = *ebx = *ecx = *edx = 0;
> > + break;
> > + }
> > + break;
> > case 0xC0000000:
> > *eax = env->cpuid_xlevel2;
> > *ebx = 0;
> > diff --git a/target/i386/kvm.c b/target/i386/kvm.c
> > index 6c49954..6e66f9c 100644
> > --- a/target/i386/kvm.c
> > +++ b/target/i386/kvm.c
> > @@ -967,9 +967,32 @@ int kvm_arch_init_vcpu(CPUState *cs)
> > }
> > c = &cpuid_data.entries[cpuid_i++];
> >
> > - c->function = i;
> > - c->flags = 0;
> > - cpu_x86_cpuid(env, i, 0, &c->eax, &c->ebx, &c->ecx, &c->edx);
> > + switch (i) {
> > + case 0x8000001d:
> > + /* Query for all AMD cache information leaves */
> > + for (j = 0; ; j++) {
> > + c->function = i;
> > + c->flags = KVM_CPUID_FLAG_SIGNIFCANT_INDEX;
> > + c->index = j;
> > + cpu_x86_cpuid(env, i, j, &c->eax, &c->ebx, &c->ecx, &c->edx);
> > +
> > + if (c->eax == 0) {
> > + break;
> > + }
> > + if (cpuid_i == KVM_MAX_CPUID_ENTRIES) {
> > + fprintf(stderr, "cpuid_data is full, no space for "
> > + "cpuid(eax:0x%x,ecx:0x%x)\n", i, j);
> > + abort();
> > + }
> > + c = &cpuid_data.entries[cpuid_i++];
> > + }
> > + break;
> > + default:
> > + c->function = i;
> > + c->flags = 0;
> > + cpu_x86_cpuid(env, i, 0, &c->eax, &c->ebx, &c->ecx, &c->edx);
> > + break;
> > + }
> > }
> >
> > /* Call Centaur's CPUID instructions they are supported. */
> > --
> > 2.7.4
> >
> >
>
> --
> Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [Qemu-devel] [PATCH v7 6/9] i386: Populate AMD Processor Cache Information for cpuid 0x8000001D
@ 2018-05-08 16:41 ` Moger, Babu
0 siblings, 0 replies; 88+ messages in thread
From: Moger, Babu @ 2018-05-08 16:41 UTC (permalink / raw)
To: Eduardo Habkost
Cc: mst, marcel, pbonzini, rth, mtosatti, geoff, kash, qemu-devel, kvm
> -----Original Message-----
> From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> Sent: Monday, May 7, 2018 4:07 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 6/9] i386: Populate AMD Processor
> Cache Information for cpuid 0x8000001D
>
> Hi,
>
> Sorry for taking so long to send feedback on this series:
>
> On Thu, Apr 26, 2018 at 11:26:46AM -0500, Babu Moger wrote:
> > Add information for cpuid 0x8000001D leaf. Populate cache topology
> information
> > for different cache types(Data Cache, Instruction Cache, L2 and L3)
> supported
> > by 0x8000001D leaf. Please refer Processor Programming Reference (PPR)
> for AMD
> > Family 17h Model for more details.
> >
> > Signed-off-by: Babu Moger <babu.moger@amd.com>
> > Tested-by: Geoffrey McRae <geoff@hostfission.com>
> > ---
> > target/i386/cpu.c | 92
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > target/i386/kvm.c | 29 ++++++++++++++++--
> > 2 files changed, 118 insertions(+), 3 deletions(-)
> >
> > diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> > index 56d2f0b..1024b09 100644
> > --- a/target/i386/cpu.c
> > +++ b/target/i386/cpu.c
> > @@ -307,6 +307,14 @@ static uint32_t
> encode_cache_cpuid80000005(CPUCacheInfo *cache)
> > a == ASSOC_FULL ? 0xF : \
> > 0 /* invalid value */)
> >
> > +/* Definitions used on CPUID Leaf 0x8000001D */
> > +/* Number of logical cores in a complex */
> > +#define CORES_IN_CMPLX 4
> > +/* Number of logical processors sharing cache */
> > +#define NUM_SHARING_CACHE(threads) (threads ? \
> > + (((CORES_IN_CMPLX - 1) * 2) + 1) : \
> > + (CORES_IN_CMPLX - 1))
> > +
>
> Some questions about these macros:
> * Why CORES_IN_CMPLX is a constant, and we're not using
> nr_cores?
This comes from the hardware design. The maximum cores in core complex is 4.
L3 cache can be shared with 8 threads with 2 threads in each core. Idea here is to mimic the
Hardware as close as possible to get the performance benefit.
You can look at the datasheet https://www.amd.com/system/files/2017-06/AMD-EPYC-Data-Sheet.pdf
and PPR https://support.amd.com/TechDocs/54945_PPR_Family_17h_Models_00h-0Fh.pdf
> * Why "2" is a constant, and we're not using nr_threads?
Yes, I can use nr_threads here. Will change it.
> * Why it's getting nr_threads-1 as argument instead of
> nr_threads?
Yes, I can make that change.
>
> > /*
> > * Encode cache info for CPUID[0x80000006].ECX and
> CPUID[0x80000006].EDX
> > * @l3 can be NULL.
> > @@ -336,6 +344,41 @@ static void
> encode_cache_cpuid80000006(CPUCacheInfo *l2,
> > }
> > }
> >
> > +/* Encode cache info for CPUID[8000001D] */
> > +static void encode_cache_cpuid8000001d(CPUCacheInfo *cache, int
> nr_threads,
> > + uint32_t *eax, uint32_t *ebx,
> > + uint32_t *ecx, uint32_t *edx)
> > +{
> > + assert(cache->size == cache->line_size * cache->associativity *
> > + cache->partitions * cache->sets);
> > +
> > + *eax = CACHE_TYPE(cache->type) | CACHE_LEVEL(cache->level) |
> > + (cache->self_init ? CACHE_SELF_INIT_LEVEL : 0);
> > +
> > + /* L3 is shared among multiple cores */
> > + if (cache->level == 3) {
> > + *eax |= (NUM_SHARING_CACHE(nr_threads - 1) << 14);
>
> Isn't it simpler to write this as:
>
> *eax |= ((nr_cores * nr_threads) - 1) << 14;
Ok. Let me try to simplify this whole code segment.
>
>
> Or, even better:
>
> static void encode_cache_cpuid8000001d(CPUCacheInfo *cache, int
> nr_logical_procs,
> uint32_t *eax, uint32_t *ebx,
> uint32_t *ecx, uint32_t *edx)
> {
> /* ... */
> /* No need to check cache->level here */
> *eax |= (nr_logical_procs - 1) << 14;
> /* ... */
> }
>
> void cpu_x86_cpuid(...)
> {
> /* ... */
> case 0x8000001D:
> switch (count) {
> case 0: /* L1 dcache info */
> /* legacy_cache checks omitted in example for simplicity */
> encode_cache_cpuid8000001d(&env->cache_info.l1d_cache,
> cs->nr_threads,
> eax, ebx, ecx, edx);
> break;
> case 1: /* L1 icache info */
> encode_cache_cpuid8000001d(&env->cache_info.l1i_cache,
> cs->nr_threads,
> eax, ebx, ecx, edx);
> break;
> case 2: /* L2 cache info */
> encode_cache_cpuid8000001d(&env->cache_info.l2_cache,
> cs->nr_threads,
> eax, ebx, ecx, edx);
> break;
> case 3: /* L3 cache info */
> /* L3 is shared among multiple cores */
> encode_cache_cpuid8000001d(&env->cache_info.l3_cache,
> cs->nr_threads * cs->nr_cores,
> eax, ebx, ecx, edx);
> break;
> /* ... */
> }
>
>
> > + } else {
> > + *eax |= ((nr_threads - 1) << 14);
> > + }
> > +
> > + assert(cache->line_size > 0);
> > + assert(cache->partitions > 0);
> > + assert(cache->associativity > 0);
> > + /* We don't implement fully-associative caches */
> > + assert(cache->associativity < cache->sets);
> > + *ebx = (cache->line_size - 1) |
> > + ((cache->partitions - 1) << 12) |
> > + ((cache->associativity - 1) << 22);
> > +
> > + assert(cache->sets > 0);
> > + *ecx = cache->sets - 1;
> > +
> > + *edx = (cache->no_invd_sharing ? CACHE_NO_INVD_SHARING : 0) |
> > + (cache->inclusive ? CACHE_INCLUSIVE : 0) |
> > + (cache->complex_indexing ? CACHE_COMPLEX_IDX : 0);
> > +}
> > +
> > /* Definitions of the hardcoded cache entries we expose: */
> >
> > /* L1 data cache: */
> > @@ -4013,6 +4056,55 @@ void cpu_x86_cpuid(CPUX86State *env,
> uint32_t index, uint32_t count,
> > *edx = 0;
> > }
> > break;
> > + case 0x8000001D:
> > + *eax = 0;
> > + switch (count) {
> > + case 0: /* L1 dcache info */
> > + if (env->cache_info.valid && !cpu->legacy_cache) {
> > + encode_cache_cpuid8000001d(&env->cache_info.l1d_cache,
> > + cs->nr_threads,
> > + eax, ebx, ecx, edx);
> > + } else {
> > + encode_cache_cpuid8000001d(&l1d_cache_amd, cs->nr_threads,
> > + eax, ebx, ecx, edx);
> > + }
> > + break;
> > + case 1: /* L1 icache info */
> > + if (env->cache_info.valid && !cpu->legacy_cache) {
> > + encode_cache_cpuid8000001d(&env->cache_info.l1i_cache,
> > + cs->nr_threads,
> > + eax, ebx, ecx, edx);
> > + } else {
> > + encode_cache_cpuid8000001d(&l1i_cache_amd,
> > + cs->nr_threads,
> > + eax, ebx, ecx, edx);
> > + }
> > + break;
> > + case 2: /* L2 cache info */
> > + if (env->cache_info.valid && !cpu->legacy_cache) {
> > + encode_cache_cpuid8000001d(&env->cache_info.l2_cache,
> > + cs->nr_threads,
> > + eax, ebx, ecx, edx);
> > + } else {
> > + encode_cache_cpuid8000001d(&l2_cache_amd, cs->nr_threads,
> > + eax, ebx, ecx, edx);
> > + }
> > + break;
> > + case 3: /* L3 cache info */
> > + if (env->cache_info.valid && !cpu->legacy_cache) {
> > + encode_cache_cpuid8000001d(&env->cache_info.l3_cache,
> > + cs->nr_threads,
> > + eax, ebx, ecx, edx);
> > + } else {
> > + encode_cache_cpuid8000001d(&l3_cache, cs->nr_threads,
> > + eax, ebx, ecx, edx);
> > + }
> > + break;
> > + default: /* end of info */
> > + *eax = *ebx = *ecx = *edx = 0;
> > + break;
> > + }
> > + break;
> > case 0xC0000000:
> > *eax = env->cpuid_xlevel2;
> > *ebx = 0;
> > diff --git a/target/i386/kvm.c b/target/i386/kvm.c
> > index 6c49954..6e66f9c 100644
> > --- a/target/i386/kvm.c
> > +++ b/target/i386/kvm.c
> > @@ -967,9 +967,32 @@ int kvm_arch_init_vcpu(CPUState *cs)
> > }
> > c = &cpuid_data.entries[cpuid_i++];
> >
> > - c->function = i;
> > - c->flags = 0;
> > - cpu_x86_cpuid(env, i, 0, &c->eax, &c->ebx, &c->ecx, &c->edx);
> > + switch (i) {
> > + case 0x8000001d:
> > + /* Query for all AMD cache information leaves */
> > + for (j = 0; ; j++) {
> > + c->function = i;
> > + c->flags = KVM_CPUID_FLAG_SIGNIFCANT_INDEX;
> > + c->index = j;
> > + cpu_x86_cpuid(env, i, j, &c->eax, &c->ebx, &c->ecx, &c->edx);
> > +
> > + if (c->eax == 0) {
> > + break;
> > + }
> > + if (cpuid_i == KVM_MAX_CPUID_ENTRIES) {
> > + fprintf(stderr, "cpuid_data is full, no space for "
> > + "cpuid(eax:0x%x,ecx:0x%x)\n", i, j);
> > + abort();
> > + }
> > + c = &cpuid_data.entries[cpuid_i++];
> > + }
> > + break;
> > + default:
> > + c->function = i;
> > + c->flags = 0;
> > + cpu_x86_cpuid(env, i, 0, &c->eax, &c->ebx, &c->ecx, &c->edx);
> > + break;
> > + }
> > }
> >
> > /* Call Centaur's CPUID instructions they are supported. */
> > --
> > 2.7.4
> >
> >
>
> --
> Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH v7 5/9] i386: Use the statically loaded cache definitions
2018-05-08 14:12 ` [Qemu-devel] " Eduardo Habkost
@ 2018-05-08 17:08 ` Moger, Babu
-1 siblings, 0 replies; 88+ messages in thread
From: Moger, Babu @ 2018-05-08 17:08 UTC (permalink / raw)
To: Eduardo Habkost
Cc: geoff, kvm, mst, kash, mtosatti, qemu-devel, marcel, pbonzini, rth
> -----Original Message-----
> From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> Sent: Tuesday, May 8, 2018 9:12 AM
> 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 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.
Ok. Will make those changes. Will check for cache_info pointer and legacy_cache like we do for 0x80000005.
>
> >
> > >
> > > 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
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [Qemu-devel] [PATCH v7 5/9] i386: Use the statically loaded cache definitions
@ 2018-05-08 17:08 ` Moger, Babu
0 siblings, 0 replies; 88+ messages in thread
From: Moger, Babu @ 2018-05-08 17:08 UTC (permalink / raw)
To: Eduardo Habkost
Cc: mst, marcel, pbonzini, rth, mtosatti, geoff, kash, qemu-devel, kvm
> -----Original Message-----
> From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> Sent: Tuesday, May 8, 2018 9:12 AM
> 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 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.
Ok. Will make those changes. Will check for cache_info pointer and legacy_cache like we do for 0x80000005.
>
> >
> > >
> > > 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
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH v7 4/9] i386: Add new property to control cache info
2018-05-08 14:25 ` [Qemu-devel] " Eduardo Habkost
@ 2018-05-08 17:26 ` Moger, Babu
-1 siblings, 0 replies; 88+ messages in thread
From: Moger, Babu @ 2018-05-08 17:26 UTC (permalink / raw)
To: Eduardo Habkost
Cc: geoff, kvm, mst, kash, mtosatti, qemu-devel, marcel, pbonzini, rth
> -----Original Message-----
> From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> Sent: Tuesday, May 8, 2018 9:26 AM
> To: Moger, Babu <Babu.Moger@amd.com>
> Cc: mst@redhat.com; marcel@redhat.com; pbonzini@redhat.com;
> rth@twiddle.net; mtosatti@redhat.com; qemu-devel@nongnu.org;
> kvm@vger.kernel.org; kash@tripleback.net; geoff@hostfission.com
> Subject: Re: [PATCH v7 4/9] i386: Add new property to control cache info
>
> On Thu, Apr 26, 2018 at 11:26:44AM -0500, Babu Moger wrote:
> > 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.
> > It will be "on" for machine type "pc-q35-2.10" for compatibility.
> >
> > Signed-off-by: Babu Moger <babu.moger@amd.com>
> > Tested-by: Geoffrey McRae <geoff@hostfission.com>
> > ---
> > include/hw/i386/pc.h | 4 ++++
> > target/i386/cpu.c | 1 +
> > target/i386/cpu.h | 5 +++++
> > 3 files changed, 10 insertions(+)
> >
> > diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> > index ffee841..d904a3c 100644
> > --- a/include/hw/i386/pc.h
> > +++ b/include/hw/i386/pc.h
> > @@ -327,6 +327,10 @@ 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 = "on",\
> > },
>
> >
> > #define PC_COMPAT_2_9 \
> > diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> > index 5d88363..a27b658 100644
> > --- a/target/i386/cpu.c
> > +++ b/target/i386/cpu.c
> > @@ -5138,6 +5138,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),
Ok. I will remove this about line and add below code in x86_cpu_load_def.
>
>
> Hmm, this can get messy if we start adding cache info to other
> CPU models in future QEMU versions. e.g.: what if we add cache
> info to Opteron_G3 on QEMU 2.14?
>
> I suggest adding this to x86_cpu_load_def():
>
> cpu->legacy_cache = !cpu->cache_info.valid;
>
> (Or equivalent code, in case cache_info is changed to be a
> pointer)
>
> This way, only EPYC will have legacy-cache=false by now, making
> it easier to write compatibility code for other CPU models in the
> future.
>
>
> >
> > /*
> > * From "Requirements for Implementing the Microsoft
> > diff --git a/target/i386/cpu.h b/target/i386/cpu.h
> > index 1213bb7..852586a 100644
> > --- a/target/i386/cpu.h
> > +++ b/target/i386/cpu.h
> > @@ -1395,6 +1395,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;
> >
> > --
> > 2.7.4
> >
>
> --
> Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [Qemu-devel] [PATCH v7 4/9] i386: Add new property to control cache info
@ 2018-05-08 17:26 ` Moger, Babu
0 siblings, 0 replies; 88+ messages in thread
From: Moger, Babu @ 2018-05-08 17:26 UTC (permalink / raw)
To: Eduardo Habkost
Cc: mst, marcel, pbonzini, rth, mtosatti, qemu-devel, kvm, kash, geoff
> -----Original Message-----
> From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> Sent: Tuesday, May 8, 2018 9:26 AM
> To: Moger, Babu <Babu.Moger@amd.com>
> Cc: mst@redhat.com; marcel@redhat.com; pbonzini@redhat.com;
> rth@twiddle.net; mtosatti@redhat.com; qemu-devel@nongnu.org;
> kvm@vger.kernel.org; kash@tripleback.net; geoff@hostfission.com
> Subject: Re: [PATCH v7 4/9] i386: Add new property to control cache info
>
> On Thu, Apr 26, 2018 at 11:26:44AM -0500, Babu Moger wrote:
> > 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.
> > It will be "on" for machine type "pc-q35-2.10" for compatibility.
> >
> > Signed-off-by: Babu Moger <babu.moger@amd.com>
> > Tested-by: Geoffrey McRae <geoff@hostfission.com>
> > ---
> > include/hw/i386/pc.h | 4 ++++
> > target/i386/cpu.c | 1 +
> > target/i386/cpu.h | 5 +++++
> > 3 files changed, 10 insertions(+)
> >
> > diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> > index ffee841..d904a3c 100644
> > --- a/include/hw/i386/pc.h
> > +++ b/include/hw/i386/pc.h
> > @@ -327,6 +327,10 @@ 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 = "on",\
> > },
>
> >
> > #define PC_COMPAT_2_9 \
> > diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> > index 5d88363..a27b658 100644
> > --- a/target/i386/cpu.c
> > +++ b/target/i386/cpu.c
> > @@ -5138,6 +5138,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),
Ok. I will remove this about line and add below code in x86_cpu_load_def.
>
>
> Hmm, this can get messy if we start adding cache info to other
> CPU models in future QEMU versions. e.g.: what if we add cache
> info to Opteron_G3 on QEMU 2.14?
>
> I suggest adding this to x86_cpu_load_def():
>
> cpu->legacy_cache = !cpu->cache_info.valid;
>
> (Or equivalent code, in case cache_info is changed to be a
> pointer)
>
> This way, only EPYC will have legacy-cache=false by now, making
> it easier to write compatibility code for other CPU models in the
> future.
>
>
> >
> > /*
> > * From "Requirements for Implementing the Microsoft
> > diff --git a/target/i386/cpu.h b/target/i386/cpu.h
> > index 1213bb7..852586a 100644
> > --- a/target/i386/cpu.h
> > +++ b/target/i386/cpu.h
> > @@ -1395,6 +1395,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;
> >
> > --
> > 2.7.4
> >
>
> --
> Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH v7 4/9] i386: Add new property to control cache info
2018-05-08 17:26 ` [Qemu-devel] " Moger, Babu
@ 2018-05-08 18:33 ` Eduardo Habkost
-1 siblings, 0 replies; 88+ messages in thread
From: Eduardo Habkost @ 2018-05-08 18:33 UTC (permalink / raw)
To: Moger, Babu
Cc: geoff, kvm, mst, kash, mtosatti, qemu-devel, marcel, pbonzini, rth
On Tue, May 08, 2018 at 05:26:16PM +0000, Moger, Babu wrote:
>
>
> > -----Original Message-----
> > From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> > Sent: Tuesday, May 8, 2018 9:26 AM
> > To: Moger, Babu <Babu.Moger@amd.com>
> > Cc: mst@redhat.com; marcel@redhat.com; pbonzini@redhat.com;
> > rth@twiddle.net; mtosatti@redhat.com; qemu-devel@nongnu.org;
> > kvm@vger.kernel.org; kash@tripleback.net; geoff@hostfission.com
> > Subject: Re: [PATCH v7 4/9] i386: Add new property to control cache info
> >
> > On Thu, Apr 26, 2018 at 11:26:44AM -0500, Babu Moger wrote:
> > > 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.
> > > It will be "on" for machine type "pc-q35-2.10" for compatibility.
> > >
> > > Signed-off-by: Babu Moger <babu.moger@amd.com>
> > > Tested-by: Geoffrey McRae <geoff@hostfission.com>
> > > ---
> > > include/hw/i386/pc.h | 4 ++++
> > > target/i386/cpu.c | 1 +
> > > target/i386/cpu.h | 5 +++++
> > > 3 files changed, 10 insertions(+)
> > >
> > > diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> > > index ffee841..d904a3c 100644
> > > --- a/include/hw/i386/pc.h
> > > +++ b/include/hw/i386/pc.h
> > > @@ -327,6 +327,10 @@ 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 = "on",\
> > > },
> >
> > >
> > > #define PC_COMPAT_2_9 \
> > > diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> > > index 5d88363..a27b658 100644
> > > --- a/target/i386/cpu.c
> > > +++ b/target/i386/cpu.c
> > > @@ -5138,6 +5138,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),
>
> Ok. I will remove this about line and add below code in x86_cpu_load_def.
You need this line forthe PC_COMPAT_* entry to work.
But in this case, the default here won't matter because it will
be overwritten by x86_cpu_load_def(). So it's a good idea to add
a comment noting that the default will depend on the CPU model
being chosen, and point people to x86_cpu_load_def()).
>
> >
> >
> > Hmm, this can get messy if we start adding cache info to other
> > CPU models in future QEMU versions. e.g.: what if we add cache
> > info to Opteron_G3 on QEMU 2.14?
> >
> > I suggest adding this to x86_cpu_load_def():
> >
> > cpu->legacy_cache = !cpu->cache_info.valid;
> >
> > (Or equivalent code, in case cache_info is changed to be a
> > pointer)
> >
> > This way, only EPYC will have legacy-cache=false by now, making
> > it easier to write compatibility code for other CPU models in the
> > future.
> >
> >
> > >
> > > /*
> > > * From "Requirements for Implementing the Microsoft
> > > diff --git a/target/i386/cpu.h b/target/i386/cpu.h
> > > index 1213bb7..852586a 100644
> > > --- a/target/i386/cpu.h
> > > +++ b/target/i386/cpu.h
> > > @@ -1395,6 +1395,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;
> > >
> > > --
> > > 2.7.4
> > >
> >
> > --
> > Eduardo
--
Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [Qemu-devel] [PATCH v7 4/9] i386: Add new property to control cache info
@ 2018-05-08 18:33 ` Eduardo Habkost
0 siblings, 0 replies; 88+ messages in thread
From: Eduardo Habkost @ 2018-05-08 18:33 UTC (permalink / raw)
To: Moger, Babu
Cc: mst, marcel, pbonzini, rth, mtosatti, qemu-devel, kvm, kash, geoff
On Tue, May 08, 2018 at 05:26:16PM +0000, Moger, Babu wrote:
>
>
> > -----Original Message-----
> > From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> > Sent: Tuesday, May 8, 2018 9:26 AM
> > To: Moger, Babu <Babu.Moger@amd.com>
> > Cc: mst@redhat.com; marcel@redhat.com; pbonzini@redhat.com;
> > rth@twiddle.net; mtosatti@redhat.com; qemu-devel@nongnu.org;
> > kvm@vger.kernel.org; kash@tripleback.net; geoff@hostfission.com
> > Subject: Re: [PATCH v7 4/9] i386: Add new property to control cache info
> >
> > On Thu, Apr 26, 2018 at 11:26:44AM -0500, Babu Moger wrote:
> > > 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.
> > > It will be "on" for machine type "pc-q35-2.10" for compatibility.
> > >
> > > Signed-off-by: Babu Moger <babu.moger@amd.com>
> > > Tested-by: Geoffrey McRae <geoff@hostfission.com>
> > > ---
> > > include/hw/i386/pc.h | 4 ++++
> > > target/i386/cpu.c | 1 +
> > > target/i386/cpu.h | 5 +++++
> > > 3 files changed, 10 insertions(+)
> > >
> > > diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> > > index ffee841..d904a3c 100644
> > > --- a/include/hw/i386/pc.h
> > > +++ b/include/hw/i386/pc.h
> > > @@ -327,6 +327,10 @@ 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 = "on",\
> > > },
> >
> > >
> > > #define PC_COMPAT_2_9 \
> > > diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> > > index 5d88363..a27b658 100644
> > > --- a/target/i386/cpu.c
> > > +++ b/target/i386/cpu.c
> > > @@ -5138,6 +5138,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),
>
> Ok. I will remove this about line and add below code in x86_cpu_load_def.
You need this line forthe PC_COMPAT_* entry to work.
But in this case, the default here won't matter because it will
be overwritten by x86_cpu_load_def(). So it's a good idea to add
a comment noting that the default will depend on the CPU model
being chosen, and point people to x86_cpu_load_def()).
>
> >
> >
> > Hmm, this can get messy if we start adding cache info to other
> > CPU models in future QEMU versions. e.g.: what if we add cache
> > info to Opteron_G3 on QEMU 2.14?
> >
> > I suggest adding this to x86_cpu_load_def():
> >
> > cpu->legacy_cache = !cpu->cache_info.valid;
> >
> > (Or equivalent code, in case cache_info is changed to be a
> > pointer)
> >
> > This way, only EPYC will have legacy-cache=false by now, making
> > it easier to write compatibility code for other CPU models in the
> > future.
> >
> >
> > >
> > > /*
> > > * From "Requirements for Implementing the Microsoft
> > > diff --git a/target/i386/cpu.h b/target/i386/cpu.h
> > > index 1213bb7..852586a 100644
> > > --- a/target/i386/cpu.h
> > > +++ b/target/i386/cpu.h
> > > @@ -1395,6 +1395,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;
> > >
> > > --
> > > 2.7.4
> > >
> >
> > --
> > Eduardo
--
Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH v7 1/9] i386: Helpers to encode cache information consistently
2018-05-07 22:47 ` [Qemu-devel] " Moger, Babu
@ 2018-05-08 18:40 ` Moger, Babu
-1 siblings, 0 replies; 88+ messages in thread
From: Moger, Babu @ 2018-05-08 18:40 UTC (permalink / raw)
To: Eduardo Habkost
Cc: geoff, kvm, mst, kash, mtosatti, qemu-devel, marcel, pbonzini, rth
Hi Eduardo, One more comment below.
> -----Original Message-----
> From: kvm-owner@vger.kernel.org [mailto:kvm-owner@vger.kernel.org]
> On Behalf Of Moger, Babu
> Sent: Monday, May 7, 2018 5:48 PM
> To: Eduardo Habkost <ehabkost@redhat.com>
> Cc: geoff@hostfission.com; kvm@vger.kernel.org; mst@redhat.com;
> kash@tripleback.net; mtosatti@redhat.com; qemu-devel@nongnu.org;
> marcel@redhat.com; pbonzini@redhat.com; rth@twiddle.net
> Subject: RE: [Qemu-devel] [PATCH v7 1/9] i386: Helpers to encode cache
> information consistently
>
>
>
> > -----Original Message-----
> > From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> > Sent: Monday, May 7, 2018 4:27 PM
> > To: Moger, Babu <Babu.Moger@amd.com>
> > Cc: geoff@hostfission.com; kvm@vger.kernel.org; mst@redhat.com;
> > kash@tripleback.net; mtosatti@redhat.com; qemu-devel@nongnu.org;
> > marcel@redhat.com; pbonzini@redhat.com; rth@twiddle.net
> > Subject: Re: [Qemu-devel] [PATCH v7 1/9] i386: Helpers to encode cache
> > information consistently
> >
> > On Mon, May 07, 2018 at 09:14:27PM +0000, Moger, Babu wrote:
> > > Eduardo,
> > > Thanks for all the comments. Will respond to each one separately.
> > >
> > > > -----Original Message-----
> > > > From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> > > > Sent: Monday, May 7, 2018 2:05 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 1/9] i386: Helpers to encode
> cache
> > > > information consistently
> > > >
> > > > Hi,
> > > >
> > > > I was about to apply this because I assumed it was the same patch
> > > > I sent in March, but then I found this:
> > > >
> > > > On Thu, Apr 26, 2018 at 11:26:41AM -0500, Babu Moger wrote:
> > > > > From: Eduardo Habkost <ehabkost@redhat.com>
> > > > >
> > > > > Instead of having a collection of macros that need to be used in
> > > > > complex expressions to build CPUID data, define a CPUCacheInfo
> > > > > struct that can hold information about a given cache. Helper
> > > > > functions will take a CPUCacheInfo struct as input to encode
> > > > > CPUID leaves for a cache.
> > > > >
> > > > > This will help us ensure consistency between cache information
> > > > > CPUID leaves, and make the existing inconsistencies in CPUID info
> > > > > more visible.
> > > > >
> > > > > Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> > > > > Signed-off-by: Babu Moger <babu.moger@amd.com>
> > > > > Tested-by: Geoffrey McRae <geoff@hostfission.com>
> > > > [...]
> > > > > -#define L2_ASSOCIATIVITY 16
> > > > [...]
> > > > > /*FIXME: CPUID leaf 0x80000006 is inconsistent with leaves 2 & 4 */
> > > > > +static CPUCacheInfo l2_cache_amd = {
> > > > [...]
> > > > > + .associativity = 8,
> > > > [...]
> > > > > +};
> > > > [...]
> > > > > case 0x80000006:
> > > > [...]
> > > > > - *ecx = (L2_SIZE_KB_AMD << 16) | \
> > > > > - (AMD_ENC_ASSOC(L2_ASSOCIATIVITY) << 12) | \
> > > > > - (L2_LINES_PER_TAG << 8) | (L2_LINE_SIZE);
> > > > [...]
> > > > > + encode_cache_cpuid80000006(&l2_cache_amd,
> > > > > + cpu->enable_l3_cache ? &l3_cache : NULL,
> > > > > + ecx, edx);
> > > > [...]
> > > >
> > > > The structs added by this patch are supposed to represent the
> > > > legacy cache sizes, and must match the old code. My original
> > > > patch set l2_cache_amd.associativity=16 because of that.
> > > >
> > > > This patch changes 0x80000006 from associativity=16 to
> > > > associativity=8. Why?
Keeping this to 16 will be a problem. It breaks the size rule(line size *associativity * partitions * sets).
It asserts violating that rule. Now I remember. That is why I changed it to 8. I would think it would be
better to fix it now.
> > >
> > > The original code had a bug here. The associativity should have been 8.
> > > My earlier response from the thread
> > > http://patchwork.ozlabs.org/patch/884880/
> > >
> > > This should have been 8-way. This is a bug. Will fix.
> > > This should have been (AMD_ENC_ASSOC(L2_ASSOCIATIVITY_AMD) <<
> > 12)
> >
> > If we want to change the associativity, we must keep the old
> > values on older machine-types, which was the whole purpose of the
> > "legacy-cache" property.
> >
> > I suggest using the new X86CPUDefinition::cache_info field if you
> > want to make AMD CPUs report different associativity.
>
> Ok. Sure. I will change it. Thanks
>
> >
> > --
> > Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [Qemu-devel] [PATCH v7 1/9] i386: Helpers to encode cache information consistently
@ 2018-05-08 18:40 ` Moger, Babu
0 siblings, 0 replies; 88+ messages in thread
From: Moger, Babu @ 2018-05-08 18:40 UTC (permalink / raw)
To: Eduardo Habkost
Cc: geoff, kvm, mst, kash, mtosatti, qemu-devel, marcel, pbonzini, rth
Hi Eduardo, One more comment below.
> -----Original Message-----
> From: kvm-owner@vger.kernel.org [mailto:kvm-owner@vger.kernel.org]
> On Behalf Of Moger, Babu
> Sent: Monday, May 7, 2018 5:48 PM
> To: Eduardo Habkost <ehabkost@redhat.com>
> Cc: geoff@hostfission.com; kvm@vger.kernel.org; mst@redhat.com;
> kash@tripleback.net; mtosatti@redhat.com; qemu-devel@nongnu.org;
> marcel@redhat.com; pbonzini@redhat.com; rth@twiddle.net
> Subject: RE: [Qemu-devel] [PATCH v7 1/9] i386: Helpers to encode cache
> information consistently
>
>
>
> > -----Original Message-----
> > From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> > Sent: Monday, May 7, 2018 4:27 PM
> > To: Moger, Babu <Babu.Moger@amd.com>
> > Cc: geoff@hostfission.com; kvm@vger.kernel.org; mst@redhat.com;
> > kash@tripleback.net; mtosatti@redhat.com; qemu-devel@nongnu.org;
> > marcel@redhat.com; pbonzini@redhat.com; rth@twiddle.net
> > Subject: Re: [Qemu-devel] [PATCH v7 1/9] i386: Helpers to encode cache
> > information consistently
> >
> > On Mon, May 07, 2018 at 09:14:27PM +0000, Moger, Babu wrote:
> > > Eduardo,
> > > Thanks for all the comments. Will respond to each one separately.
> > >
> > > > -----Original Message-----
> > > > From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> > > > Sent: Monday, May 7, 2018 2:05 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 1/9] i386: Helpers to encode
> cache
> > > > information consistently
> > > >
> > > > Hi,
> > > >
> > > > I was about to apply this because I assumed it was the same patch
> > > > I sent in March, but then I found this:
> > > >
> > > > On Thu, Apr 26, 2018 at 11:26:41AM -0500, Babu Moger wrote:
> > > > > From: Eduardo Habkost <ehabkost@redhat.com>
> > > > >
> > > > > Instead of having a collection of macros that need to be used in
> > > > > complex expressions to build CPUID data, define a CPUCacheInfo
> > > > > struct that can hold information about a given cache. Helper
> > > > > functions will take a CPUCacheInfo struct as input to encode
> > > > > CPUID leaves for a cache.
> > > > >
> > > > > This will help us ensure consistency between cache information
> > > > > CPUID leaves, and make the existing inconsistencies in CPUID info
> > > > > more visible.
> > > > >
> > > > > Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> > > > > Signed-off-by: Babu Moger <babu.moger@amd.com>
> > > > > Tested-by: Geoffrey McRae <geoff@hostfission.com>
> > > > [...]
> > > > > -#define L2_ASSOCIATIVITY 16
> > > > [...]
> > > > > /*FIXME: CPUID leaf 0x80000006 is inconsistent with leaves 2 & 4 */
> > > > > +static CPUCacheInfo l2_cache_amd = {
> > > > [...]
> > > > > + .associativity = 8,
> > > > [...]
> > > > > +};
> > > > [...]
> > > > > case 0x80000006:
> > > > [...]
> > > > > - *ecx = (L2_SIZE_KB_AMD << 16) | \
> > > > > - (AMD_ENC_ASSOC(L2_ASSOCIATIVITY) << 12) | \
> > > > > - (L2_LINES_PER_TAG << 8) | (L2_LINE_SIZE);
> > > > [...]
> > > > > + encode_cache_cpuid80000006(&l2_cache_amd,
> > > > > + cpu->enable_l3_cache ? &l3_cache : NULL,
> > > > > + ecx, edx);
> > > > [...]
> > > >
> > > > The structs added by this patch are supposed to represent the
> > > > legacy cache sizes, and must match the old code. My original
> > > > patch set l2_cache_amd.associativity=16 because of that.
> > > >
> > > > This patch changes 0x80000006 from associativity=16 to
> > > > associativity=8. Why?
Keeping this to 16 will be a problem. It breaks the size rule(line size *associativity * partitions * sets).
It asserts violating that rule. Now I remember. That is why I changed it to 8. I would think it would be
better to fix it now.
> > >
> > > The original code had a bug here. The associativity should have been 8.
> > > My earlier response from the thread
> > > http://patchwork.ozlabs.org/patch/884880/
> > >
> > > This should have been 8-way. This is a bug. Will fix.
> > > This should have been (AMD_ENC_ASSOC(L2_ASSOCIATIVITY_AMD) <<
> > 12)
> >
> > If we want to change the associativity, we must keep the old
> > values on older machine-types, which was the whole purpose of the
> > "legacy-cache" property.
> >
> > I suggest using the new X86CPUDefinition::cache_info field if you
> > want to make AMD CPUs report different associativity.
>
> Ok. Sure. I will change it. Thanks
>
> >
> > --
> > Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH v7 4/9] i386: Add new property to control cache info
2018-05-08 18:33 ` [Qemu-devel] " Eduardo Habkost
@ 2018-05-08 18:44 ` Moger, Babu
-1 siblings, 0 replies; 88+ messages in thread
From: Moger, Babu @ 2018-05-08 18:44 UTC (permalink / raw)
To: Eduardo Habkost
Cc: geoff, kvm, mst, kash, mtosatti, qemu-devel, marcel, pbonzini, rth
> -----Original Message-----
> From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> Sent: Tuesday, May 8, 2018 1:34 PM
> To: Moger, Babu <Babu.Moger@amd.com>
> Cc: mst@redhat.com; marcel@redhat.com; pbonzini@redhat.com;
> rth@twiddle.net; mtosatti@redhat.com; qemu-devel@nongnu.org;
> kvm@vger.kernel.org; kash@tripleback.net; geoff@hostfission.com
> Subject: Re: [PATCH v7 4/9] i386: Add new property to control cache info
>
> On Tue, May 08, 2018 at 05:26:16PM +0000, Moger, Babu wrote:
> >
> >
> > > -----Original Message-----
> > > From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> > > Sent: Tuesday, May 8, 2018 9:26 AM
> > > To: Moger, Babu <Babu.Moger@amd.com>
> > > Cc: mst@redhat.com; marcel@redhat.com; pbonzini@redhat.com;
> > > rth@twiddle.net; mtosatti@redhat.com; qemu-devel@nongnu.org;
> > > kvm@vger.kernel.org; kash@tripleback.net; geoff@hostfission.com
> > > Subject: Re: [PATCH v7 4/9] i386: Add new property to control cache info
> > >
> > > On Thu, Apr 26, 2018 at 11:26:44AM -0500, Babu Moger wrote:
> > > > 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.
> > > > It will be "on" for machine type "pc-q35-2.10" for compatibility.
> > > >
> > > > Signed-off-by: Babu Moger <babu.moger@amd.com>
> > > > Tested-by: Geoffrey McRae <geoff@hostfission.com>
> > > > ---
> > > > include/hw/i386/pc.h | 4 ++++
> > > > target/i386/cpu.c | 1 +
> > > > target/i386/cpu.h | 5 +++++
> > > > 3 files changed, 10 insertions(+)
> > > >
> > > > diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> > > > index ffee841..d904a3c 100644
> > > > --- a/include/hw/i386/pc.h
> > > > +++ b/include/hw/i386/pc.h
> > > > @@ -327,6 +327,10 @@ 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 = "on",\
> > > > },
> > >
> > > >
> > > > #define PC_COMPAT_2_9 \
> > > > diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> > > > index 5d88363..a27b658 100644
> > > > --- a/target/i386/cpu.c
> > > > +++ b/target/i386/cpu.c
> > > > @@ -5138,6 +5138,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),
> >
> > Ok. I will remove this about line and add below code in x86_cpu_load_def.
>
> You need this line forthe PC_COMPAT_* entry to work.
>
> But in this case, the default here won't matter because it will
> be overwritten by x86_cpu_load_def(). So it's a good idea to add
> a comment noting that the default will depend on the CPU model
> being chosen, and point people to x86_cpu_load_def()).
Ok. Got it. Thanks
>
> >
> > >
> > >
> > > Hmm, this can get messy if we start adding cache info to other
> > > CPU models in future QEMU versions. e.g.: what if we add cache
> > > info to Opteron_G3 on QEMU 2.14?
> > >
> > > I suggest adding this to x86_cpu_load_def():
> > >
> > > cpu->legacy_cache = !cpu->cache_info.valid;
> > >
> > > (Or equivalent code, in case cache_info is changed to be a
> > > pointer)
> > >
> > > This way, only EPYC will have legacy-cache=false by now, making
> > > it easier to write compatibility code for other CPU models in the
> > > future.
> > >
> > >
> > > >
> > > > /*
> > > > * From "Requirements for Implementing the Microsoft
> > > > diff --git a/target/i386/cpu.h b/target/i386/cpu.h
> > > > index 1213bb7..852586a 100644
> > > > --- a/target/i386/cpu.h
> > > > +++ b/target/i386/cpu.h
> > > > @@ -1395,6 +1395,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;
> > > >
> > > > --
> > > > 2.7.4
> > > >
> > >
> > > --
> > > Eduardo
>
> --
> Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [Qemu-devel] [PATCH v7 4/9] i386: Add new property to control cache info
@ 2018-05-08 18:44 ` Moger, Babu
0 siblings, 0 replies; 88+ messages in thread
From: Moger, Babu @ 2018-05-08 18:44 UTC (permalink / raw)
To: Eduardo Habkost
Cc: mst, marcel, pbonzini, rth, mtosatti, qemu-devel, kvm, kash, geoff
> -----Original Message-----
> From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> Sent: Tuesday, May 8, 2018 1:34 PM
> To: Moger, Babu <Babu.Moger@amd.com>
> Cc: mst@redhat.com; marcel@redhat.com; pbonzini@redhat.com;
> rth@twiddle.net; mtosatti@redhat.com; qemu-devel@nongnu.org;
> kvm@vger.kernel.org; kash@tripleback.net; geoff@hostfission.com
> Subject: Re: [PATCH v7 4/9] i386: Add new property to control cache info
>
> On Tue, May 08, 2018 at 05:26:16PM +0000, Moger, Babu wrote:
> >
> >
> > > -----Original Message-----
> > > From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> > > Sent: Tuesday, May 8, 2018 9:26 AM
> > > To: Moger, Babu <Babu.Moger@amd.com>
> > > Cc: mst@redhat.com; marcel@redhat.com; pbonzini@redhat.com;
> > > rth@twiddle.net; mtosatti@redhat.com; qemu-devel@nongnu.org;
> > > kvm@vger.kernel.org; kash@tripleback.net; geoff@hostfission.com
> > > Subject: Re: [PATCH v7 4/9] i386: Add new property to control cache info
> > >
> > > On Thu, Apr 26, 2018 at 11:26:44AM -0500, Babu Moger wrote:
> > > > 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.
> > > > It will be "on" for machine type "pc-q35-2.10" for compatibility.
> > > >
> > > > Signed-off-by: Babu Moger <babu.moger@amd.com>
> > > > Tested-by: Geoffrey McRae <geoff@hostfission.com>
> > > > ---
> > > > include/hw/i386/pc.h | 4 ++++
> > > > target/i386/cpu.c | 1 +
> > > > target/i386/cpu.h | 5 +++++
> > > > 3 files changed, 10 insertions(+)
> > > >
> > > > diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> > > > index ffee841..d904a3c 100644
> > > > --- a/include/hw/i386/pc.h
> > > > +++ b/include/hw/i386/pc.h
> > > > @@ -327,6 +327,10 @@ 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 = "on",\
> > > > },
> > >
> > > >
> > > > #define PC_COMPAT_2_9 \
> > > > diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> > > > index 5d88363..a27b658 100644
> > > > --- a/target/i386/cpu.c
> > > > +++ b/target/i386/cpu.c
> > > > @@ -5138,6 +5138,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),
> >
> > Ok. I will remove this about line and add below code in x86_cpu_load_def.
>
> You need this line forthe PC_COMPAT_* entry to work.
>
> But in this case, the default here won't matter because it will
> be overwritten by x86_cpu_load_def(). So it's a good idea to add
> a comment noting that the default will depend on the CPU model
> being chosen, and point people to x86_cpu_load_def()).
Ok. Got it. Thanks
>
> >
> > >
> > >
> > > Hmm, this can get messy if we start adding cache info to other
> > > CPU models in future QEMU versions. e.g.: what if we add cache
> > > info to Opteron_G3 on QEMU 2.14?
> > >
> > > I suggest adding this to x86_cpu_load_def():
> > >
> > > cpu->legacy_cache = !cpu->cache_info.valid;
> > >
> > > (Or equivalent code, in case cache_info is changed to be a
> > > pointer)
> > >
> > > This way, only EPYC will have legacy-cache=false by now, making
> > > it easier to write compatibility code for other CPU models in the
> > > future.
> > >
> > >
> > > >
> > > > /*
> > > > * From "Requirements for Implementing the Microsoft
> > > > diff --git a/target/i386/cpu.h b/target/i386/cpu.h
> > > > index 1213bb7..852586a 100644
> > > > --- a/target/i386/cpu.h
> > > > +++ b/target/i386/cpu.h
> > > > @@ -1395,6 +1395,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;
> > > >
> > > > --
> > > > 2.7.4
> > > >
> > >
> > > --
> > > Eduardo
>
> --
> Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH v7 1/9] i386: Helpers to encode cache information consistently
2018-05-08 18:40 ` [Qemu-devel] " Moger, Babu
@ 2018-05-08 19:07 ` Eduardo Habkost
-1 siblings, 0 replies; 88+ messages in thread
From: Eduardo Habkost @ 2018-05-08 19:07 UTC (permalink / raw)
To: Moger, Babu
Cc: geoff, kvm, mst, kash, mtosatti, qemu-devel, marcel, pbonzini, rth
On Tue, May 08, 2018 at 06:40:23PM +0000, Moger, Babu wrote:
> Hi Eduardo, One more comment below.
>
> > -----Original Message-----
> > From: kvm-owner@vger.kernel.org [mailto:kvm-owner@vger.kernel.org]
> > On Behalf Of Moger, Babu
> > Sent: Monday, May 7, 2018 5:48 PM
> > To: Eduardo Habkost <ehabkost@redhat.com>
> > Cc: geoff@hostfission.com; kvm@vger.kernel.org; mst@redhat.com;
> > kash@tripleback.net; mtosatti@redhat.com; qemu-devel@nongnu.org;
> > marcel@redhat.com; pbonzini@redhat.com; rth@twiddle.net
> > Subject: RE: [Qemu-devel] [PATCH v7 1/9] i386: Helpers to encode cache
> > information consistently
> >
> >
> >
> > > -----Original Message-----
> > > From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> > > Sent: Monday, May 7, 2018 4:27 PM
> > > To: Moger, Babu <Babu.Moger@amd.com>
> > > Cc: geoff@hostfission.com; kvm@vger.kernel.org; mst@redhat.com;
> > > kash@tripleback.net; mtosatti@redhat.com; qemu-devel@nongnu.org;
> > > marcel@redhat.com; pbonzini@redhat.com; rth@twiddle.net
> > > Subject: Re: [Qemu-devel] [PATCH v7 1/9] i386: Helpers to encode cache
> > > information consistently
> > >
> > > On Mon, May 07, 2018 at 09:14:27PM +0000, Moger, Babu wrote:
> > > > Eduardo,
> > > > Thanks for all the comments. Will respond to each one separately.
> > > >
> > > > > -----Original Message-----
> > > > > From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> > > > > Sent: Monday, May 7, 2018 2:05 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 1/9] i386: Helpers to encode
> > cache
> > > > > information consistently
> > > > >
> > > > > Hi,
> > > > >
> > > > > I was about to apply this because I assumed it was the same patch
> > > > > I sent in March, but then I found this:
> > > > >
> > > > > On Thu, Apr 26, 2018 at 11:26:41AM -0500, Babu Moger wrote:
> > > > > > From: Eduardo Habkost <ehabkost@redhat.com>
> > > > > >
> > > > > > Instead of having a collection of macros that need to be used in
> > > > > > complex expressions to build CPUID data, define a CPUCacheInfo
> > > > > > struct that can hold information about a given cache. Helper
> > > > > > functions will take a CPUCacheInfo struct as input to encode
> > > > > > CPUID leaves for a cache.
> > > > > >
> > > > > > This will help us ensure consistency between cache information
> > > > > > CPUID leaves, and make the existing inconsistencies in CPUID info
> > > > > > more visible.
> > > > > >
> > > > > > Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> > > > > > Signed-off-by: Babu Moger <babu.moger@amd.com>
> > > > > > Tested-by: Geoffrey McRae <geoff@hostfission.com>
> > > > > [...]
> > > > > > -#define L2_ASSOCIATIVITY 16
> > > > > [...]
> > > > > > /*FIXME: CPUID leaf 0x80000006 is inconsistent with leaves 2 & 4 */
> > > > > > +static CPUCacheInfo l2_cache_amd = {
> > > > > [...]
> > > > > > + .associativity = 8,
> > > > > [...]
> > > > > > +};
> > > > > [...]
> > > > > > case 0x80000006:
> > > > > [...]
> > > > > > - *ecx = (L2_SIZE_KB_AMD << 16) | \
> > > > > > - (AMD_ENC_ASSOC(L2_ASSOCIATIVITY) << 12) | \
> > > > > > - (L2_LINES_PER_TAG << 8) | (L2_LINE_SIZE);
> > > > > [...]
> > > > > > + encode_cache_cpuid80000006(&l2_cache_amd,
> > > > > > + cpu->enable_l3_cache ? &l3_cache : NULL,
> > > > > > + ecx, edx);
> > > > > [...]
> > > > >
> > > > > The structs added by this patch are supposed to represent the
> > > > > legacy cache sizes, and must match the old code. My original
> > > > > patch set l2_cache_amd.associativity=16 because of that.
> > > > >
> > > > > This patch changes 0x80000006 from associativity=16 to
> > > > > associativity=8. Why?
>
> Keeping this to 16 will be a problem. It breaks the size rule(line size *associativity * partitions * sets).
> It asserts violating that rule. Now I remember. That is why I changed it to 8. I would think it would be
> better to fix it now.
You can fix it, no problem. You just need to make sure
CPUID[0x80000006] data for old machine-types without topoext will
stay the same.
Remember that l2_cache_amd is just for the legacy values enabled
by legacy-cache=on. Non-legacy values with more consistent data
can be set at the CPU model table.
The current CPUID data is:
#define L2_SIZE_KB_AMD 512
#define L2_ASSOCIATIVITY 16
#define L2_LINES_PER_TAG 1
#define L2_LINE_SIZE 64
[...]
case 0x80000006:
*ecx = (L2_SIZE_KB_AMD << 16) | \
(AMD_ENC_ASSOC(L2_ASSOCIATIVITY) << 12) | \
(L2_LINES_PER_TAG << 8) | (L2_LINE_SIZE);
This means l2_cache_amd.size must be 512KiB,
l2_cache_amd.associativity must be 16, l2_cache_amd.lines_per_tag
must be 1, and l2_cache_amd.line_size must be 64.
l2_cache_amd.partitions and l2_cache_amd.sets, on the other hand,
can be set to any value you wish.
Another option is to simply disable CPUID[0x8000001d] if
legacy-cache=on, so we don't need to worry about consistency on
legacy cache entries that are known to be inconsistent.
If we want to be extra safe/consistent, we can automatically set
legacy-cache=off if topoext is enabled, and prevent QEMU from
starting if topoext is enabled on a CPU without
X86CPUDefinition.cache_info.
We have lots of freedom on what to do when topoext is enabled or
when using new machine-types. We just can't change the CPUID
data of old machine-types when topoext is disabled.
>
> > > >
> > > > The original code had a bug here. The associativity should have been 8.
> > > > My earlier response from the thread
> > > > http://patchwork.ozlabs.org/patch/884880/
> > > >
> > > > This should have been 8-way. This is a bug. Will fix.
> > > > This should have been (AMD_ENC_ASSOC(L2_ASSOCIATIVITY_AMD) <<
> > > 12)
> > >
> > > If we want to change the associativity, we must keep the old
> > > values on older machine-types, which was the whole purpose of the
> > > "legacy-cache" property.
> > >
> > > I suggest using the new X86CPUDefinition::cache_info field if you
> > > want to make AMD CPUs report different associativity.
> >
> > Ok. Sure. I will change it. Thanks
> >
> > >
> > > --
> > > Eduardo
--
Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [Qemu-devel] [PATCH v7 1/9] i386: Helpers to encode cache information consistently
@ 2018-05-08 19:07 ` Eduardo Habkost
0 siblings, 0 replies; 88+ messages in thread
From: Eduardo Habkost @ 2018-05-08 19:07 UTC (permalink / raw)
To: Moger, Babu
Cc: geoff, kvm, mst, kash, mtosatti, qemu-devel, marcel, pbonzini, rth
On Tue, May 08, 2018 at 06:40:23PM +0000, Moger, Babu wrote:
> Hi Eduardo, One more comment below.
>
> > -----Original Message-----
> > From: kvm-owner@vger.kernel.org [mailto:kvm-owner@vger.kernel.org]
> > On Behalf Of Moger, Babu
> > Sent: Monday, May 7, 2018 5:48 PM
> > To: Eduardo Habkost <ehabkost@redhat.com>
> > Cc: geoff@hostfission.com; kvm@vger.kernel.org; mst@redhat.com;
> > kash@tripleback.net; mtosatti@redhat.com; qemu-devel@nongnu.org;
> > marcel@redhat.com; pbonzini@redhat.com; rth@twiddle.net
> > Subject: RE: [Qemu-devel] [PATCH v7 1/9] i386: Helpers to encode cache
> > information consistently
> >
> >
> >
> > > -----Original Message-----
> > > From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> > > Sent: Monday, May 7, 2018 4:27 PM
> > > To: Moger, Babu <Babu.Moger@amd.com>
> > > Cc: geoff@hostfission.com; kvm@vger.kernel.org; mst@redhat.com;
> > > kash@tripleback.net; mtosatti@redhat.com; qemu-devel@nongnu.org;
> > > marcel@redhat.com; pbonzini@redhat.com; rth@twiddle.net
> > > Subject: Re: [Qemu-devel] [PATCH v7 1/9] i386: Helpers to encode cache
> > > information consistently
> > >
> > > On Mon, May 07, 2018 at 09:14:27PM +0000, Moger, Babu wrote:
> > > > Eduardo,
> > > > Thanks for all the comments. Will respond to each one separately.
> > > >
> > > > > -----Original Message-----
> > > > > From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> > > > > Sent: Monday, May 7, 2018 2:05 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 1/9] i386: Helpers to encode
> > cache
> > > > > information consistently
> > > > >
> > > > > Hi,
> > > > >
> > > > > I was about to apply this because I assumed it was the same patch
> > > > > I sent in March, but then I found this:
> > > > >
> > > > > On Thu, Apr 26, 2018 at 11:26:41AM -0500, Babu Moger wrote:
> > > > > > From: Eduardo Habkost <ehabkost@redhat.com>
> > > > > >
> > > > > > Instead of having a collection of macros that need to be used in
> > > > > > complex expressions to build CPUID data, define a CPUCacheInfo
> > > > > > struct that can hold information about a given cache. Helper
> > > > > > functions will take a CPUCacheInfo struct as input to encode
> > > > > > CPUID leaves for a cache.
> > > > > >
> > > > > > This will help us ensure consistency between cache information
> > > > > > CPUID leaves, and make the existing inconsistencies in CPUID info
> > > > > > more visible.
> > > > > >
> > > > > > Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> > > > > > Signed-off-by: Babu Moger <babu.moger@amd.com>
> > > > > > Tested-by: Geoffrey McRae <geoff@hostfission.com>
> > > > > [...]
> > > > > > -#define L2_ASSOCIATIVITY 16
> > > > > [...]
> > > > > > /*FIXME: CPUID leaf 0x80000006 is inconsistent with leaves 2 & 4 */
> > > > > > +static CPUCacheInfo l2_cache_amd = {
> > > > > [...]
> > > > > > + .associativity = 8,
> > > > > [...]
> > > > > > +};
> > > > > [...]
> > > > > > case 0x80000006:
> > > > > [...]
> > > > > > - *ecx = (L2_SIZE_KB_AMD << 16) | \
> > > > > > - (AMD_ENC_ASSOC(L2_ASSOCIATIVITY) << 12) | \
> > > > > > - (L2_LINES_PER_TAG << 8) | (L2_LINE_SIZE);
> > > > > [...]
> > > > > > + encode_cache_cpuid80000006(&l2_cache_amd,
> > > > > > + cpu->enable_l3_cache ? &l3_cache : NULL,
> > > > > > + ecx, edx);
> > > > > [...]
> > > > >
> > > > > The structs added by this patch are supposed to represent the
> > > > > legacy cache sizes, and must match the old code. My original
> > > > > patch set l2_cache_amd.associativity=16 because of that.
> > > > >
> > > > > This patch changes 0x80000006 from associativity=16 to
> > > > > associativity=8. Why?
>
> Keeping this to 16 will be a problem. It breaks the size rule(line size *associativity * partitions * sets).
> It asserts violating that rule. Now I remember. That is why I changed it to 8. I would think it would be
> better to fix it now.
You can fix it, no problem. You just need to make sure
CPUID[0x80000006] data for old machine-types without topoext will
stay the same.
Remember that l2_cache_amd is just for the legacy values enabled
by legacy-cache=on. Non-legacy values with more consistent data
can be set at the CPU model table.
The current CPUID data is:
#define L2_SIZE_KB_AMD 512
#define L2_ASSOCIATIVITY 16
#define L2_LINES_PER_TAG 1
#define L2_LINE_SIZE 64
[...]
case 0x80000006:
*ecx = (L2_SIZE_KB_AMD << 16) | \
(AMD_ENC_ASSOC(L2_ASSOCIATIVITY) << 12) | \
(L2_LINES_PER_TAG << 8) | (L2_LINE_SIZE);
This means l2_cache_amd.size must be 512KiB,
l2_cache_amd.associativity must be 16, l2_cache_amd.lines_per_tag
must be 1, and l2_cache_amd.line_size must be 64.
l2_cache_amd.partitions and l2_cache_amd.sets, on the other hand,
can be set to any value you wish.
Another option is to simply disable CPUID[0x8000001d] if
legacy-cache=on, so we don't need to worry about consistency on
legacy cache entries that are known to be inconsistent.
If we want to be extra safe/consistent, we can automatically set
legacy-cache=off if topoext is enabled, and prevent QEMU from
starting if topoext is enabled on a CPU without
X86CPUDefinition.cache_info.
We have lots of freedom on what to do when topoext is enabled or
when using new machine-types. We just can't change the CPUID
data of old machine-types when topoext is disabled.
>
> > > >
> > > > The original code had a bug here. The associativity should have been 8.
> > > > My earlier response from the thread
> > > > http://patchwork.ozlabs.org/patch/884880/
> > > >
> > > > This should have been 8-way. This is a bug. Will fix.
> > > > This should have been (AMD_ENC_ASSOC(L2_ASSOCIATIVITY_AMD) <<
> > > 12)
> > >
> > > If we want to change the associativity, we must keep the old
> > > values on older machine-types, which was the whole purpose of the
> > > "legacy-cache" property.
> > >
> > > I suggest using the new X86CPUDefinition::cache_info field if you
> > > want to make AMD CPUs report different associativity.
> >
> > Ok. Sure. I will change it. Thanks
> >
> > >
> > > --
> > > Eduardo
--
Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH v7 1/9] i386: Helpers to encode cache information consistently
2018-05-08 19:07 ` [Qemu-devel] " Eduardo Habkost
@ 2018-05-08 19:34 ` Moger, Babu
-1 siblings, 0 replies; 88+ messages in thread
From: Moger, Babu @ 2018-05-08 19:34 UTC (permalink / raw)
To: Eduardo Habkost
Cc: geoff, kvm, mst, kash, mtosatti, qemu-devel, marcel, pbonzini, rth
> -----Original Message-----
> From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> Sent: Tuesday, May 8, 2018 2:08 PM
> To: Moger, Babu <Babu.Moger@amd.com>
> Cc: geoff@hostfission.com; kvm@vger.kernel.org; mst@redhat.com;
> kash@tripleback.net; mtosatti@redhat.com; qemu-devel@nongnu.org;
> marcel@redhat.com; pbonzini@redhat.com; rth@twiddle.net
> Subject: Re: [Qemu-devel] [PATCH v7 1/9] i386: Helpers to encode cache
> information consistently
>
> On Tue, May 08, 2018 at 06:40:23PM +0000, Moger, Babu wrote:
> > Hi Eduardo, One more comment below.
> >
> > > -----Original Message-----
> > > From: kvm-owner@vger.kernel.org [mailto:kvm-
> owner@vger.kernel.org]
> > > On Behalf Of Moger, Babu
> > > Sent: Monday, May 7, 2018 5:48 PM
> > > To: Eduardo Habkost <ehabkost@redhat.com>
> > > Cc: geoff@hostfission.com; kvm@vger.kernel.org; mst@redhat.com;
> > > kash@tripleback.net; mtosatti@redhat.com; qemu-devel@nongnu.org;
> > > marcel@redhat.com; pbonzini@redhat.com; rth@twiddle.net
> > > Subject: RE: [Qemu-devel] [PATCH v7 1/9] i386: Helpers to encode cache
> > > information consistently
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> > > > Sent: Monday, May 7, 2018 4:27 PM
> > > > To: Moger, Babu <Babu.Moger@amd.com>
> > > > Cc: geoff@hostfission.com; kvm@vger.kernel.org; mst@redhat.com;
> > > > kash@tripleback.net; mtosatti@redhat.com; qemu-
> devel@nongnu.org;
> > > > marcel@redhat.com; pbonzini@redhat.com; rth@twiddle.net
> > > > Subject: Re: [Qemu-devel] [PATCH v7 1/9] i386: Helpers to encode
> cache
> > > > information consistently
> > > >
> > > > On Mon, May 07, 2018 at 09:14:27PM +0000, Moger, Babu wrote:
> > > > > Eduardo,
> > > > > Thanks for all the comments. Will respond to each one separately.
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> > > > > > Sent: Monday, May 7, 2018 2:05 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 1/9] i386: Helpers to encode
> > > cache
> > > > > > information consistently
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I was about to apply this because I assumed it was the same patch
> > > > > > I sent in March, but then I found this:
> > > > > >
> > > > > > On Thu, Apr 26, 2018 at 11:26:41AM -0500, Babu Moger wrote:
> > > > > > > From: Eduardo Habkost <ehabkost@redhat.com>
> > > > > > >
> > > > > > > Instead of having a collection of macros that need to be used in
> > > > > > > complex expressions to build CPUID data, define a CPUCacheInfo
> > > > > > > struct that can hold information about a given cache. Helper
> > > > > > > functions will take a CPUCacheInfo struct as input to encode
> > > > > > > CPUID leaves for a cache.
> > > > > > >
> > > > > > > This will help us ensure consistency between cache information
> > > > > > > CPUID leaves, and make the existing inconsistencies in CPUID info
> > > > > > > more visible.
> > > > > > >
> > > > > > > Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> > > > > > > Signed-off-by: Babu Moger <babu.moger@amd.com>
> > > > > > > Tested-by: Geoffrey McRae <geoff@hostfission.com>
> > > > > > [...]
> > > > > > > -#define L2_ASSOCIATIVITY 16
> > > > > > [...]
> > > > > > > /*FIXME: CPUID leaf 0x80000006 is inconsistent with leaves 2 & 4
> */
> > > > > > > +static CPUCacheInfo l2_cache_amd = {
> > > > > > [...]
> > > > > > > + .associativity = 8,
> > > > > > [...]
> > > > > > > +};
> > > > > > [...]
> > > > > > > case 0x80000006:
> > > > > > [...]
> > > > > > > - *ecx = (L2_SIZE_KB_AMD << 16) | \
> > > > > > > - (AMD_ENC_ASSOC(L2_ASSOCIATIVITY) << 12) | \
> > > > > > > - (L2_LINES_PER_TAG << 8) | (L2_LINE_SIZE);
> > > > > > [...]
> > > > > > > + encode_cache_cpuid80000006(&l2_cache_amd,
> > > > > > > + cpu->enable_l3_cache ? &l3_cache : NULL,
> > > > > > > + ecx, edx);
> > > > > > [...]
> > > > > >
> > > > > > The structs added by this patch are supposed to represent the
> > > > > > legacy cache sizes, and must match the old code. My original
> > > > > > patch set l2_cache_amd.associativity=16 because of that.
> > > > > >
> > > > > > This patch changes 0x80000006 from associativity=16 to
> > > > > > associativity=8. Why?
> >
> > Keeping this to 16 will be a problem. It breaks the size rule(line size
> *associativity * partitions * sets).
> > It asserts violating that rule. Now I remember. That is why I changed it to 8.
> I would think it would be
> > better to fix it now.
>
> You can fix it, no problem. You just need to make sure
> CPUID[0x80000006] data for old machine-types without topoext will
> stay the same.
>
> Remember that l2_cache_amd is just for the legacy values enabled
> by legacy-cache=on. Non-legacy values with more consistent data
> can be set at the CPU model table.
>
> The current CPUID data is:
>
> #define L2_SIZE_KB_AMD 512
> #define L2_ASSOCIATIVITY 16
> #define L2_LINES_PER_TAG 1
> #define L2_LINE_SIZE 64
> [...]
> case 0x80000006:
> *ecx = (L2_SIZE_KB_AMD << 16) | \
> (AMD_ENC_ASSOC(L2_ASSOCIATIVITY) << 12) | \
> (L2_LINES_PER_TAG << 8) | (L2_LINE_SIZE);
>
>
> This means l2_cache_amd.size must be 512KiB,
> l2_cache_amd.associativity must be 16, l2_cache_amd.lines_per_tag
> must be 1, and l2_cache_amd.line_size must be 64.
>
> l2_cache_amd.partitions and l2_cache_amd.sets, on the other hand,
> can be set to any value you wish.
Ok. Let me adjust sets and partitions. Thanks
>
> Another option is to simply disable CPUID[0x8000001d] if
> legacy-cache=on, so we don't need to worry about consistency on
> legacy cache entries that are known to be inconsistent.
>
> If we want to be extra safe/consistent, we can automatically set
> legacy-cache=off if topoext is enabled, and prevent QEMU from
> starting if topoext is enabled on a CPU without
> X86CPUDefinition.cache_info.
>
> We have lots of freedom on what to do when topoext is enabled or
> when using new machine-types. We just can't change the CPUID
> data of old machine-types when topoext is disabled.
>
>
> >
> > > > >
> > > > > The original code had a bug here. The associativity should have been
> 8.
> > > > > My earlier response from the thread
> > > > > http://patchwork.ozlabs.org/patch/884880/
> > > > >
> > > > > This should have been 8-way. This is a bug. Will fix.
> > > > > This should have been (AMD_ENC_ASSOC(L2_ASSOCIATIVITY_AMD)
> <<
> > > > 12)
> > > >
> > > > If we want to change the associativity, we must keep the old
> > > > values on older machine-types, which was the whole purpose of the
> > > > "legacy-cache" property.
> > > >
> > > > I suggest using the new X86CPUDefinition::cache_info field if you
> > > > want to make AMD CPUs report different associativity.
> > >
> > > Ok. Sure. I will change it. Thanks
> > >
> > > >
> > > > --
> > > > Eduardo
>
> --
> Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [Qemu-devel] [PATCH v7 1/9] i386: Helpers to encode cache information consistently
@ 2018-05-08 19:34 ` Moger, Babu
0 siblings, 0 replies; 88+ messages in thread
From: Moger, Babu @ 2018-05-08 19:34 UTC (permalink / raw)
To: Eduardo Habkost
Cc: geoff, kvm, mst, kash, mtosatti, qemu-devel, marcel, pbonzini, rth
> -----Original Message-----
> From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> Sent: Tuesday, May 8, 2018 2:08 PM
> To: Moger, Babu <Babu.Moger@amd.com>
> Cc: geoff@hostfission.com; kvm@vger.kernel.org; mst@redhat.com;
> kash@tripleback.net; mtosatti@redhat.com; qemu-devel@nongnu.org;
> marcel@redhat.com; pbonzini@redhat.com; rth@twiddle.net
> Subject: Re: [Qemu-devel] [PATCH v7 1/9] i386: Helpers to encode cache
> information consistently
>
> On Tue, May 08, 2018 at 06:40:23PM +0000, Moger, Babu wrote:
> > Hi Eduardo, One more comment below.
> >
> > > -----Original Message-----
> > > From: kvm-owner@vger.kernel.org [mailto:kvm-
> owner@vger.kernel.org]
> > > On Behalf Of Moger, Babu
> > > Sent: Monday, May 7, 2018 5:48 PM
> > > To: Eduardo Habkost <ehabkost@redhat.com>
> > > Cc: geoff@hostfission.com; kvm@vger.kernel.org; mst@redhat.com;
> > > kash@tripleback.net; mtosatti@redhat.com; qemu-devel@nongnu.org;
> > > marcel@redhat.com; pbonzini@redhat.com; rth@twiddle.net
> > > Subject: RE: [Qemu-devel] [PATCH v7 1/9] i386: Helpers to encode cache
> > > information consistently
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> > > > Sent: Monday, May 7, 2018 4:27 PM
> > > > To: Moger, Babu <Babu.Moger@amd.com>
> > > > Cc: geoff@hostfission.com; kvm@vger.kernel.org; mst@redhat.com;
> > > > kash@tripleback.net; mtosatti@redhat.com; qemu-
> devel@nongnu.org;
> > > > marcel@redhat.com; pbonzini@redhat.com; rth@twiddle.net
> > > > Subject: Re: [Qemu-devel] [PATCH v7 1/9] i386: Helpers to encode
> cache
> > > > information consistently
> > > >
> > > > On Mon, May 07, 2018 at 09:14:27PM +0000, Moger, Babu wrote:
> > > > > Eduardo,
> > > > > Thanks for all the comments. Will respond to each one separately.
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> > > > > > Sent: Monday, May 7, 2018 2:05 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 1/9] i386: Helpers to encode
> > > cache
> > > > > > information consistently
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I was about to apply this because I assumed it was the same patch
> > > > > > I sent in March, but then I found this:
> > > > > >
> > > > > > On Thu, Apr 26, 2018 at 11:26:41AM -0500, Babu Moger wrote:
> > > > > > > From: Eduardo Habkost <ehabkost@redhat.com>
> > > > > > >
> > > > > > > Instead of having a collection of macros that need to be used in
> > > > > > > complex expressions to build CPUID data, define a CPUCacheInfo
> > > > > > > struct that can hold information about a given cache. Helper
> > > > > > > functions will take a CPUCacheInfo struct as input to encode
> > > > > > > CPUID leaves for a cache.
> > > > > > >
> > > > > > > This will help us ensure consistency between cache information
> > > > > > > CPUID leaves, and make the existing inconsistencies in CPUID info
> > > > > > > more visible.
> > > > > > >
> > > > > > > Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> > > > > > > Signed-off-by: Babu Moger <babu.moger@amd.com>
> > > > > > > Tested-by: Geoffrey McRae <geoff@hostfission.com>
> > > > > > [...]
> > > > > > > -#define L2_ASSOCIATIVITY 16
> > > > > > [...]
> > > > > > > /*FIXME: CPUID leaf 0x80000006 is inconsistent with leaves 2 & 4
> */
> > > > > > > +static CPUCacheInfo l2_cache_amd = {
> > > > > > [...]
> > > > > > > + .associativity = 8,
> > > > > > [...]
> > > > > > > +};
> > > > > > [...]
> > > > > > > case 0x80000006:
> > > > > > [...]
> > > > > > > - *ecx = (L2_SIZE_KB_AMD << 16) | \
> > > > > > > - (AMD_ENC_ASSOC(L2_ASSOCIATIVITY) << 12) | \
> > > > > > > - (L2_LINES_PER_TAG << 8) | (L2_LINE_SIZE);
> > > > > > [...]
> > > > > > > + encode_cache_cpuid80000006(&l2_cache_amd,
> > > > > > > + cpu->enable_l3_cache ? &l3_cache : NULL,
> > > > > > > + ecx, edx);
> > > > > > [...]
> > > > > >
> > > > > > The structs added by this patch are supposed to represent the
> > > > > > legacy cache sizes, and must match the old code. My original
> > > > > > patch set l2_cache_amd.associativity=16 because of that.
> > > > > >
> > > > > > This patch changes 0x80000006 from associativity=16 to
> > > > > > associativity=8. Why?
> >
> > Keeping this to 16 will be a problem. It breaks the size rule(line size
> *associativity * partitions * sets).
> > It asserts violating that rule. Now I remember. That is why I changed it to 8.
> I would think it would be
> > better to fix it now.
>
> You can fix it, no problem. You just need to make sure
> CPUID[0x80000006] data for old machine-types without topoext will
> stay the same.
>
> Remember that l2_cache_amd is just for the legacy values enabled
> by legacy-cache=on. Non-legacy values with more consistent data
> can be set at the CPU model table.
>
> The current CPUID data is:
>
> #define L2_SIZE_KB_AMD 512
> #define L2_ASSOCIATIVITY 16
> #define L2_LINES_PER_TAG 1
> #define L2_LINE_SIZE 64
> [...]
> case 0x80000006:
> *ecx = (L2_SIZE_KB_AMD << 16) | \
> (AMD_ENC_ASSOC(L2_ASSOCIATIVITY) << 12) | \
> (L2_LINES_PER_TAG << 8) | (L2_LINE_SIZE);
>
>
> This means l2_cache_amd.size must be 512KiB,
> l2_cache_amd.associativity must be 16, l2_cache_amd.lines_per_tag
> must be 1, and l2_cache_amd.line_size must be 64.
>
> l2_cache_amd.partitions and l2_cache_amd.sets, on the other hand,
> can be set to any value you wish.
Ok. Let me adjust sets and partitions. Thanks
>
> Another option is to simply disable CPUID[0x8000001d] if
> legacy-cache=on, so we don't need to worry about consistency on
> legacy cache entries that are known to be inconsistent.
>
> If we want to be extra safe/consistent, we can automatically set
> legacy-cache=off if topoext is enabled, and prevent QEMU from
> starting if topoext is enabled on a CPU without
> X86CPUDefinition.cache_info.
>
> We have lots of freedom on what to do when topoext is enabled or
> when using new machine-types. We just can't change the CPUID
> data of old machine-types when topoext is disabled.
>
>
> >
> > > > >
> > > > > The original code had a bug here. The associativity should have been
> 8.
> > > > > My earlier response from the thread
> > > > > http://patchwork.ozlabs.org/patch/884880/
> > > > >
> > > > > This should have been 8-way. This is a bug. Will fix.
> > > > > This should have been (AMD_ENC_ASSOC(L2_ASSOCIATIVITY_AMD)
> <<
> > > > 12)
> > > >
> > > > If we want to change the associativity, we must keep the old
> > > > values on older machine-types, which was the whole purpose of the
> > > > "legacy-cache" property.
> > > >
> > > > I suggest using the new X86CPUDefinition::cache_info field if you
> > > > want to make AMD CPUs report different associativity.
> > >
> > > Ok. Sure. I will change it. Thanks
> > >
> > > >
> > > > --
> > > > Eduardo
>
> --
> Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH v7 7/9] i386: Add support for CPUID_8000_001E for AMD
2018-05-08 15:02 ` [Qemu-devel] " Moger, Babu
@ 2018-05-11 14:12 ` Eduardo Habkost
-1 siblings, 0 replies; 88+ messages in thread
From: Eduardo Habkost @ 2018-05-11 14:12 UTC (permalink / raw)
To: Moger, Babu
Cc: geoff, kvm, mst, kash, mtosatti, qemu-devel, marcel, pbonzini, rth
On Tue, May 08, 2018 at 03:02:07PM +0000, Moger, Babu wrote:
>
> > -----Original Message-----
> > From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> > Sent: Tuesday, May 8, 2018 9:17 AM
> > 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 7/9] i386: Add support for
> > CPUID_8000_001E for AMD
> >
> > On Mon, May 07, 2018 at 11:44:31PM +0000, Moger, Babu wrote:
> > [...]
> > > > > +
> > > > > /*
> > > > > * Encode cache info for CPUID[0x80000006].ECX and
> > > > CPUID[0x80000006].EDX
> > > > > * @l3 can be NULL.
> > > > > @@ -4105,6 +4111,14 @@ void cpu_x86_cpuid(CPUX86State *env,
> > > > uint32_t index, uint32_t count,
> > > > > break;
> > > > > }
> > > > > break;
> > > > > + case 0x8000001E:
> > > > > + assert(cpu->core_id <= 255);
> > > >
> > > > Where's the code that ensures this assert() line can't be
> > > > triggered by any command-line configuration?
> > >
> > > I did not understand this. Can you please elaborate. Thanks
> >
> > The user must not be able to trigger an assert(), so we need to
> > ensure that core_id will never be larger than 255. Is there
> > existing code that ensures that?
>
> I see that max_cpus is set to 255 and also there are checks to make sure core_id does not go above 255.
> I verified it while testing. So, probably we don't need assert here. Radim asked me to add this assert.
> I can remove it if no abjections.
Sorry for not replying to this before: no objection to the
assert(), especially considering it will trigger very early on
initialization if we break it one day.
--
Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [Qemu-devel] [PATCH v7 7/9] i386: Add support for CPUID_8000_001E for AMD
@ 2018-05-11 14:12 ` Eduardo Habkost
0 siblings, 0 replies; 88+ messages in thread
From: Eduardo Habkost @ 2018-05-11 14:12 UTC (permalink / raw)
To: Moger, Babu
Cc: mst, marcel, pbonzini, rth, mtosatti, geoff, kash, qemu-devel, kvm
On Tue, May 08, 2018 at 03:02:07PM +0000, Moger, Babu wrote:
>
> > -----Original Message-----
> > From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> > Sent: Tuesday, May 8, 2018 9:17 AM
> > 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 7/9] i386: Add support for
> > CPUID_8000_001E for AMD
> >
> > On Mon, May 07, 2018 at 11:44:31PM +0000, Moger, Babu wrote:
> > [...]
> > > > > +
> > > > > /*
> > > > > * Encode cache info for CPUID[0x80000006].ECX and
> > > > CPUID[0x80000006].EDX
> > > > > * @l3 can be NULL.
> > > > > @@ -4105,6 +4111,14 @@ void cpu_x86_cpuid(CPUX86State *env,
> > > > uint32_t index, uint32_t count,
> > > > > break;
> > > > > }
> > > > > break;
> > > > > + case 0x8000001E:
> > > > > + assert(cpu->core_id <= 255);
> > > >
> > > > Where's the code that ensures this assert() line can't be
> > > > triggered by any command-line configuration?
> > >
> > > I did not understand this. Can you please elaborate. Thanks
> >
> > The user must not be able to trigger an assert(), so we need to
> > ensure that core_id will never be larger than 255. Is there
> > existing code that ensures that?
>
> I see that max_cpus is set to 255 and also there are checks to make sure core_id does not go above 255.
> I verified it while testing. So, probably we don't need assert here. Radim asked me to add this assert.
> I can remove it if no abjections.
Sorry for not replying to this before: no objection to the
assert(), especially considering it will trigger very early on
initialization if we break it one day.
--
Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH v7 7/9] i386: Add support for CPUID_8000_001E for AMD
2018-05-11 14:12 ` [Qemu-devel] " Eduardo Habkost
@ 2018-05-11 14:44 ` Moger, Babu
-1 siblings, 0 replies; 88+ messages in thread
From: Moger, Babu @ 2018-05-11 14:44 UTC (permalink / raw)
To: Eduardo Habkost
Cc: geoff, kvm, mst, kash, mtosatti, qemu-devel, marcel, pbonzini, rth
> -----Original Message-----
> From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> Sent: Friday, May 11, 2018 9:12 AM
> 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 7/9] i386: Add support for
> CPUID_8000_001E for AMD
>
> On Tue, May 08, 2018 at 03:02:07PM +0000, Moger, Babu wrote:
> >
> > > -----Original Message-----
> > > From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> > > Sent: Tuesday, May 8, 2018 9:17 AM
> > > 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 7/9] i386: Add support for
> > > CPUID_8000_001E for AMD
> > >
> > > On Mon, May 07, 2018 at 11:44:31PM +0000, Moger, Babu wrote:
> > > [...]
> > > > > > +
> > > > > > /*
> > > > > > * Encode cache info for CPUID[0x80000006].ECX and
> > > > > CPUID[0x80000006].EDX
> > > > > > * @l3 can be NULL.
> > > > > > @@ -4105,6 +4111,14 @@ void cpu_x86_cpuid(CPUX86State *env,
> > > > > uint32_t index, uint32_t count,
> > > > > > break;
> > > > > > }
> > > > > > break;
> > > > > > + case 0x8000001E:
> > > > > > + assert(cpu->core_id <= 255);
> > > > >
> > > > > Where's the code that ensures this assert() line can't be
> > > > > triggered by any command-line configuration?
> > > >
> > > > I did not understand this. Can you please elaborate. Thanks
> > >
> > > The user must not be able to trigger an assert(), so we need to
> > > ensure that core_id will never be larger than 255. Is there
> > > existing code that ensures that?
> >
> > I see that max_cpus is set to 255 and also there are checks to make sure
> core_id does not go above 255.
> > I verified it while testing. So, probably we don't need assert here. Radim
> asked me to add this assert.
> > I can remove it if no abjections.
>
> Sorry for not replying to this before: no objection to the
> assert(), especially considering it will trigger very early on
> initialization if we break it one day.
Ok. No problem. I will add it back and send a v9 version.
Please let me know if you have any other feedback for v8 version(sent yesterday).
>
> --
> Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [Qemu-devel] [PATCH v7 7/9] i386: Add support for CPUID_8000_001E for AMD
@ 2018-05-11 14:44 ` Moger, Babu
0 siblings, 0 replies; 88+ messages in thread
From: Moger, Babu @ 2018-05-11 14:44 UTC (permalink / raw)
To: Eduardo Habkost
Cc: mst, marcel, pbonzini, rth, mtosatti, geoff, kash, qemu-devel, kvm
> -----Original Message-----
> From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> Sent: Friday, May 11, 2018 9:12 AM
> 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 7/9] i386: Add support for
> CPUID_8000_001E for AMD
>
> On Tue, May 08, 2018 at 03:02:07PM +0000, Moger, Babu wrote:
> >
> > > -----Original Message-----
> > > From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> > > Sent: Tuesday, May 8, 2018 9:17 AM
> > > 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 7/9] i386: Add support for
> > > CPUID_8000_001E for AMD
> > >
> > > On Mon, May 07, 2018 at 11:44:31PM +0000, Moger, Babu wrote:
> > > [...]
> > > > > > +
> > > > > > /*
> > > > > > * Encode cache info for CPUID[0x80000006].ECX and
> > > > > CPUID[0x80000006].EDX
> > > > > > * @l3 can be NULL.
> > > > > > @@ -4105,6 +4111,14 @@ void cpu_x86_cpuid(CPUX86State *env,
> > > > > uint32_t index, uint32_t count,
> > > > > > break;
> > > > > > }
> > > > > > break;
> > > > > > + case 0x8000001E:
> > > > > > + assert(cpu->core_id <= 255);
> > > > >
> > > > > Where's the code that ensures this assert() line can't be
> > > > > triggered by any command-line configuration?
> > > >
> > > > I did not understand this. Can you please elaborate. Thanks
> > >
> > > The user must not be able to trigger an assert(), so we need to
> > > ensure that core_id will never be larger than 255. Is there
> > > existing code that ensures that?
> >
> > I see that max_cpus is set to 255 and also there are checks to make sure
> core_id does not go above 255.
> > I verified it while testing. So, probably we don't need assert here. Radim
> asked me to add this assert.
> > I can remove it if no abjections.
>
> Sorry for not replying to this before: no objection to the
> assert(), especially considering it will trigger very early on
> initialization if we break it one day.
Ok. No problem. I will add it back and send a v9 version.
Please let me know if you have any other feedback for v8 version(sent yesterday).
>
> --
> Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [PATCH v7 7/9] i386: Add support for CPUID_8000_001E for AMD
2018-05-11 14:44 ` [Qemu-devel] " Moger, Babu
@ 2018-05-11 14:59 ` Eduardo Habkost
-1 siblings, 0 replies; 88+ messages in thread
From: Eduardo Habkost @ 2018-05-11 14:59 UTC (permalink / raw)
To: Moger, Babu
Cc: geoff, kvm, mst, kash, mtosatti, qemu-devel, marcel, pbonzini, rth
On Fri, May 11, 2018 at 02:44:11PM +0000, Moger, Babu wrote:
>
>
> > -----Original Message-----
> > From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> > Sent: Friday, May 11, 2018 9:12 AM
> > 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 7/9] i386: Add support for
> > CPUID_8000_001E for AMD
> >
> > On Tue, May 08, 2018 at 03:02:07PM +0000, Moger, Babu wrote:
> > >
> > > > -----Original Message-----
> > > > From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> > > > Sent: Tuesday, May 8, 2018 9:17 AM
> > > > 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 7/9] i386: Add support for
> > > > CPUID_8000_001E for AMD
> > > >
> > > > On Mon, May 07, 2018 at 11:44:31PM +0000, Moger, Babu wrote:
> > > > [...]
> > > > > > > +
> > > > > > > /*
> > > > > > > * Encode cache info for CPUID[0x80000006].ECX and
> > > > > > CPUID[0x80000006].EDX
> > > > > > > * @l3 can be NULL.
> > > > > > > @@ -4105,6 +4111,14 @@ void cpu_x86_cpuid(CPUX86State *env,
> > > > > > uint32_t index, uint32_t count,
> > > > > > > break;
> > > > > > > }
> > > > > > > break;
> > > > > > > + case 0x8000001E:
> > > > > > > + assert(cpu->core_id <= 255);
> > > > > >
> > > > > > Where's the code that ensures this assert() line can't be
> > > > > > triggered by any command-line configuration?
> > > > >
> > > > > I did not understand this. Can you please elaborate. Thanks
> > > >
> > > > The user must not be able to trigger an assert(), so we need to
> > > > ensure that core_id will never be larger than 255. Is there
> > > > existing code that ensures that?
> > >
> > > I see that max_cpus is set to 255 and also there are checks to make sure
> > core_id does not go above 255.
> > > I verified it while testing. So, probably we don't need assert here. Radim
> > asked me to add this assert.
> > > I can remove it if no abjections.
> >
> > Sorry for not replying to this before: no objection to the
> > assert(), especially considering it will trigger very early on
> > initialization if we break it one day.
>
> Ok. No problem. I will add it back and send a v9 version.
> Please let me know if you have any other feedback for v8 version(sent yesterday).
Thanks, I just saw v8 on my mailbox. No need to send v9 just
because of the assert(), I can re-add it while committing if
necessary.
--
Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
* Re: [Qemu-devel] [PATCH v7 7/9] i386: Add support for CPUID_8000_001E for AMD
@ 2018-05-11 14:59 ` Eduardo Habkost
0 siblings, 0 replies; 88+ messages in thread
From: Eduardo Habkost @ 2018-05-11 14:59 UTC (permalink / raw)
To: Moger, Babu
Cc: mst, marcel, pbonzini, rth, mtosatti, geoff, kash, qemu-devel, kvm
On Fri, May 11, 2018 at 02:44:11PM +0000, Moger, Babu wrote:
>
>
> > -----Original Message-----
> > From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> > Sent: Friday, May 11, 2018 9:12 AM
> > 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 7/9] i386: Add support for
> > CPUID_8000_001E for AMD
> >
> > On Tue, May 08, 2018 at 03:02:07PM +0000, Moger, Babu wrote:
> > >
> > > > -----Original Message-----
> > > > From: Eduardo Habkost [mailto:ehabkost@redhat.com]
> > > > Sent: Tuesday, May 8, 2018 9:17 AM
> > > > 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 7/9] i386: Add support for
> > > > CPUID_8000_001E for AMD
> > > >
> > > > On Mon, May 07, 2018 at 11:44:31PM +0000, Moger, Babu wrote:
> > > > [...]
> > > > > > > +
> > > > > > > /*
> > > > > > > * Encode cache info for CPUID[0x80000006].ECX and
> > > > > > CPUID[0x80000006].EDX
> > > > > > > * @l3 can be NULL.
> > > > > > > @@ -4105,6 +4111,14 @@ void cpu_x86_cpuid(CPUX86State *env,
> > > > > > uint32_t index, uint32_t count,
> > > > > > > break;
> > > > > > > }
> > > > > > > break;
> > > > > > > + case 0x8000001E:
> > > > > > > + assert(cpu->core_id <= 255);
> > > > > >
> > > > > > Where's the code that ensures this assert() line can't be
> > > > > > triggered by any command-line configuration?
> > > > >
> > > > > I did not understand this. Can you please elaborate. Thanks
> > > >
> > > > The user must not be able to trigger an assert(), so we need to
> > > > ensure that core_id will never be larger than 255. Is there
> > > > existing code that ensures that?
> > >
> > > I see that max_cpus is set to 255 and also there are checks to make sure
> > core_id does not go above 255.
> > > I verified it while testing. So, probably we don't need assert here. Radim
> > asked me to add this assert.
> > > I can remove it if no abjections.
> >
> > Sorry for not replying to this before: no objection to the
> > assert(), especially considering it will trigger very early on
> > initialization if we break it one day.
>
> Ok. No problem. I will add it back and send a v9 version.
> Please let me know if you have any other feedback for v8 version(sent yesterday).
Thanks, I just saw v8 on my mailbox. No need to send v9 just
because of the assert(), I can re-add it while committing if
necessary.
--
Eduardo
^ permalink raw reply [flat|nested] 88+ messages in thread
end of thread, other threads:[~2018-05-11 14:59 UTC | newest]
Thread overview: 88+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2018-05-08 14:12 ` [Qemu-devel] " 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
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.