It is no longer needed since dropping cpudef config file support.
Cleaning this up removes knowledge about other models from x86_def_t,
in preparation for reusing x86_def_t as intermediate step towards pure
QOM X86CPU subclasses.
Signed-off-by: Andreas Färber <afaerber@suse.de>
Catch NULL name argument early to avoid repeated checks.
Similarly, check for -cpu host early and untangle from iterating through
model definitions. This prepares for introducing X86CPU subclasses.
Signed-off-by: Andreas Färber <afaerber@suse.de>
This keeps compatibility on machine-types pc-1.2 and older, and prints a
warning in case the requested configuration won't get the correct
topology.
I couldn't think of a better way to warn about broken topology when in
compat mode other than using error_report(). The warning message will
probably be buried in a log file somewhere, but it's better than
nothing.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
This function will be used by both the CPU initialization code and the
fw_cfg table initialization code.
Later this function will be updated to generate APIC IDs according to
the CPU topology.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Currently, the pc-1.4 machine init function enables PV EOI and then
calls the pc-1.2 machine init function. The problem with this approach
is that now we can't enable any additional compatibility code inside the
pc-1.2 init function because it would end up enabling the compatibility
behavior on pc-1.3 and pc-1.4 as well.
This reverses the logic so that the pc-1.2 machine init function will
disable PV EOI, and then call the pc-1.4 machine init function.
This way we can change older machine-types to enable compatibility
behavior, and the newer machine-types (pc-1.3, pc-q35-1.4 and
pc-i440fx-1.4) would just use the default behavior.
(This means that one nice side-effect of this change is that pc-q35-1.4
will get PV EOI enabled by default, too)
It would be interesting to eventually change pc_init_pci_no_kvmclock()
and pc_init_isa() to reuse pc_init_pci_1_2() as well (so we don't need
to duplicate compatibility code on those two functions). But this will
be probably much easier to do after we create a PCInitArgs struct for
the PC initialization arguments, and/or after we use global-properties
to implement the compatibility modes present in pc_init_pci_1_2().
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
This is a cleanup that tries to solve two small issues:
- We don't need a separate kvm_pv_eoi_features variable just to keep a
constant calculated at compile-time, and this style would require
adding a separate variable (that's declared twice because of the
CONFIG_KVM ifdef) for each feature that's going to be
enabled/disabled by machine-type compat code.
- The pc-1.3 code is setting the kvm_pv_eoi flag on cpuid_kvm_features
even when KVM is disabled at runtime. This small inconsistency in
the cpuid_kvm_features field isn't a problem today because
cpuid_kvm_features is ignored by the TCG code, but it may cause
unexpected problems later when refactoring the CPUID handling code.
This patch eliminates the kvm_pv_eoi_features variable and simply uses
kvm_enabled() inside the enable_kvm_pv_eoi() compat function, so it
enables kvm_pv_eoi only if KVM is enabled. I believe this makes the
behavior of enable_kvm_pv_eoi() clearer and easier to understand.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Acked-by: Gleb Natapov <gleb@redhat.com>
Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Replace by SYS_BUS_DEVICE() QOM cast macro using a scripted conversion.
Avoids the old macro creeping into new code.
Resolve a Coding Style warning in openpic code.
Signed-off-by: Andreas Färber <afaerber@suse.de>
Cc: Anthony Liguori <anthony@codemonkey.ws>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
kvm_check_features_against_host() should be called when features can't
be changed, and when features are converted to properties it would be
possible to change them until realize time, so correct way is to call
kvm_check_features_against_host() in x86_cpu_realize().
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Freeing resources in one place would require setting 'error'
to not NULL, so add some more error reporting before jumping to
exit branch.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
No functional change, needed for simplifying conversion to properties.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
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: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Feature names were taken from the X86_FEATURE_* constants in the Linux
kernel code.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Andreas 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: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Andreas 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: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Andreas 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: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Andreas 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: Andreas 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: Andreas 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: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Andreas 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: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Andreas 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: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Andreas 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: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Andreas 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: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Andreas 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: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Andreas 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: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Andreas 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: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Andreas 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: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
* 'qom-cpu' of git://repo.or.cz/qemu/afaerber:
MAINTAINERS: Include X86CPU in CPU maintenance area
cpu: Move kvm_run into CPUState
cpu: Move kvm_state field into CPUState
ppc_booke: Pass PowerPCCPU to ppc_booke_timers_init()
ppc4xx_devs: Return PowerPCCPU from ppc4xx_init()
ppc_booke: Pass PowerPCCPU to {decr,fit,wdt} timer callbacks
ppc: Pass PowerPCCPU to [h]decr timer callbacks
ppc: Pass PowerPCCPU to [h]decr callbacks
ppc: Pass PowerPCCPU to ppc_set_irq()
kvm: Pass CPUState to kvm_vcpu_ioctl()
kvm: Pass CPUState to kvm_arch_*
cpu: Move kvm_fd into CPUState
qdev-properties.c: Separate core from the code used only by qemu-system-*
qdev: Coding style fixes
cpu: Introduce CPUListState struct
target-alpha: Add support for -cpu ?
target-alpha: Turn CPU definitions into subclasses
target-alpha: Avoid leaking the alarm timer over reset
alpha: Pass AlphaCPU array to Typhoon
target-alpha: Let cpu_alpha_init() return AlphaCPU
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 b3baa152aa. 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: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
The file is only including error.h and qerror.h. Prefer explicit
inclusion of whatever files are needed.
Signed-off-by: Paolo 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: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Andreas 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: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Andreas 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: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
SSSE3 support has been added to TCG more than 4 years ago in commit
4242b1bd8a. It has been disabled by
mistake in commit 551a2dec8f.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Signed-off-by: Andreas 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: Martin Kletzander <mkletzan@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Andreas 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: Andre Przywara <osp@andrep.de>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
[ehabkost: edited commit message]
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Andreas 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: Andre Przywara <osp@andrep.de>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
[ehabkost: added CPUID_EXT_PCID]
[ehabkost: edited commit message]
[ehabkost: rebased against latest qemu.git master]
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Andreas 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: Andreas Färber <afaerber@suse.de>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
* qemu-kvm/uq/master: (28 commits)
update-linux-headers.sh: Handle new kernel uapi/ directories
target-i386: kvm_cpu_fill_host: use GET_SUPPORTED_CPUID
target-i386: cpu: make -cpu host/check/enforce code KVM-specific
target-i386: make cpu_x86_fill_host() void
Emulate qemu-kvms -no-kvm option
Issue warning when deprecated -tdf option is used
Issue warning when deprecated drive parameter boot=on|off is used
Use global properties to emulate -no-kvm-pit-reinjection
Issue warning when deprecated -no-kvm-pit is used
Use machine options to emulate -no-kvm-irqchip
cirrus_vga: allow configurable vram size
target-i386: Add missing kvm cpuid feature name
i386: cpu: add missing CPUID[EAX=7,ECX=0] flag names
i386: kvm: filter CPUID leaf 7 based on GET_SUPPORTED_CPUID, too
i386: kvm: reformat filter_features_for_kvm() code
i386: kvm: filter CPUID feature words earlier, on cpu.c
i386: kvm: mask cpuid_ext4_features bits earlier
i386: kvm: mask cpuid_kvm_features earlier
i386: kvm: x2apic is not supported without in-kernel irqchip
i386: kvm: set CPUID_EXT_TSC_DEADLINE_TIMER on kvm_arch_get_supported_cpuid()
...
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
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: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Marcelo 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: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
The return value of that function is always 0, and is always ignored.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
