- 17 6月, 2016 1 次提交
-
-
由 Jiri Denemark 提交于
The CPU model was implemented in QEMU by commit f6f949e929. The change to i7-5600U is wrong since it's a 5th generation CPU, i.e., Broadwell rather than Skylake, but that's just the result of our CPU detection code (which is fixed by the following commit). Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 09 6月, 2016 13 次提交
-
-
由 Jiri Denemark 提交于
Implemented in QEMU by commit 28b8e4d0bf93ba176b4b7be819d537383c5a9060. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
This was implemented in QEMU by commit 0bb0b2d2fe7f645dda. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
As a side effect this changes the order of CPU features in XMLs generated by libvirt, but that's not a big deal since the order there is insignificant. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
For two reasons: - 0x00000001 is very similar to 0x80000001, but 0x01 is visually different - 0x01 format is consistent with CPUID manual Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
This patch makes our CPUID handling code up-to-date with the current specification found in Intel® 64 and IA-32 Architectures Developer's Manual: Vol. 2A http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.htmlSigned-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
CPUID instruction normally takes its parameter from EAX, but sometimes ECX is used as an additional parameter. This patch prepares the x86 CPU driver code for the new 'ecx_in' CPUID parameter. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The internal features are only used in explicit checks with cpuHasFeature. Loading them into the CPU map is dangerous since the features may accidentally be reported to users when decoding CPUID data. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
virCPUData and struct ppc64_model structures contained a pointer to virCPUppc64Data, which was not very nice since the real data were accessible by yet another level of pointers from virCPUppc64Data. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
virCPUData, virCPUx86Feature, and virCPUx86Model all contained a pointer to virCPUx86Data, which was not very nice since the real CPUID data were accessible by yet another pointer from virCPUx86Data. Moreover, using virCPUx86Data directly will make static definitions of internal CPU features a bit easier. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
CPUID instruction normally takes its parameter from EAX, but sometimes ECX is used as an additional parameter. Let's rename 'function' to 'eax_in' in preparation for adding 'ecx_in'. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
A CPU data XML file already contains the architecture, let the parser use it to detect which CPU driver should be used to parse the rest of the file. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The formatter uses /cpudata/cpuid elements and the parser should really do the same. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
When computing CPU data for a given guest CPU we should set CPUID vendor bits appropriately so that we don't lose the vendor when transforming CPU data back to XML description. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 02 6月, 2016 1 次提交
-
-
由 Michal Privoznik 提交于
cpu/cpu_ppc64.c: In function 'ppc64Compute': cpu/cpu_ppc64.c:620:27: error: potential null pointer dereference [-Werror=null-dereference] if (STRNEQ(guest_model->name, host_model->name)) { ~~~~~~~~~~~^~~ cpu/cpu_ppc64.c:620:9: note: in expansion of macro 'STRNEQ' if (STRNEQ(guest_model->name, host_model->name)) { ^~~~~~ cc1: all warnings being treated as errors Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 20 5月, 2016 7 次提交
-
-
由 Jiri Denemark 提交于
All callers of cpuGetModels expect @models to be NULL-terminated. Once both x86GetModels and ppc64GetModels were fixed to meet this expectation, we can explicitly document it. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The architecture specific loaders are now called with a list of all elements of a given type (rather than a single element at a time). This avoids the need to reallocate the arrays in CPU maps for each element. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
There's no reason for keeping the models in a linked list. Especially when we know upfront the total number of models we are loading. As a nice side effect, this fixes ppc64GetModels to always return a NULL-terminated list of models. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
There's no reason for keeping the vendors in a linked list. Especially when we know upfront the total number of models we are loading. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
There's no reason for keeping the features in a linked list. Especially when we know upfront the total number of features we are loading. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
There's no reason for keeping the vendors in a linked list. Especially when we know upfront the total number of models we are loading. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
There's no reason for keeping the models in a linked list. Especially when we know upfront the total number of models we are loading. As a nice side effect, this fixes x86GetModels to always return a NULL-terminated list of models. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 16 5月, 2016 18 次提交
-
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
When searching for the best CPU model for CPUID data we can easily ignore models with non-matching vendor before spending time on CPUID data to virCPUDef conversion. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
CPU map XML is our internal data file, it makes no sense to tolerate any errors in it. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
CPU map XML is our internal data file, it makes no sense to tolerate any errors in it. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
CPU map XML is our internal data file, it makes no sense to tolerate any errors in it. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The next pointer is initialized to NULL, overwriting to with another NULL doesn't hurt. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Splitting the comparison into a separate function makes the code cleaner and easier to update in the future. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-