Commit Graph

156 Commits

Author SHA1 Message Date
Jiri Denemark
322707ba8a Use closest CPU model when decoding from CPUID
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: Jiri Denemark <jdenemar@redhat.com>
2010-01-18 02:40:41 +01:00
Jiri Denemark
913ab198fb Rename DATADIR to PKGDATADIR to fix win32 build
* src/Makefile.am src/cpu/cpu_map.c: rename in Makefile and in the
  cpu map loading code
2009-12-23 14:29:57 +01:00
Matthias Bolte
d4c1e5aeed Fix compilation with configure --disable-nls 2009-12-22 13:04:50 +01:00
Matthias Bolte
434daaff9a cpu: Fix memory leaks in x86FeatureLoad and x86ModelLoad
Also backup and restore the original ctxt->node value in x86FeatureLoad.
2009-12-22 13:04:50 +01:00
Jiri Denemark
d5ef0a69e9 Adds CPU map for models and features
* src/cpu/cpu_map.xml: newdescription file
* src/Makefile.am: include it in dist
2009-12-18 16:14:05 +01:00
Jiri Denemark
7286882c34 Adds CPU selection infrastructure
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
2009-12-18 16:13:45 +01:00