Commit Graph

393 Commits

Author SHA1 Message Date
Vitaly Kuznetsov
f4c39db736 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-16 12:50:18 -04:00
Vitaly Kuznetsov
b5d770e155 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-16 12:46:49 -04:00
Vitaly Kuznetsov
8253bca961 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-16 12:45:55 -04:00
Daniel P. Berrangé
2625722cbc cpu: add 'amd-ssbd' and 'amd-no-ssb' CPU features (CVE-2018-3639)
AMD x86 CPUs have two separate ways to mitigate the Speculative Store
Bypass hardware flaw. In current processors only non-architectural MSRs
are available, and so hypervisors must expose a virtualized MSR and CPU
flag "virt-ssbd" (CPUID Function 8000_0008, EBX[25]=1).

In future processors AMD will provide an architectural MSR, indicated by
existance of the CPUID Function 8000_0008, EBX[24]=1, to which QEMU has
given the name "amd-ssbd".

The "amd-ssbd" flag should be used in preference to "virt-ssbd", if it
is available, since it provides improved performance. For virtual
machine configuration, both should be exposed when available, to allow
for maximal guest OS compatibility as not all guests yet support both.

If future processes are not vulnerable to the flaw, this will be
indicated by the existance of CPUID Function 8000_0008, EBX[26]=1,
to which QEMU has given the name "amd-no-ssb".

See also 124441_AMD64_SpeculativeStoreBypassDisable_Whitepaper_final.pdf
from:

  https://bugzilla.kernel.org/show_bug.cgi?id=199889

Note that neither amd-ssbd or amd-no-ssb will be reported by the kernel
in /proc/cpuinfo. It knows about these CPUID bits and does the right thing,
but doesn't report their existance as distinct flags in /proc/cpuinfo.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-07-03 17:31:46 +01:00
Jiri Denemark
7fb950958a cpu: Add optional list of allowed features to virCPUBaseline
When computing a baseline CPU for a specific hypervisor we have to make
sure to include only CPU features supported by the hypervisor. Otherwise
the computed CPU could not be used for starting a new domain.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Collin Walling <walling@linux.ibm.com>
2018-05-28 15:59:11 +02:00
Jiri Denemark
f277fb39b7 cpu: Update style in virCPUBaseline
To make it more consistent with the rest of the CPU driver code.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Collin Walling <walling@linux.ibm.com>
2018-05-28 15:59:10 +02:00
Jiri Denemark
f8c9f6ea2d cpu: Add explicit arch parameter for virCPUBaseline
This is required for virCPUBaseline to accept a list of guest CPU
definitions since they do not have arch set.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Collin Walling <walling@linux.ibm.com>
2018-05-28 15:59:10 +02:00
Jiri Denemark
388a5c1400 cpu_x86: Add support for passing guest CPUs to virCPUx86Baseline
Modern host CPU models from domain capabilities XMLs are reported as
guest CPU definitions with feature policies. This patch updates
virCPUx86Baseline to properly handle such CPU models.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-05-28 15:59:10 +02:00
Jiri Denemark
5ed6cf96bc cpu: Rename cpuBaseline as virCPUBaseline
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-05-28 15:59:10 +02:00
Daniel P. Berrangé
9267342206 cpu: define the 'virt-ssbd' CPUID feature bit (CVE-2018-3639)
Some AMD processors only support a non-architectural means of
enabling Speculative Store Bypass Disable. To allow simplified
handling in virtual environments, hypervisors will expose an
architectural definition through CPUID bit 0x80000008_EBX[25].
This needs to be exposed to guest OS running on AMD x86 hosts to
allow them to protect against CVE-2018-3639.

Note that since this CPUID bit won't be present in the host CPUID
results on physical hosts, it will not be enabled automatically
in guests configured with "host-model" CPU unless using QEMU
version >= 2.9.0. Thus for older versions of QEMU, this feature
must be manually enabled using policy=force. Guests using the
"host-passthrough" CPU mode do not need special handling.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2018-05-22 13:13:27 +02:00
Daniel P. Berrangé
1dbca2ecca cpu: define the 'ssbd' CPUID feature bit (CVE-2018-3639)
New microcode introduces the "Speculative Store Bypass Disable"
CPUID feature bit. This needs to be exposed to guest OS to allow
them to protect against CVE-2018-3639.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2018-05-22 13:13:26 +02:00
Daniel P. Berrangé
240c62ae50 make: split CPU build rules into cpu/Makefile.inc.am
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-03-05 17:12:01 +00:00
Shaohe Feng
e7cb9c4e23 cpu: Add support for al57 Intel features
We can start qemu with a "cpu,+la57" to set 57-bit vitrual address
space. So VM can be aware that it need to enable 5-level paging.

