- 27 3月, 2010 1 次提交
-
-
由 Jiri Denemark 提交于
Useful mainly for migration. cpuUpdate changes guest CPU requirements in the following way: - match == "strict" || match == "exact" - optional features which are supported by host CPU are changed into required features - optional features which are not supported by host CPU are disabled - all other features remain untouched - match == "minimum" - match is changed into "exact" - optional features and all features not mentioned in guest CPU specification which are supported by host CPU become required features - other optional features are disabled - all other features remain untouched This ensures that no feature will suddenly disappear from the guest after migration.
-
- 25 3月, 2010 1 次提交
-
-
由 Jiri Denemark 提交于
-
- 23 3月, 2010 1 次提交
-
-
由 Jiri Denemark 提交于
-
- 10 3月, 2010 1 次提交
-
-
由 Eric Blake 提交于
* global: patch created by running: for f in $(git ls-files '*.[ch]') ; do cppi $f > $f.t && mv $f.t $f done
-
- 08 3月, 2010 1 次提交
-
-
由 Eric Blake 提交于
Prior to this patch, there was an inconsistent mix between GNU and C99. For consistency, and potential portability to other compilers, stick with the C99 vararg macro syntax. * src/conf/cpu_conf.c (virCPUReportError): Use C99 rather than GNU vararg macro syntax. * src/conf/domain_conf.c (virDomainReportError): Likewise. * src/conf/domain_event.c (eventReportError): Likewise. * src/conf/interface_conf.c (virInterfaceReportError): Likewise. * src/conf/network_conf.c (virNetworkReportError): Likewise. * src/conf/node_device_conf.h (virNodeDeviceReportError): Likewise. * src/conf/secret_conf.h (virSecretReportError): Likewise. * src/conf/storage_conf.h (virStorageReportError): Likewise. * src/esx/esx_device_monitor.c (ESX_ERROR): Use C99 rather than GNU vararg macro syntax. * src/esx/esx_driver.c (ESX_ERROR): Likewise. * src/esx/esx_interface_driver.c (ESX_ERROR): Likewise. * src/esx/esx_network_driver.c (ESX_ERROR): Likewise. * src/esx/esx_secret_driver.c (ESX_ERROR): Likewise. * src/esx/esx_storage_driver.c (ESX_ERROR): Likewise. * src/esx/esx_util.c (ESX_ERROR): Likewise. * src/esx/esx_vi.c (ESX_VI_ERROR): Likewise. * src/esx/esx_vi_methods.c (ESX_VI_ERROR): Likewise. * src/esx/esx_vi_types.c (ESX_VI_ERROR): Likewise. * src/esx/esx_vmx.c (ESX_ERROR): Likewise. * src/util/hostusb.c (usbReportError): Use C99 rather than GNU vararg macro syntax. * src/util/json.c (virJSONError): Likewise. * src/util/macvtap.c (ReportError): Likewise. * src/util/pci.c (pciReportError): Likewise. * src/util/stats_linux.c (virStatsError): Likewise. * src/util/util.c (virUtilError): Likewise. * src/util/xml.c (virXMLError): Likewise. * src/xen/proxy_internal.c (virProxyError): Use C99 rather than GNU vararg macro syntax. * src/xen/sexpr.c (virSexprError): Likewise. * src/xen/xen_driver.c (xenUnifiedError): Likewise. * src/xen/xen_hypervisor.c (virXenError): Likewise. * src/xen/xen_inotify.c (virXenInotifyError): Likewise. * src/xen/xend_internal.c (virXendError): Likewise. * src/xen/xm_internal.c (xenXMError): Likewise. * src/xen/xs_internal.c (virXenStoreError): Likewise. * src/cpu/cpu.h (virCPUReportError): Use C99 rather than GNU vararg macro syntax. * src/datatypes.c (virLibConnError): Likewise. * src/interface/netcf_driver.c (interfaceReportError): Likewise. * src/libvirt.c (virLibStreamError): Likewise. * src/lxc/lxc_conf.h (lxcError): Likewise. * src/network/bridge_driver.c (networkReportError): Likewise. * src/nodeinfo.c (nodeReportError): Likewise. * src/opennebula/one_conf.h (oneError): Likewise. * src/openvz/openvz_conf.h (openvzError): Likewise. * src/phyp/phyp_driver.c (PHYP_ERROR): Likewise. * src/qemu/qemu_conf.h (qemuReportError): Likewise. * src/remote/remote_driver.c (errorf): Likewise. * src/security/security_driver.h (virSecurityReportError): Likewise. * src/test/test_driver.c (testError): Likewise. * src/uml/uml_conf.h (umlReportError): Likewise. * src/vbox/vbox_driver.c (vboxError): Likewise. * src/vbox/vbox_tmpl.c (vboxError): Likewise.
-
- 02 3月, 2010 1 次提交
-
-
由 Jim Meyering 提交于
* src/cpu/cpu_x86.c (x86Decode): Don't dereference NULL when passed a NULL "models" pointer, or when passed a nonzero "nmodels" value and a corresponding NULL models[i].
-
- 12 2月, 2010 3 次提交
-
-
由 Jiri Denemark 提交于
-
由 Jiri Denemark 提交于
-
由 Jiri Denemark 提交于
Baseline CPU is the best CPU which can be used for a guest on any of the hosts.
-
- 11 2月, 2010 1 次提交
-
-
由 Jiri Denemark 提交于
All other libvirt functions use array first and then number of elements in that array. Let's make cpuDecode follow this rule. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 10 2月, 2010 1 次提交
-
-
由 Daniel P. Berrange 提交于
The virConnectPtr is no longer required for error reporting since that is recorded in a thread local. Remove use of virConnectPtr from all APIs in cpu_conf.{h,c} and update all callers to match
-
- 09 2月, 2010 2 次提交
-
-
由 Matthias Bolte 提交于
It was used for error reporting only.
-
由 Matthias Bolte 提交于
-
- 02 2月, 2010 1 次提交
-
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 27 1月, 2010 1 次提交
-
-
由 Jim Meyering 提交于
* src/cpu/cpu_x86.c (x86Decode): Do not dereference NULL when "models" is NULL and nmodels is 1 or greater.
-
- 19 1月, 2010 2 次提交
-
-
由 Jiri Denemark 提交于
When comparing incompatible CPUs, the reason for this incompatibility is logged as a debug message. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
When comparing x86 CPUs, features with 'disabled' policy were mistakenly required to be supported by the host CPU. Likewise, features with 'force' policy which were supported by host CPU would make CPUs incompatible if 'strict' match was used by guest CPU. This patch fixes both issues. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 18 1月, 2010 2 次提交
-
-
由 Jim Meyering 提交于
* src/cpu/cpu_x86_data.h: Include <stdint.h>.
-
由 Jiri Denemark 提交于
Current implementation of x86Decode() used for CPUID -> model+features translation does not always select the closest CPU model. When walking through all models from cpu_map.xml the function considers a new candidate as a better choice than a previously selected candidate only if the new one is a superset of the old one. In case the new candidate is closer to host CPU but lacks some feature comparing to the old candidate, the function does not choose well. This patch changes the algorithm so that the closest model is always selected. That is, the model which requires the lowest number of additional features to describe host CPU. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 23 12月, 2009 1 次提交
-
-
由 Jiri Denemark 提交于
* src/Makefile.am src/cpu/cpu_map.c: rename in Makefile and in the cpu map loading code
-
- 22 12月, 2009 2 次提交
-
-
由 Matthias Bolte 提交于
-
由 Matthias Bolte 提交于
Also backup and restore the original ctxt->node value in x86FeatureLoad.
-
- 18 12月, 2009 2 次提交
-
-
由 Jiri Denemark 提交于
* src/cpu/cpu_map.xml: newdescription file * src/Makefile.am: include it in dist
-
由 Jiri Denemark 提交于
Each driver supporting CPU selection must fill in host CPU capabilities. When filling them, drivers for hypervisors running on the same node as libvirtd can use cpuNodeData() to obtain raw CPU data. Other drivers, such as VMware, need to implement their own way of getting such data. Raw data can be decoded into virCPUDefPtr using cpuDecode() function. When implementing virConnectCompareCPU(), a hypervisor driver can just call cpuCompareXML() function with host CPU capabilities. For each guest for which a driver supports selecting CPU models, it must set the appropriate feature in guest's capabilities: virCapabilitiesAddGuestFeature(guest, "cpuselection", 1, 0) Actions needed when a domain is being created depend on whether the hypervisor understands raw CPU data (currently CPUID for i686, x86_64 architectures) or symbolic names has to be used. Typical use by hypervisors which prefer CPUID (such as VMware and Xen): - convert guest CPU configuration from domain's XML into a set of raw data structures each representing one of the feature policies: cpuEncode(conn, architecture, guest_cpu_config, &forced_data, &required_data, &optional_data, &disabled_data, &forbidden_data) - create a mask or whatever the hypervisor expects to see and pass it to the hypervisor Typical use by hypervisors with symbolic model names (such as QEMU): - get raw CPU data for a computed guest CPU: cpuGuestData(conn, host_cpu, guest_cpu_config, &data) - decode raw data into virCPUDefPtr with a possible restriction on allowed model names: cpuDecode(conn, guest, data, n_allowed_models, allowed_models) - pass guest->model and guest->features to the hypervisor * src/cpu/cpu.c src/cpu/cpu.h src/cpu/cpu_generic.c src/cpu/cpu_generic.h src/cpu/cpu_map.c src/cpu/cpu_map.h src/cpu/cpu_x86.c src/cpu/cpu_x86.h src/cpu/cpu_x86_data.h * configure.in: check for CPUID instruction * src/Makefile.am: glue the new files in * src/libvirt_private.syms: add new private symbols * po/POTFILES.in: add new cpu files containing translatable strings
-