This adds the following feature words to the list of flags to be checked
by kvm_check_features_against_host():

 - cpuid_7_0_ebx_features
 - ext4_features
 - kvm_features
 - svm_features

This will ensure the "enforce" flag works as it should: it won't allow
QEMU to be started unless every flag that was requested by the user or
defined in the CPU model is supported by the host.

This patch may cause existing configurations where "enforce" wasn't
preventing QEMU from being started to abort QEMU. But that's exactly the
point of this patch: if a flag was not supported by the host and QEMU
wasn't aborting, it was a bug in the "enforce" code.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NGleb Natapov <gleb@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Feature names were taken from the X86_FEATURE_* constants in the Linux
kernel code.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NGleb Natapov <gleb@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Instead of carrying the CPUID leaf/register and feature name array on
the model_features_t struct, move that information into
feature_word_info so it can be reused by other functions.

The goal is to eventually kill model_features_t entirely, but to do that
we have to either convert x86_def_t.features to an array or use
offsetof() inside FeatureWordInfo (to replace the pointers inside
model_features_t). So by now just move most of the model_features_t
fields to FeatureWordInfo except for the two pointers to local
arguments.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NGleb Natapov <gleb@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

This introduces a FeatureWord enum, FeatureWordInfo struct (with
generation information about a feature word), and a FeatureWordArray
typedef, and changes add_flagname_to_bitmaps() code and
cpu_x86_parse_featurestr() to use the new typedefs instead of separate
variables for each feature word.

This will help us keep the code at kvm_check_features_against_host(),
cpu_x86_parse_featurestr() and add_flagname_to_bitmaps() sane while
adding new feature name arrays.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NGleb Natapov <gleb@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

KVM_CAP_PV_MMU capability reporting was removed from the kernel since
v2.6.33 (see commit a68a6a7282373), and was completely removed from the
kernel since v3.3 (see commit fb92045843). It doesn't make sense to keep
it enabled by default, as it would cause unnecessary hassle when using
the "enforce" flag.

This disables kvm_mmu on all machine-types. With this fix, the possible
scenarios when migrating from QEMU <= 1.3 to QEMU 1.4 are:

------------+----------+----------------------------------------------------
 src kernel | dst kern.| Result
------------+----------+----------------------------------------------------
 >= 2.6.33  | any      | kvm_mmu was already disabled and will stay disabled
 <= 2.6.32  | >= 3.3   | correct live migration is impossible
 <= 2.6.32  | <= 3.2   | kvm_mmu will be disabled on next guest reboot *
------------+----------+----------------------------------------------------

 * If they are running kernel <= 2.6.32 and want kvm_mmu to be kept
   enabled on guest reboot, they can explicitly add +kvm_mmu to the QEMU
   command-line. Using 2.6.33 and higher, it is not possible to enable
   kvm_mmu explicitly anymore.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NGleb Natapov <gleb@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Note that target-alpha accesses this field from TCG, now using a
negative offset. Therefore the field is placed last in CPUState.

Pass PowerPCCPU to [kvm]ppc_fixup_cpu() to facilitate this change.

Move common parts of mips cpu_state_reset() to mips_cpu_reset().

Acked-by: Richard Henderson <rth@twiddle.net> (for alpha)
[AF: Rebased onto ppc CPU subclasses and openpic changes]
Signed-off-by: NAndreas Färber <afaerber@suse.de>

To facilitate the field movements, pass MIPSCPU to malta_mips_config();
avoid that for mips_cpu_map_tc() since callers only access MIPS Thread
Contexts, inside TCG helpers.
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Since cpudef config is not supported anymore and all remaining sources
now always set x86_def_t.vendor[123] fields, remove setting default
vendor to simplify future re-factoring.
Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

When CPU properties are implemented, ext2_features may change
between object_new(CPU) and cpu_realize_fn(). Sanitizing
ext2_features for AMD based CPU at realize() time will keep
current behavior after CPU features are converted to properties.
Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Now that all entries have check_feat=~0 in
kvm_check_features_against_host(), we can eliminate check_feat entirely
and make the code check all bits.

This patch shouldn't introduce any behavior change, as check_feat is set
to ~0 on all entries.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NGleb Natapov <gleb@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

When nested SVM is supported, the kernel returns the SVM flag on
GET_SUPPORTED_CPUID[1], so we can check the SVM flag safely in
kvm_check_features_against_host().

