External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-12-29 09:05:25 +00:00
Code Issues Packages Projects Releases Wiki Activity
1c596f4964
libvirt/src/cpu/cpu_x86_data.h

80 lines
2.8 KiB
C
Raw Normal View History

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 15:02:11 +00:00
/*
* cpu_x86_data.h: x86 specific CPU data
*
cpu_x86: Refactor storage of CPUID data to add support for KVM features The CPUID functions were stored in multiple arrays according to a specified prefix of those. This made it very hard to add another prefix to store KVM CPUID features (0x40000000). Instead of hardcoding a third array this patch changes the approach used: The code is refactored to use a single array where the CPUID functions are stored ordered by the cpuid function so that they don't depend on the specific prefix and don't waste memory. The code is also less complex using this approach. A trateoff to this is the change from O(N) complexity to O(N^2) in x86DataAdd and x86DataSubtract. The rest of the functions were already using O(N^2) algorithms.
2013-10-07 13:26:17 +00:00
* Copyright (C) 2009-2010, 2013 Red Hat, Inc.
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 15:02:11 +00:00
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
maint: fix up copyright notice inconsistencies https://www.gnu.org/licenses/gpl-howto.html recommends that the 'If not, see <url>.' phrase be a separate sentence. * tests/securityselinuxhelper.c: Remove doubled line. * tests/securityselinuxtest.c: Likewise. * globally: s/; If/. If/
2012-09-20 22:30:55 +00:00
* License along with this library. If not, see
Desert the FSF address in copyright Per the FSF address could be changed from time to time, and GNU recommends the following now: (http://www.gnu.org/licenses/gpl-howto.html) You should have received a copy of the GNU General Public License along with Foobar. If not, see <http://www.gnu.org/licenses/>. This patch removes the explicit FSF address, and uses above instead (of course, with inserting 'Lesser' before 'General'). Except a bunch of files for security driver, all others are changed automatically, the copyright for securify files are not complete, that's why to do it manually: src/security/security_selinux.h src/security/security_driver.h src/security/security_selinux.c src/security/security_apparmor.h src/security/security_apparmor.c src/security/security_driver.c
2012-07-21 10:06:23 +00:00
* <http://www.gnu.org/licenses/>.
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 15:02:11 +00:00
*
* Authors:
* Jiri Denemark <jdenemar@redhat.com>
*/
#ifndef __VIR_CPU_X86_DATA_H__
build: consistently indent preprocessor directives * global: patch created by running: for f in $(git ls-files '*.[ch]') ; do cppi $f > $f.t && mv $f.t $f done
2010-03-09 18:22:22 +00:00
# define __VIR_CPU_X86_DATA_H__
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 15:02:11 +00:00
cpu_x86_data.h: include required header * src/cpu/cpu_x86_data.h: Include <stdint.h>.
2010-01-15 09:33:32 +00:00
cpu: x86: Rename struct cpuX86cpuid as virCPUx86CPUID
2013-07-23 18:00:14 +00:00
typedef struct _virCPUx86CPUID virCPUx86CPUID;
struct _virCPUx86CPUID {
cpu_x86: Rename CPUID function to eax_in CPUID instruction normally takes its parameter from EAX, but sometimes ECX is used as an additional parameter. Let's rename 'function' to 'eax_in' in preparation for adding 'ecx_in'. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-05-20 07:48:21 +00:00
uint32_t eax_in;
cpu_x86: Prepare for ecx_in CPUID parameter CPUID instruction normally takes its parameter from EAX, but sometimes ECX is used as an additional parameter. This patch prepares the x86 CPU driver code for the new 'ecx_in' CPUID parameter. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-05-20 08:59:13 +00:00
uint32_t ecx_in;
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 15:02:11 +00:00
uint32_t eax;
uint32_t ebx;
uint32_t ecx;
uint32_t edx;
};
build: consistently indent preprocessor directives * global: patch created by running: for f in $(git ls-files '*.[ch]') ; do cppi $f > $f.t && mv $f.t $f done
2010-03-09 18:22:22 +00:00
# define CPUX86_BASIC 0x0
cpu: x86: Add internal CPUID features support and KVM feature bits Some of the emulator features are presented in the <features> element in the domain XML although they are virtual CPUID feature bits when presented to the guest. To avoid confusing the users with these features, as they are not configurable via the <cpu> element, this patch adds an internal array where those can be stored privately instead of exposing them in the XML. Additionaly KVM feature bits are added as example usage of this code.
2013-10-09 09:42:24 +00:00
# define CPUX86_KVM 0x40000000
build: consistently indent preprocessor directives * global: patch created by running: for f in $(git ls-files '*.[ch]') ; do cppi $f > $f.t && mv $f.t $f done
2010-03-09 18:22:22 +00:00
# define CPUX86_EXTENDED 0x80000000
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 15:02:11 +00:00
cpu: x86: Add internal CPUID features support and KVM feature bits Some of the emulator features are presented in the <features> element in the domain XML although they are virtual CPUID feature bits when presented to the guest. To avoid confusing the users with these features, as they are not configurable via the <cpu> element, this patch adds an internal array where those can be stored privately instead of exposing them in the XML. Additionaly KVM feature bits are added as example usage of this code.
2013-10-09 09:42:24 +00:00
# define VIR_CPU_x86_KVM_CLOCKSOURCE "__kvm_clocksource"
# define VIR_CPU_x86_KVM_NOP_IO_DELAY "__kvm_no_io_delay"
# define VIR_CPU_x86_KVM_MMU_OP "__kvm_mmu_op"
# define VIR_CPU_x86_KVM_CLOCKSOURCE2 "__kvm_clocksource2"
# define VIR_CPU_x86_KVM_ASYNC_PF "__kvm_async_pf"
# define VIR_CPU_x86_KVM_STEAL_TIME "__kvm_steal_time"
# define VIR_CPU_x86_KVM_PV_EOI "__kvm_pv_eoi"
# define VIR_CPU_x86_KVM_PV_UNHALT "__kvm_pv_unhalt"
# define VIR_CPU_x86_KVM_CLOCKSOURCE_STABLE_BIT "__kvm_clocksource_stable"
cpu: fix typo: rename __kvm_hv_spinlock to __kvm_hv_spinlocks Strings associated with virDomainHyperv values in domain_conf.c are used to construct HyperV CPU features names to be compared with names defined in cpu_x86_data.h and the names for HyperV "spinlocks" feature don't match. This leads to a misleading warning: "host doesn't support hyperv 'spinlocks' feature" even when it's supported. Let's fix it and rename along with it VIR_CPU_x86_KVM_HV_SPINLOCK to VIR_CPU_x86_KVM_HV_SPINLOCKS. Signed-off-by: Maxim Nestratov <mnestratov@virtuozzo.com>
2017-01-31 14:12:13 +00:00
/*
* The following HyperV feature names suffixes must exactly match corresponding
* ones defined for virDomainHyperv in domain_conf.c.
* E.g "__kvm_runtime" -> "runtime", "__kvm_hv_spinlocks" -> "spinlocks" etc.
*/
qemu_process: add check for hyperv features Commit 7068b56c introduced several hyperv features. Not all hyperv features are supported by old enough kernels and we shouldn't allow to start a guest if kernel doesn't support any of the hyperv feature. There is one exception, for backward compatibility we cannot error out if one of the RELAXED, VAPIC or SPINLOCKS isn't supported, for the same reason we ignore invtsc, to not break restoring saved domains with older libvirt. Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2016-03-29 13:17:45 +00:00
# define VIR_CPU_x86_KVM_HV_RUNTIME "__kvm_hv_runtime"
# define VIR_CPU_x86_KVM_HV_SYNIC "__kvm_hv_synic"
# define VIR_CPU_x86_KVM_HV_STIMER "__kvm_hv_stimer"
# define VIR_CPU_x86_KVM_HV_RELAXED "__kvm_hv_relaxed"
cpu: fix typo: rename __kvm_hv_spinlock to __kvm_hv_spinlocks Strings associated with virDomainHyperv values in domain_conf.c are used to construct HyperV CPU features names to be compared with names defined in cpu_x86_data.h and the names for HyperV "spinlocks" feature don't match. This leads to a misleading warning: "host doesn't support hyperv 'spinlocks' feature" even when it's supported. Let's fix it and rename along with it VIR_CPU_x86_KVM_HV_SPINLOCK to VIR_CPU_x86_KVM_HV_SPINLOCKS. Signed-off-by: Maxim Nestratov <mnestratov@virtuozzo.com>
2017-01-31 14:12:13 +00:00
# define VIR_CPU_x86_KVM_HV_SPINLOCKS "__kvm_hv_spinlocks"
qemu_process: add check for hyperv features Commit 7068b56c introduced several hyperv features. Not all hyperv features are supported by old enough kernels and we shouldn't allow to start a guest if kernel doesn't support any of the hyperv feature. There is one exception, for backward compatibility we cannot error out if one of the RELAXED, VAPIC or SPINLOCKS isn't supported, for the same reason we ignore invtsc, to not break restoring saved domains with older libvirt. Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2016-03-29 13:17:45 +00:00
# define VIR_CPU_x86_KVM_HV_VAPIC "__kvm_hv_vapic"
# define VIR_CPU_x86_KVM_HV_VPINDEX "__kvm_hv_vpindex"
# define VIR_CPU_x86_KVM_HV_RESET "__kvm_hv_reset"
conf: qemu: add support for Hyper-V frequency MSRs Qemu-2.12 gained 'hv-frequencies' cpu flag to enable Hyper-V frequency MSRs. These MSRs are required (but not sufficient) to make Hyper-V on KVM pass stable TSC page clocksource to L2 guests. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2018-08-09 13:14:19 +00:00
# define VIR_CPU_x86_KVM_HV_FREQUENCIES "__kvm_hv_frequencies"
conf: qemu: add support for Hyper-V reenlightenment notifications Qemu-3.0 supports so-called 'Reenlightenment' notifications and this (in conjunction with 'hv-frequencies') can be used make Hyper-V on KVM pass stable TSC page clocksource to L2 guests. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2018-08-09 13:14:20 +00:00
# define VIR_CPU_x86_KVM_HV_REENLIGHTENMENT "__kvm_hv_reenlightenment"
conf: qemu: add support for Hyper-V PV TLB flush Qemu-3.0 supports Hyper-V-style PV TLB flush, Windows guests can benefit from this feature as KVM knows which vCPUs are not currently scheduled (and thus don't require any immediate action). Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2018-08-09 13:14:21 +00:00
# define VIR_CPU_x86_KVM_HV_TLBFLUSH "__kvm_hv_tlbflush"
conf: add support for Hyper-V PV IPIs Support Hyper-V PV IPI enlightenment in domain config. QEMU support will be implemented in the next patch, adding interim VIR_DOMAIN_HYPERV_IPI cases to src/qemu/* for now. Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
2018-11-14 22:46:04 +00:00
# define VIR_CPU_x86_KVM_HV_IPI "__kvm_hv_ipi"
cpu: x86: Add internal CPUID features support and KVM feature bits Some of the emulator features are presented in the <features> element in the domain XML although they are virtual CPUID feature bits when presented to the guest. To avoid confusing the users with these features, as they are not configurable via the <cpu> element, this patch adds an internal array where those can be stored privately instead of exposing them in the XML. Additionaly KVM feature bits are added as example usage of this code.
2013-10-09 09:42:24 +00:00
cpu_x86: Avoid unnecessary pointers to virCPUx86Data virCPUData, virCPUx86Feature, and virCPUx86Model all contained a pointer to virCPUx86Data, which was not very nice since the real CPUID data were accessible by yet another pointer from virCPUx86Data. Moreover, using virCPUx86Data directly will make static definitions of internal CPU features a bit easier. Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-06-07 07:38:53 +00:00
# define VIR_CPU_X86_DATA_INIT { 0 }
cpu: x86: Rename struct cpuX86Data as virCPUx86Data
2013-07-23 18:03:30 +00:00
typedef struct _virCPUx86Data virCPUx86Data;
struct _virCPUx86Data {
cpu_x86: Refactor storage of CPUID data to add support for KVM features The CPUID functions were stored in multiple arrays according to a specified prefix of those. This made it very hard to add another prefix to store KVM CPUID features (0x40000000). Instead of hardcoding a third array this patch changes the approach used: The code is refactored to use a single array where the CPUID functions are stored ordered by the cpuid function so that they don't depend on the specific prefix and don't waste memory. The code is also less complex using this approach. A trateoff to this is the change from O(N) complexity to O(N^2) in x86DataAdd and x86DataSubtract. The rest of the functions were already using O(N^2) algorithms.
2013-10-07 13:26:17 +00:00
size_t len;
virCPUx86CPUID *data;
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 15:02:11 +00:00
};
#endif /* __VIR_CPU_X86_DATA_H__ */
Reference in New Issue Copy Permalink