Corresponding QEMU commits:
        al57 6c7c3c21f95dd9af8a0691c0dd29b07247984122
2018-01-25 15:30:32 +01:00
Jiri Denemark
6d4a3cd427 cpu: Add EPYC-IBPB CPU model
This is a variant of EPYC with indirect branch prediction protection.
The only difference between EPYC and EPYC-IBPB is the added "ibpb"
feature.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2018-01-18 15:04:18 +01:00
Jiri Denemark
24d504396c cpu: Add Skylake-Server-IBRS CPU model
This is a variant of Skylake-Server with indirect branch prediction
protection. The only difference between Skylake-Server and
Skylake-Server-IBRS is the added "spec-ctrl" feature.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2018-01-17 17:07:04 +01:00
Jiri Denemark
b2042020c3 cpu: Add Skylake-Client-IBRS CPU model
This is a variant of Skylake-Client with indirect branch prediction
protection. The only difference between Skylake-Client and
Skylake-Client-IBRS is the added "spec-ctrl" feature.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2018-01-17 17:07:04 +01:00
Jiri Denemark
7bb4ce9761 cpu: Add Broadwell-IBRS CPU model
This is a variant of Broadwell with indirect branch prediction
protection. The only difference between Broadwell and Broadwell-IBRS is
the added "spec-ctrl" feature.

The Broadwell-IBRS model in QEMU is a bit different since Broadwell got
several additional features since we added it in cpu_map.xml:
    abm, arat, f16c, rdrand, vme, xsaveopt

Adding them only to the -IBRS variant would confuse our CPU detection
code.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2018-01-17 17:07:04 +01:00
Jiri Denemark
49bffcb3cc cpu: Add Broadwell-noTSX-IBRS CPU model
This is a variant of Broadwell-noTSX with indirect branch prediction
protection. The only difference between Broadwell-noTSX and
Broadwell-noTSX-IBRS is the added "spec-ctrl" feature.

The Broadwell-noTSX-IBRS model in QEMU is a bit different since
Broadwell-noTSX got several additional features since we added it in
cpu_map.xml:
    abm, arat, f16c, rdrand, vme, xsaveopt

Adding them only to the -IBRS variant would confuse our CPU detection
code.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2018-01-17 17:07:03 +01:00
Jiri Denemark
7f83eefa9e cpu: Add Haswell-IBRS CPU model
This is a variant of Haswell with indirect branch prediction protection.
The only difference between Haswell and Haswell-IBRS is the added
"spec-ctrl" feature.

The Haswell-IBRS model in QEMU is a bit different since Haswell got
several additional features since we added it in cpu_map.xml:
    arat, abm, f16c, rdrand, vme, xsaveopt

Adding them only to the -IBRS variant would confuse our CPU detection
code.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2018-01-17 17:07:03 +01:00
Jiri Denemark
7dd85ff62d cpu: Add Haswell-noTSX-IBRS CPU model
This is a variant of Haswell-noTSX with indirect branch prediction
protection. The only difference between Haswell-noTSX and
Haswell-noTSX-IBRS is the added "spec-ctrl" feature.

The Haswell-noTSX-IBRS model in QEMU is a bit different since
Haswell-noTSX got several additional features since we added it in
cpu_map.xml:
    arat, abm, f16c, rdrand, vme, xsaveopt

Adding them only to the -IBRS variant would confuse our CPU detection
code.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2018-01-17 17:07:03 +01:00
Jiri Denemark
203c92e9cc cpu: Add IvyBridge-IBRS CPU model
This is a variant of IvyBridge with indirect branch prediction
protection. The only difference between IvyBridge and IvyBridge-IBRS is
the added "spec-ctrl" feature.

The IvyBridge-IBRS model in QEMU is a bit different since IvyBridge got
several additional features since we added it in cpu_map.xml:
    arat, vme, xsaveopt

Adding them only to the -IBRS variant would confuse our CPU detection
code.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2018-01-17 17:07:03 +01:00
Jiri Denemark
30b381cfdd cpu: Add SandyBridge-IBRS CPU model
This is a variant of SandyBridge with indirect branch prediction
protection. The only difference between SandyBridge and SandyBridge-IBRS
is the added "spec-ctrl" feature.

The SandyBridge-IBRS model in QEMU is a bit different since SandyBridge
got several additional features since we added it in cpu_map.xml:
    arat, vme, xsaveopt

Adding them only to the -IBRS variant would confuse our CPU detection
code.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2018-01-17 17:07:03 +01:00
Jiri Denemark
2e3b220a87 cpu: Add Westmere-IBRS CPU model
This is a variant of Westmere with indirect branch prediction
protection. The only difference between Westmere and Westmere-IBRS is
the added "spec-ctrl" feature.

