- 28 5月, 2018 2 次提交
-
-
由 Jiri Denemark 提交于
This is required for virCPUBaseline to accept a list of guest CPU definitions since they do not have arch set. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NCollin Walling <walling@linux.ibm.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
- 16 10月, 2017 3 次提交
-
-
由 Jiri Denemark 提交于
This internal API can be used to find a specific CPU model in virDomainCapsCPUModels list. 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>
-
- 18 9月, 2017 4 次提交
-
-
由 Jiri Denemark 提交于
This new API may be used to check whether all features used in a CPU definition are valid (e.g., libvirt knows their name, their policy is supported, etc.). Leaving this API unimplemented in an arch subdriver means libvirt does not restrict CPU features usable on the associated architectures. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The implementation of virConnectBaselineCPU may be different for each hypervisor. Thus it shouldn't really be implmented in the cpu code. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
They are logged in cpuBaseline anyway. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
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 提交于
Sometimes we want to call virCPUGetHost only when it is implemented for a given architecture to avoid logging expected and possibly misleading errors. The new virCPUGetHostIsSupported API may be used to guard such calls to virCPUGetHost. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 07 4月, 2017 1 次提交
-
-
由 Jiri Denemark 提交于
This new internal API makes a copy of virCPUDef while removing all features which would block migration. It uses cpu_map.xml as a database of such features, which should only be used as a fallback when we cannot get the data from a hypervisor. The main goal of this API is to decouple this filtering from virCPUUpdate so that the hypervisor driver can filter the features according to the hypervisor. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 27 3月, 2017 7 次提交
-
-
由 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>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Having to use cpuBaseline with VIR_CONNECT_BASELINE_CPU_EXPAND_FEATURES flag to expand CPU features is strange. Not to mention that cpuBaseline can only expand host CPU definitions (i.e., it completely ignores feature policies). The new virCPUExpandFeatures API is designed to work with both host and guest CPU definitions. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Martin Kletzander 提交于
There is no "node driver" as there was before, drivers have to do their own ACL checking anyway, so they all specify their functions and nodeinfo is basically just extending conf/capablities. Hence moving the code to src/conf/ is the right way to go. Also that way we can de-duplicate some code that is in virsysfs and/or virhostcpu that got duplicated during the virhostcpu.c split. And Some cleanup is done throughout the changes, like adding the vir* prefix etc. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
Both QEMU and bhyve are using the same function for setting up the CPU in virCapabilities, so de-duplicate it, save code and time, and help other drivers adopt it. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 17 3月, 2017 2 次提交
-
-
由 Jiri Denemark 提交于
When guest CPU definition uses VIR_CPU_CHECK_FULL checks, we need to make sure QEMU does not add or remove any features. https://bugzilla.redhat.com/show_bug.cgi?id=822148 https://bugzilla.redhat.com/show_bug.cgi?id=824989Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
When starting a domain with custom guest CPU specification QEMU may add or remove some CPU features. There are several reasons for this, e.g., QEMU/KVM does not support some requested features or the definition of the requested CPU model in libvirt's cpu_map.xml differs from the one QEMU is using. We can't really avoid this because CPU models are allowed to change with machine types and libvirt doesn't know (and probably doesn't even want to know) about such changes. Thus when we want to make sure guest ABI doesn't change when a domain gets migrated to another host, we need to update our live CPU definition according to the CPU QEMU created. Once updated, we will change CPU checking to VIR_CPU_CHECK_FULL to make sure the virtual CPU created after migration exactly matches the one on the source. https://bugzilla.redhat.com/show_bug.cgi?id=822148 https://bugzilla.redhat.com/show_bug.cgi?id=824989Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 14 3月, 2017 3 次提交
-
-
由 Jiri Denemark 提交于
When creating host CPU definition usable with a given emulator, the CPU should not be defined using an unsupported CPU model. The new @models and @nmodels parameters can be used to limit CPU models which can be used in the result. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The parameter can be used to request either VIR_CPU_TYPE_HOST (which has been assumed so far) or VIR_CPU_TYPE_GUEST definition. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
cpuNodeData has always been followed by cpuDecode as no hypervisor driver is really interested in raw CPUID data for a host CPU. Let's create a new CPU driver API which returns virCPUDefPtr directly. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 24 2月, 2017 1 次提交
-
-
由 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>
-
- 22 2月, 2017 2 次提交
-
-
由 Jiri Denemark 提交于
virCPUDef.arch is not required to be filled in for guest CPU definitions. It doesn't make sense to artificially mandate it to be set when cpuDecode is called especially when virCPUData.arch passed to cpuDecode already contains the architecture. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 15 11月, 2016 7 次提交
-
-
由 Jiri Denemark 提交于
The API is not used anywhere in the code. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 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 doesn't change the array so let's make it constant. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The new name is virCPUDataFormat. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The new name is virCPUDataParse. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The new name is virCPUModelIsAllowed. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The new name is virCPUGetModels. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 22 9月, 2016 6 次提交
-
-
由 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 提交于
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 提交于
To match our coding style and to provide better debug and error messages. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The API is supposed to make sure the provided CPU definition does not use a CPU model which is not supported by the hypervisor (if at all possible, of course). Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-