Commit Graph

16 Commits

Author SHA1 Message Date
Eric Blake
d89dd42d51 maint: simplify lots of libxml2 clients
Repetitive patterns should be factored.  The sign of a good
factorization is a change that kills 5x more lines than it adds :)

* src/conf/domain_conf.c (virDomainDeviceDefParse)
(virDomainSnapshotDefParseString): Use new convenience macros.
* src/conf/storage_conf.c (virStoragePoolDefParseSourceString):
Likewise.
* src/cpu/cpu.c (cpuCompareXML, cpuBaselineXML): Likewise.
* src/esx/esx_vi.c (esxVI_Context_Execute): Likewise.
* src/qemu/qemu_migration.c (qemuMigrationCookieXMLParseStr):
Likewise.
* src/security/virt-aa-helper.c (caps_mockup): Likewise.
* src/test/test_driver.c (testOpenFromFile): Likewise.
* tests/cputest.c (cpuTestLoadXML, cpuTestLoadMultiXML):
Likewise.
* tools/virsh.c (cmdFreecell, makeCloneXML, cmdVNCDisplay)
(cmdTTYConsole, cmdDetachInterface, cmdDetachDisk)
(cmdSnapshotCreate, cmdSnapshotCreateAs, cmdSnapshotCurrent)
(cmdSnapshotList, cmdSnapshotParent): Likewise.
2011-08-19 09:13:55 -06:00
Daniel P. Berrange
f98a6cd6ae Enable support for nested SVM
This enables support for nested SVM using the regular CPU
model/features block. If the CPU model or features include
'svm', then the '-enable-nesting' flag will be added to the
QEMU command line. Latest out of tree patches for nested
'vmx', no longer require the '-enable-nesting' flag. They
instead just look at the cpu features. Several of the models
already include svm support, but QEMU was just masking out
the svm bit silently. So this will enable SVM on such
models

* src/qemu/qemu_conf.h: flag for -enable-nesting
* src/qemu/qemu_conf.c: Use -enable-nesting if VMX or SVM are in
  the CPUID
* src/cpu/cpu.h, src/cpu/cpu.c: API to check for a named feature
* src/cpu/cpu_x86.c: x86 impl of feature check
* src/libvirt_private.syms: Add cpuHasFeature
* src/qemuhelptest.c: Add nesting flag where required
2010-10-13 16:45:31 +01:00
Jiri Denemark
f5055f2310 cpuCompare: Fix crash on unexpected CPU XML
When comparing a CPU without <model> element, such as

    <cpu>
        <topology sockets='1' cores='1' threads='1'/>
    </cpu>

libvirt would happily crash without warning.
2010-07-12 19:45:22 +02:00
Jiri Denemark
af53714f47 cpu: Add support for CPU vendor
By specifying <vendor> element in CPU requirements a guest can be
restricted to run only on CPUs by a given vendor. Host CPU vendor is
also specified in capabilities XML.

The vendor is checked when migrating a guest but it's not forced, i.e.,
guests configured without <vendor> element can be freely migrated.
2010-07-07 17:26:00 +02:00
Jiri Denemark
4e0f648fbb cpuBaseline: Don't mess with the CPU returned by arch driver
All features in the baseline CPU definition were always created with
policy='require' even though an arch driver returned them with different
policy settings.
2010-07-07 17:24:53 +02:00
Jiri Denemark
b9a2552d2a Use configured CPU model if possible
Adds ability to provide a preferred CPU model for CPUID data decoding.
Such model would be considered as the best possible model (if it's
supported by hypervisor) regardless on number of features which have to
be added or removed for describing required CPU.
2010-04-22 10:20:50 +02:00
Jiri Denemark
661ae104c2 cpuUpdate() for updating guest CPU according to host CPU
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.
2010-03-26 23:01:58 +01:00
Jiri Denemark
e36be6e7c7 Add entry point logging for cpu functions 2010-03-25 14:51:52 +01:00
Jiri Denemark
81e99f014b Fix error reporting when parsing CPU XML strings 2010-03-23 15:40:10 +01:00
Jiri Denemark
388f3cb565 Functions for computing baseline CPU from a set of host CPUs
Baseline CPU is the best CPU which can be used for a guest on any of the
hosts.
2010-02-12 14:16:23 +01:00
Jiri Denemark
8efec111fc Swap position of nmodels and models parameters in cpuDecode()
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: Jiri Denemark <jdenemar@redhat.com>
2010-02-11 16:46:20 +01:00
Daniel P. Berrange
f430ddb624 Remove virConnectPtr from CPU XML APIs
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
2010-02-10 13:32:38 +00:00
Matthias Bolte
8ce5e2c1ab Remove conn parameter from virReportOOMError 2010-02-09 01:04:54 +01:00
Jiri Denemark
1e44c678fa Move models/nmodels mismatch checking one level up
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2010-02-01 17:20:27 +01:00
Matthias Bolte
d4c1e5aeed Fix compilation with configure --disable-nls 2009-12-22 13:04:50 +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