The Westmere-IBRS model in QEMU is a bit different since Westmere got
several additional features since we added it in cpu_map.xml:
    arat, pclmuldq, vme

Adding them only to the -IBRS variant would confuse our CPU detection
code.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2018-01-17 17:07:03 +01:00
Jiri Denemark
6b7e7d1cc2 cpu: Add Nehalem-IBRS CPU model
This is a variant of Nehalem with indirect branch prediction protection.
The only difference between Nehalem and Nehalem-IBRS is the added
"spec-ctrl" feature.

Thus the diff matches QEMU, but the new CPU model itself is different.
The QEMU's versions of both models contain "vme" feature, while this
feature is missing in libvirt's models. While we can't change the
existing Nehalem CPU model, we could add "vme" to Nehalem-IBRS to make
it similar to QEMU, but doing so would fool our CPU detecting code so
that any Nehalem CPU with "vme" feature would be detected as
Nehalem-IBRS CPU without spec-ctrl. Not adding "vme" to Nehalem-IBRS is
safe as QEMU will just provide the feature anyway, which matches what
happens with Nehalem (and new enough machine types).

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2018-01-17 17:07:02 +01:00
Paolo Bonzini
8b605530e8 cpu: add CPU features for indirect branch prediction protection
Added in QEMU commits TBD and TBD.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2018-01-17 17:07:02 +01:00
Jiri Denemark
b427cf4831 cpu_x86: Copy CPU signature from ancestor
When specifying a new CPU model in cpu_map.xml as an extension to an
existing model, we forgot to copy the signature (family + model) from
the original CPU model.

We don't use this way of specifying CPU models, but it's still supported
and it becomes useful when someone wants to quickly hack up a CPU model
for testing or when creating additional variants of existing models to
help with fixing some spectral issues.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2018-01-10 11:07:23 +01:00
Jiri Denemark
ad80ccd3f9 cpu_x86: Add debug messages to x86DecodeUseCandidate
When translating CPUID data into CPU model + features, the code
sometimes uses an unexpected CPU model. There may be several reasons for
this, starting with wrong expectations and ending with an actual bug in
our code. These debug messages will help determining the reason.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2018-01-10 11:07:23 +01:00
Paolo Bonzini
d2440f3b53 conf: include x86 microcode version in virsh capabilities
A microcode update can cause the CPUID bits to change; an example
from the past was the update that disabled TSX on several Haswell and
Broadwell machines.

In order to track the x86 microcode version in the QEMU capabilities,
we have to fetch it and store it in the host CPU.  This also makes the
version visible in "virsh capabilities", which is a nice side effect.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2018-01-04 16:52:03 +01:00
Jiri Denemark
bd874d9ff1 cpu_x86: Rename virCPUx86MapInitialize
The function will be used to initialize internal data of the x86 CPU
driver (including the CPU map).

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2018-01-04 16:52:03 +01:00
Andrea Bolognani
3e7db8d3e8 Remove backslash alignment attempts
Right-aligning backslashes when defining macros or using complex
commands in Makefiles looks cute, but as soon as any changes is
required to the code you end up with either distractingly broken
alignment or unnecessarily big diffs where most of the changes
are just pushing all backslashes a few characters to one side.

Generated using

  $ git grep -El '[[:blank:]][[:blank:]]\\$' | \
    grep -E '*\.([chx]|am|mk)$$' | \
    while read f; do \
      sed -Ei 's/[[:blank:]]*[[:blank:]]\\$/ \\/g' "$f"; \
    done

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
2017-11-03 13:24:12 +01:00
Jiri Denemark
3b2674ff63 cpu_map: Add cqm alternative name for cmt
Linux kernel shows our "cmt" feature as "cqm". Let's mention the name in
the cpu_map.xml to make it easier to find.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-11-02 21:44:29 +01:00
Jiri Denemark
c1a63a5f7b qemu: Parse CPU stepping from query-cpu-model-expansion
Even though only family and model are used for matching CPUID data with
CPU models from cpu_map.xml, stepping is used by x86DataFilterTSX which
is supposed to disable TSX on CPU models with broken TSX support. Thus
we need to start parsing stepping from QEMU to make sure we don't
disable TSX on CPUs which provide working TSX implementation. See the
following patch for a real world example of such CPU.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-10-17 22:37:04 +02:00
Jiri Denemark
9c9620af1d cpu_x86: Disable blockers from unusable CPU models
When decoding CPUID data to virCPUDef we need to be careful about using
a CPU model which cannot be directly used on the current host. Normally,
libvirt would notice the features which prevent the model from being
usable and it would disable them in the computed virCPUDef, but this
won't work in case the definition of the CPU model in QEMU contains more
features than what we have in cpu_map.xml. We need to count with the
usability blockers we got from QEMU and explicitly disable all of them
to make the computed virCPUDef usable.