I don't know why the original code ignored the SVM flag. Maybe it was
because kvm_cpu_fill_host() used the CPUID instruction directly instead
of GET_SUPPORTED_CPUID

[1] Older kernels (before v2.6.37) returned the SVM flag even if nested
    SVM was _not_ supported. So the only cases where this patch should
    change behavior is when SVM is being requested by the user or the
    CPU model, but not supported by the host. And on these cases we
    really want QEMU to abort if the "enforce" option is set.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NGleb Natapov <gleb@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

I have no idea why PPRO_FEATURES was being ignored on the check of the
CPUID.80000001H.EDX bits. I believe it was a mistake, and it was
supposed to be ~(PPRO_FEATURES & CPUID_EXT2_AMD_ALIASES) or just
~CPUID_EXT2_AMD_ALIASES, because some time ago kvm_cpu_fill_host() used
the CPUID instruction directly (instead of
kvm_arch_get_supported_cpuid()).

But now kvm_cpu_fill_host() uses kvm_arch_get_supported_cpuid(), and
kvm_arch_get_supported_cpuid() returns all supported bits for
CPUID.80000001H.EDX, even the AMD aliases (that are explicitly copied
from CPUID.01H.EDX), so we can make the code check/enforce all the
CPUID.80000001H.EDX bits.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NGleb Natapov <gleb@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

We don't need any hack to ignore CPUID_EXT_HYPERVISOR anymore, because
kvm_arch_get_supported_cpuid() now sets CPUID_EXT_HYPERVISOR properly.
So, this shouldn't introduce any behavior change, but it makes the code
simpler.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NGleb Natapov <gleb@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

The -cpu check/enforce warnings are printing incorrect information about the
missing flags. There are no feature flags on CPUID leaves 0 and 0x80000000, but
there were references to 0 and 0x80000000 in the table at
kvm_check_features_against_host().

This changes the model_features_t struct to contain the register number as
well, so the error messages print the correct CPUID leaf+register information,
instead of wrong CPUID leaf numbers.

This also changes the format of the error messages, so they follow the
"CPUID.<leaf>.<register>.<name> [bit <offset>]" convention used in Intel
documentation. Example output:

    $ qemu-system-x86_64 -machine pc-1.0,accel=kvm -cpu Opteron_G4,+ia64,enforce
    warning: host doesn't support requested feature: CPUID.01H:EDX.ia64 [bit 30]
    warning: host doesn't support requested feature: CPUID.01H:ECX.xsave [bit 26]
    warning: host doesn't support requested feature: CPUID.01H:ECX.avx [bit 28]
    warning: host doesn't support requested feature: CPUID.80000001H:ECX.abm [bit 5]
    warning: host doesn't support requested feature: CPUID.80000001H:ECX.sse4a [bit 6]
    warning: host doesn't support requested feature: CPUID.80000001H:ECX.misalignsse [bit 7]
    warning: host doesn't support requested feature: CPUID.80000001H:ECX.3dnowprefetch [bit 8]
    warning: host doesn't support requested feature: CPUID.80000001H:ECX.xop [bit 11]
    warning: host doesn't support requested feature: CPUID.80000001H:ECX.fma4 [bit 16]
    Unable to find x86 CPU definition
    $
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NGleb Natapov <gleb@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

When using -cpu host, we don't need to use the kvm_default_features
variable, as the user is explicitly asking QEMU to enable all feature
supported by the host.

This changes the kvm_cpu_fill_host() code to use GET_SUPPORTED_CPUID to
initialize the kvm_features field, so we get all host KVM features
enabled.

This will also allow us to properly check/enforce KVM features inside
kvm_check_features_against_host() later. For example, we will be able to
make this:

  $ qemu-system-x86_64 -cpu ...,+kvm_pv_eoi,enforce

refuse to start if kvm_pv_eoi is not supported by the host (after we fix
kvm_check_features_against_host() to check KVM flags as well).
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NGleb Natapov <gleb@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

The existing -cpu host code simply sets every bit inside svm_features
(initializing it to -1), and that makes it impossible to make the
enforce/check options work properly when the user asks for SVM features
explicitly in the command-line.

So, instead of initializing svm_features to -1, use GET_SUPPORTED_CPUID
to fill only the bits that are supported by the host (just like we do
for all other CPUID feature words inside kvm_cpu_fill_host()).

This will keep the existing behavior (as filter_features_for_kvm()
already uses GET_SUPPORTED_CPUID to filter svm_features), but will allow
us to properly check for KVM features inside
kvm_check_features_against_host() later.

