- 16 10月, 2017 4 次提交
-
-
由 Jiri Denemark 提交于
If the actual result does not match our expectation, the tests would not correctly show the difference if a CPU feature is disabled in the expected result and the actual result does not mention it at all. The test could complain about an unrelated CPU feature or it could even crash in case the actual result contains no more features to go through. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Jiri Denemark 提交于
We will soon need to handle more than two values. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Jiri Denemark 提交于
The "preferred" parameter is not used by any caller of cpuDecode anymore. It's only used internally in cpu_x86 to implement cpuBaseline. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Jiri Denemark 提交于
All APIs which expect a list of CPU models supported by hypervisors were switched from char **models and int models to just accept a pointer to virDomainCapsCPUModels object stored in domain capabilities. This avoids the need to transform virDomainCapsCPUModelsPtr into a NULL-terminated list of model names and also allows the various cpu driver APIs to access additional details (such as its usability) about each CPU model. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
- 21 9月, 2017 1 次提交
-
-
由 Jiri Denemark 提交于
In the past we updated host-model CPUs with host CPU data by adding a model and features, but keeping the host-model mode. And since the CPU model is not normally formatted for host-model CPU defs, we had to pass the updateCPU flag to the formatting code to be able to properly output updated host-model CPUs. Libvirt doesn't do this anymore, host-model CPUs are turned into custom mode CPUs once updated with host CPU data and thus there's no reason for keeping the hacks inside CPU XML formatters. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 18 9月, 2017 1 次提交
-
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
- 07 9月, 2017 2 次提交
-
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
- 13 7月, 2017 1 次提交
-
-
由 Jiri Denemark 提交于
CPU features unknown to a hypervisor will not be present in dataDisabled even though the features won't naturally be enabled because. Thus any features we asked for which are not in dataEnabled should be considered disabled. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 07 6月, 2017 1 次提交
-
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
- 19 4月, 2017 1 次提交
-
-
由 Jiri Denemark 提交于
We already know from QEMU which CPU features will block migration. Let's use this information to make a migratable copy of the host CPU model and use it for updating guest CPU specification. This will allow us to drop feature filtering from virCPUUpdate where it was just a hack. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 07 4月, 2017 3 次提交
-
-
由 Jiri Denemark 提交于
This reverts commit 959e72d3 which was pushed accidentally.
-
由 Jiri Denemark 提交于
This will allow us to drop feature filtering from virCPUUpdate where it was just a hack. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The caller can ask for a migratable CPU model by passing true for the new parameter. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 04 4月, 2017 1 次提交
-
-
由 Andrea Bolognani 提交于
We use the "vir" prefix pretty consistently in our APIs, both external and internal, which made these macros stood out.
-
- 30 3月, 2017 1 次提交
-
-
由 Jiri Denemark 提交于
If calling query-cpu-model-expansion on the 'host'/'max' CPU model with 'migratable' property set to false succeeds, we know QEMU is able to tell us which features would disable migration. Thus we can mark all enabled features as migratable. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 27 3月, 2017 3 次提交
-
-
由 Jiri Denemark 提交于
The test takes x86-cpuid-Something-guest.xml CPU (the CPU libvirt would use for host-model on a CPU described by x86_64-cpuid-Something.xml without talking to QEMU about what it supports on the host) and updates it according to CPUID data from QEMU: x86_64-cpuid-Something-enabled.xml (reported as "feature-words" property of the CPU device) and x86_64-cpuid-Something-disabled.xml (reported as "filtered-features" property of the CPU device). The result is compared to x86_64-cpuid-Something-json.xml (the CPU libvirt would use as host-model based on the reply from query-cpu-model-expansion). The comparison is a bit tricky because the *-json.xml CPU contains fewer disabled features. Only the features which are included in the base CPU model, but listed as disabled in *.json will be disabled in *-json.xml. The CPU computed by virCPUUpdateLive from the test data will list all features present in the host's CPUID data and not enabled in *.json as disabled. The cpuTestUpdateLiveCompare function checks that the computed and expected sets of enabled features match. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The public API flags are handled by the cpuBaselineXML wrapper. The internal cpuBaseline API only needs to know whether it is supposed to drop non-migratable features. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
cpuBaseline is responsible for computing a baseline CPU while feature expansion is done by virCPUExpandFeatures. The cpuBaselineXML wrapper (used by hypervisor drivers to implement virConnectBaselineCPU API) calls cpuBaseline followed by virCPUExpandFeatures if requested by VIR_CONNECT_BASELINE_CPU_EXPAND_FEATURES flag. The features in the three changed test files had to be sorted using "sort -k 3" because virCPUExpandFeatures returns a sorted list of features. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 23 3月, 2017 1 次提交
-
-
由 Andrea Bolognani 提交于
-
- 14 3月, 2017 1 次提交
-
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 04 3月, 2017 3 次提交
-
-
由 Jiri Denemark 提交于
All existing Haswell CPUID data were gathered from CPUs with broken TSX. Let's add new data for Haswell with correct TSX implementation. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The original test didn't use family/model numbers to make better decisions about the CPU model and thus mis-detected the model in the two cases which are modified in this commit. The detected CPU models now match those obtained from raw CPUID data. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 24 2月, 2017 3 次提交
-
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
While "x86" is a CPU sub driver name, it is not a recognized name of any architecture known to libvirt. Let's use "x86_64" prefix which can be used with virArch APIs. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The new API is called virCPUDataFree. Individual CPU drivers are no longer required to implement their own freeing function unless they need to free architecture specific data from virCPUData. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 15 11月, 2016 8 次提交
-
-
由 Jiri Denemark 提交于
PPC driver needs to convert POWERx_v* legacy CPU model names into POWERx to maintain backward compatibility with existing domains. This patch adds a new step into the guest CPU configuration work flow which CPU drivers can use to convert legacy CPU definitions. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The API is no longer used anywhere else since it was replaced by a much saner work flow utilizing new APIs that work on virCPUDefPtr directly: virCPUCompare, virCPUUpdate, and virCPUTranslate. Not testing the new work flow caused some bugs to be hidden. This patch reveals them, but doesn't attempt to fix them. To make sure all test still pass after this patch, all affected test results are modified to pretend the tests succeeded. All of the bugs will be fixed in the following commits and the artificial modifications will be reverted. The following is the list of bugs in the new CPU model work flow: - a guest CPU with mode='custom' and missing <vendor/> gets the vendor copied from host's CPU (the vendor should only be copied to host-model CPUs): DO_TEST_UPDATE("x86", "host", "min", VIR_CPU_COMPARE_IDENTICAL) DO_TEST_UPDATE("x86", "host", "pentium3", VIR_CPU_COMPARE_IDENTICAL) DO_TEST_GUESTCPU("x86", "host-better", "pentium3", NULL, 0) - when a guest CPU with mode='custom' needs to be translated into another model because the original model is not supported by a hypervisor, the result will have its vendor set to the vendor of the original CPU model as specified in cpu_map.xml even if the original guest CPU XML didn't contain <vendor/>: DO_TEST_GUESTCPU("x86", "host", "guest", model486, 0) DO_TEST_GUESTCPU("x86", "host", "guest", models, 0) DO_TEST_GUESTCPU("x86", "host-Haswell-noTSX", "Haswell-noTSX", haswell, 0) - legacy POWERx_v* model names are not recognized: DO_TEST_GUESTCPU("ppc64", "host", "guest-legacy", ppc_models, 0) Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Now that all tests pass NULL as the preferred model, we can just drop that test parameter. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
In some cases preferred model doesn't really do anything since the result remains the same even if it is removed. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Using a preferred model for guest CPUs with forbidden fallback masks a bug in the code. It would just happily use another CPU model supported by a hypervisor even though it is explicitly forbidden in the CPU XML. This patch temporarily changes the expected result to -2, which is used when the result XML file cannot be found (but it was supposed not to be found since the tested API should have failed). The result will be switched back to -1 few commits later when the original bug gets fixed. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Using a preferred CPU model which is not in the list of CPU models supported by a hypervisor does not make sense. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Guest CPUs with match='minimum' should always be updated to match host CPU model. Trying to get different results by supplying preferred models does not make sense. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The new name is virCPUDataParse. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 22 9月, 2016 4 次提交
-
-
由 Jiri Denemark 提交于
Both cpuCompare* APIs are renamed to virCPUCompare*. And they should now work for any guest CPU definition, i.e., even for host-passthrough (trivial) and host-model CPUs. The implementation in x86 driver is enhanced to provide a hint about -noTSX Broadwell and Haswell models when appropriate. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The function is similar to virCPUDataCheckFeature, but it works directly on CPU definition rather than requiring it to be transformed into CPU data first. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The reworked API is now called virCPUUpdate and it should change the provided CPU definition into a one which can be consumed by the QEMU command line builder: - host-passthrough remains unchanged - host-model is turned into custom CPU with a model and features copied from host - custom CPU with minimum match is converted similarly to host-model - optional features are updated according to host's CPU Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 14 6月, 2016 1 次提交
-
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-