https://bugzilla.redhat.com/show_bug.cgi?id=1464832

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-10-16 09:23:20 +02:00
Jiri Denemark
722ef4ff38 cpu_x86: Move x86FeatureFind* to avoid forward prototypes
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-10-16 09:23:20 +02:00
Jiri Denemark
20664ec779 conf: Introduce virDomainCapsCPUModelsGet
This internal API can be used to find a specific CPU model in
virDomainCapsCPUModels list.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-10-16 09:23:17 +02:00
Jiri Denemark
a62dca833e cpu: Drop unused parameter from cpuDecode
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: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-10-16 09:21:52 +02:00
Jiri Denemark
fd885a06a0 cpu: Use virDomainCapsCPUModelsPtr in cpu driver APIs
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: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-10-16 09:21:52 +02:00
Nitesh Konkar
7388d055d4 cpu_ppc64: Error out when model tag missing in virsh cpu-compare xml
libvirtd throws unhandled signal 11 on ppc while running
virsh cpu-compare with missing model tag in the xml. This
patch errors out in such situation.

Signed-off-by: Nitesh Konkar <nitkon12@linux.vnet.ibm.com>
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-10-12 16:37:54 +02:00
Jiri Denemark
848b72421f cpu: Add new Skylake-Server CPU model
Available since QEMU 2.10.0 (specifically commit
v2.9.0-2233-g53f9a6f45f).

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2017-09-18 15:10:46 +02:00
Jiri Denemark
78d177df67 cpu: Add clwb/pcommit CPU features
The features were added to QEMU by commit v2.4.0-1690-gf7fda28094 as
Skylake Server features.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2017-09-18 15:10:46 +02:00
Jiri Denemark
ea9741f600 cpu_x86: Implement virCPUValidateFeatures
The function checks whether all CPU features used in a CPU definition
are specified in cpu_map.xml.

https://bugzilla.redhat.com/show_bug.cgi?id=1460086

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-09-18 10:40:12 +02:00
Jiri Denemark
20edbad776 cpu_s390: Implement virCPUValidateFeatures
Only feature policy is checked on s390, which was previously done in
virCPUUpdate, but that's not the correct place for the check once we
have virCPUValidateFeatures.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-09-18 10:40:12 +02:00
Jiri Denemark
6ef9c202f2 cpu: Introduce virCPUValidateFeatures
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: Jiri Denemark <jdenemar@redhat.com>
2017-09-18 10:40:12 +02:00
Jiri Denemark
abec725ab1 cpu: Drop cpuBaselineXML
The implementation of virConnectBaselineCPU may be different for each
hypervisor. Thus it shouldn't really be implmented in the cpu code.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-09-18 10:40:12 +02:00
Jiri Denemark
7816de498b cpu: Don't log CPU models in cpuBaselineXML
They are logged in cpuBaseline anyway.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-09-18 10:40:12 +02:00
Jiri Denemark
50234e4eaf cpu: Use virCPUDefListParse in cpuBaselineXML
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-09-18 10:40:12 +02:00
Brijesh Singh
a0b628432a cpu: Add new EPYC CPU model
Add a new CPU model called 'EPYC' to model processors from AMD EPYC
family (which includes EPYC 76xx,75xx,74xx, 73xx and 72xx).

The following features bits have been added/removed compare to Opteron_G5

Added: monitor, movbe, rdrand, mmxext, ffxsr, rdtscp, cr8legacy, osvw,
       fsgsbase, bmi1, avx2, smep, bmi2, rdseed, adx, smap, clfshopt, sha
       xsaveopt, xsavec, xgetbv1, arat

Removed: xop, fma4, tbm

The patch is depend on EPYC CPU model supported introduced in qemu [1]

[1] https://patchwork.kernel.org/patch/9902205/

Cc: Tom Lendacky <Thomas.Lendacky@amd.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2017-09-07 13:53:32 +02:00
Marek Marczykowski-Górecki
1be213e295 cpu: define sub-leaf 0 for leaf 7 in cpu_map.xml
CPUID leaf 7 is sub-leaf aware. Add missing attribute.

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-08-04 16:45:11 +02:00
Jiri Denemark
83e081b8ab cpu_x86: Properly disable unknown CPU features
CPU features unknown to a hypervisor will not be present in dataDisabled
even though the features won't naturally be enabled because.
Thus any features we asked for which are not in dataEnabled should be
considered disabled.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-07-13 09:53:15 +02:00
Jiri Denemark
5c8c2d1633 cpu_ppc64: Add support for host-model on POWER9
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2017-06-13 10:35:53 +02:00