For example, we will be able to make this:

  $ qemu-system-x86_64 -cpu ...,+pfthreshold,enforce

refuse to start if the SVM "pfthreshold" feature is not supported by the
host (after we fix kvm_check_features_against_host() to check SVM flags
as well).
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NGleb Natapov <gleb@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

This fixes a subtle bug. A bug that probably won't cause trouble for any
existing OS, but a bug anyway:

Intel SDM Volume 2, CPUID Instruction states:

> Two types of information are returned: basic and extended function
> information. If a value entered for CPUID.EAX is higher than the maximum
> input value for basic or extended function for that processor then the
> data for the highest basic information leaf is returned. For example,
> using the Intel Core i7 processor, the following is true:
>
>   CPUID.EAX = 05H (* Returns MONITOR/MWAIT leaf. *)
>   CPUID.EAX = 0AH (* Returns Architectural Performance Monitoring leaf. *)
>   CPUID.EAX = 0BH (* Returns Extended Topology Enumeration leaf. *)
>   CPUID.EAX = 0CH (* INVALID: Returns the same information as CPUID.EAX = 0BH. *)
>   CPUID.EAX = 80000008H (* Returns linear/physical address size data. *)
>   CPUID.EAX = 8000000AH (* INVALID: Returns same information as CPUID.EAX = 0BH. *)

AMD's CPUID Specification, on the other hand, is less specific:

> The CPUID instruction supports two sets or ranges of functions,
> standard and extended.
>
> • The smallest function number of the standard function range is
>   Fn0000_0000. The largest function num- ber of the standard function
>   range, for a particular implementation, is returned in CPUID
>   Fn0000_0000_EAX.
>
> • The smallest function number of the extended function range is
>   Fn8000_0000. The largest function num- ber of the extended function
>   range, for a particular implementation, is returned in CPUID
>   Fn8000_0000_EAX.
>
> Functions that are neither standard nor extended are undefined and
> should not be relied upon.

QEMU's behavior matched Intel's specification before, but this was
changed by commit b3baa152. This patch
restores the behavior documented by Intel when cpuid_xlevel2 is 0.

The existing behavior when cpuid_xlevel2 is set (falling back to
level=cpuid_xlevel) is being kept, as I couldn't find any public
documentation on the CPUID 0xC0000000 function range on Centaur CPUs.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Adapt some functions to take CPUState / {PowerPC,S390}CPU argument.
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

The file is only including error.h and qerror.h.  Prefer explicit
inclusion of whatever files are needed.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Delay capping cpuid_level to 7 to realize time so property setters
for cpuid_7_0_ebx_features and "level" could be used in any order/time
between x86_cpu_initfn() and x86_cpu_realize().
Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Instead of parsing the whole cpu_model string inside
cpu_x86_find_by_name(), first split it into the CPU model name and the
full feature string, then parse the feature string into pieces.

When using CPU model classes, those two pieces of information will be
used at different moments (CPU model name will be used to find CPU
class, feature string will be used after CPU object was created), so
making the split in two steps will make it easier to refactor the code
later.

This should also help on the CPU properties work, that will just need to
replace the cpu_x86_parse_featurestr() logic (and can keep the CPU model
lookup code as-is).
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

- Use spaces instead of tabs on cpu_x86_cpuid().
- Use braces on 'if' statement cpu_x86_find_by_name().
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

When adding the Haswell CPU model, I intended to make it a superset of the
features present on the SandyBridge model, but I have removed the SEP and
RDTSCP features from the feature list by mistake. This patch adds the missing
SEP and RDTSCP features (that are present on SandyBridge) to Haswell.
Reported-by: NMartin Kletzander <mkletzan@redhat.com>
Acked-by: NAndreas Färber <afaerber@suse.de>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

SSSE3 support has been added to TCG more than 4 years ago in commit
4242b1bd. It has been disabled by
mistake in commit 551a2dec.
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

When adding the Haswell CPU model, I intended to make it a superset of the
features present on the SandyBridge model, but I have removed the SEP and
RDTSCP features from the feature list by mistake. This patch adds the
missing SEP and RDTSCP features (that are present on SandyBridge) to
Haswell.
Reported-by: NMartin Kletzander <mkletzan@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Features added to the model, in relation to SandyBridge:

fma       CPUID[1].ECX[12]
pcid      CPUID[1].ECX[17]
movbe     CPUID[1].ECX[22]
fsgsbase  CPUID[EAX=7,ECX=0].EBX[0]
bmi1      CPUID[EAX=7,ECX=0].EBX[3]
hle       CPUID[EAX=7,ECX=0].EBX[4]
avx2      CPUID[EAX=7,ECX=0].EBX[5]
smep      CPUID[EAX=7,ECX=0].EBX[7]
bmi2      CPUID[EAX=7,ECX=0].EBX[8]
erms      CPUID[EAX=7,ECX=0].EBX[9]
invpcid   CPUID[EAX=7,ECX=0].EBX[10]
rtm       CPUID[EAX=7,ECX=0].EBX[11]
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Add a new base CPU model called Opteron_G5 to model the latest
Opteron CPUs. This increases the model value and model numbers and
adds TBM, F16C and FMA over the latest G4 model.
Signed-off-by: NAndre Przywara <osp@andrep.de>
Signed-off-by: NBoris Ostrovsky <boris.ostrovsky@amd.com>
[ehabkost: edited commit message]
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Update QEMU's knowledge of CPUID bit names. This allows to
enable/disable those new features on QEMU's command line when
using KVM and prepares future feature enablement in QEMU.

This adds F16C, RDRAND, LWP, TBM, TopoExt, PerfCtr_Core, PerfCtr_NB,
FSGSBASE, BMI1, AVX2, BMI2, ERMS, PCID, InvPCID, RTM, RDSeed and ADX.

Sources where the AMD BKDG for Family 15h/Model 10h, Intel Software
Developer Manual, and the Linux kernel for the leaf 7 bits.
Signed-off-by: NAndre Przywara <osp@andrep.de>
Signed-off-by: NBoris Ostrovsky <boris.ostrovsky@amd.com>
[ehabkost: added CPUID_EXT_PCID]
[ehabkost: edited commit message]
[ehabkost: rebased against latest qemu.git master]
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

This fixes the following:
  target-i386/cpu.o: In function `kvm_cpu_fill_host':
  target-i386/cpu.c:783: undefined reference to `kvm_state'

I didn't notice the problem before because GCC was optimizing the entire
kvm_cpu_fill_host() function out (because all calls are conditional on
kvm_enabled()).

* cpu_x86_fill_model_id() is used only if CONFIG_KVM is set, so #ifdef it
  entirely to avoid compiler warnings.

* kvm_cpu_fill_host() should be called only if KVM is enabled, so
  use #ifdef CONFIG_KVM around the entire function body.
Reported-by: NAndreas Färber <afaerber@suse.de>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Change the kvm_cpu_fill_host() function to use
kvm_arch_get_supported_cpuid() instead of running the CPUID instruction
directly, when checking for supported CPUID features.

This should solve two problems at the same time:

 * "-cpu host" was not enabling features that don't need support on
   the host CPU (e.g. x2apic);
 * "check" and "enforce" options were not detecting problems when the
   host CPU did support a feature, but the KVM kernel code didn't
   support it.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

Rationale:
 * "-cpu host" is available only when using KVM
 * The current implementation of -cpu check/enforce
   (check_features_against_host()) makes sense only when using KVM.

So this makes the functions check_features_against_host() and
cpu_x86_fill_host() KVM-specific, document them as such, and rename them
to kvm_check_features_against_host() and kvm_cpu_fill_host().
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

The return value of that function is always 0, and is always ignored.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

Currently "-cpu host,-kvmclock,-kvm_nopiodelay,-kvm_mmu" does not
turn off all bits in CPUID 0x40000001 EAX.

The missing ones is KVM_FEATURE_STEAL_TIME.

This adds the name kvm_steal_time.
Signed-off-by: NDon Slutz <Don@CloudSwitch.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

This makes QEMU recognize the following CPU flag names:

 Flags            | Corresponding KVM kernel commit
 -----------------+----------------------------------------
 FSGSBASE         | 176f61da82435eae09cc96f70b530d1ba0746b8b
 AVX2, BMI1, BMI2 | fb215366b3c7320ac25dca766a0152df16534932
 HLE, RTM         | 83c529151ab0d4a813e3f6a3e293fff75d468519
 INVPCID          | ad756a1603c5fac207758faaac7f01c34c9d0b7b
 ERMS             | a01c8f9b4e266df1d7166d23216f2060648f862d
Reviewed-by: NDon Slutz <Don@CloudSwitch.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

Now that CPUID leaf 7 features can be enabled/disabled on the
command-line, we need to filter them properly using GET_SUPPORTED_CPUID,
at the same place where other features are filtered out.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>