hw_breakpoint_enabled() returned a bit field indicating whether a local
breakpoint and/or global breakpoint was enabled. Avoid this number magic
by using explicit boolean helper functions hw_local_breakpoint_enabled()
and hw_global_breakpoint_enabled(), to aid readability.
Reuse them for the hw_breakpoint_enabled() implementation and change
its return type to bool.
While at it, fix Coding Style issues (missing braces).
Signed-off-by: liguang <lig.fnst@cn.fujitsu.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Implicit use of dr7 bit field is a little hard to understand,
so define constants for them and use them consistently.
Signed-off-by: liguang <lig.fnst@cn.fujitsu.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
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>
((pde & 0x1fe000) << 19) is the bits 39:32 of the final physical address, and
we shouldn't use unit32_t to calculate it. Convert the type to hwaddr to fix
this problem.
Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
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>
Various header files rely on qemu-char.h including qemu-config.h or
main-loop.h, but they really do not need qemu-char.h at all (particularly
interesting is the case of the block layer!). Clean this up, and also
add missing inclusions of qemu-char.h itself.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Refactor common code around calls to cpu_restore_state().
tb_find_pc() has now no external users, make it static.
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
CPUID.7.0.EBX[1]=1 indicates IA32_TSC_ADJUST MSR 0x3b is supported
Basic design is to emulate the MSR by allowing reads and writes to the
hypervisor vcpu specific locations to store the value of the emulated MSRs.
In this way the IA32_TSC_ADJUST value will be included in all reads to
the TSC MSR whether through rdmsr or rdtsc.
As this is a new MSR that the guest may access and modify its value needs
to be migrated along with the other MRSs. The changes here are specifically
for recognizing when IA32_TSC_ADJUST is enabled in CPUID and code added
for migrating its value.
Signed-off-by: Will Auld <will.auld@intel.com>
Reviewed-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
* afaerber/qom-cpu:
target-i386: Postpone cpuid_level update to realize time
target-i386: Use define for cpuid vendor string size
target-i386: Separate feature string parsing from CPU model lookup
target-i386/cpu.c: Coding style fixes
qdev: qdev_create(): use error_report() instead of hw_error()
sysemu.h: Include qemu-types.h instead of qemu-common.h
Create qemu-types.h for struct typedefs
qlist.h: Do not include qemu-common.h
qga/channel-posix.c: Include headers it needs
qapi/qmp-registry.c: Include headers it needs
ui/vnc-palette.c: Include headers it needs
user: Rename qemu-types.h to qemu-user-types.h
user: Move *-user/qemu-types.h to main directory
Signed-off-by: Anthony Liguori <aliguori@us.ibm.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>
* afaerber/qom-cpu:
target-i386: Add Haswell CPU model
target-i386/cpu: Add new Opteron CPU model
target-i386/cpu: Name new CPUID bits
qapi-types.h: Don't include qemu-common.h
osdep: Move qemu_{open,close}() prototypes
qemu-config.h: Include headers it needs
vnc-palette.h: Include <stdbool.h>
qemu-fsdev-dummy.c: Include module.h
qdev: Split up header so it can be used in cpu.h
Move qemu_irq typedef out of qemu-common.h
qemu-common.h: Comment about usage rules
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
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>
Pass around CPUArchState instead of using global cpu_single_env.
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Reviewed-by: Andreas Färber <afaerber@suse.de>
Pass around CPUArchState instead of using global cpu_single_env.
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Reviewed-by: Andreas Färber <afaerber@suse.de>
Pass around CPUArchState instead of using global cpu_single_env.
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Acked-by: Richard Henderson <rth@twiddle.net>
Acked-by: Aurelien Jarno <aurelien@aurel32.net>
Acked-by: Guan Xuetao <gxt@mprc.pku.edu.cn>
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>
For target-mips also change the return type to bool.
Make include paths for cpu-qom.h consistent for alpha and unicore32.
Signed-off-by: Andreas Färber <afaerber@suse.de>
[AF: Updated new target-openrisc function accordingly]
Acked-by: Richard Henderson <rth@twiddle.net> (for alpha)
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>
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: Don Slutz <Don@CloudSwitch.com>
Signed-off-by: Marcelo 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: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Cosmetic, but it will also help to make futher patches easier to review.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
cpu.c contains the code that will check if all requested CPU features
are available, so the filtering of KVM features must be there, so we can
implement "check" and "enforce" properly.
The only point where kvm_arch_init_vcpu() is called on i386 is:
- cpu_x86_init()
- x86_cpu_realize() (after cpu_x86_register() is called)
- qemu_init_vcpu()
- qemu_kvm_start_vcpu()
- qemu_kvm_thread_fn() (on a new thread)
- kvm_init_vcpu()
- kvm_arch_init_vcpu()
With this patch, the filtering will be done earlier, at:
- cpu_x86_init()
- cpu_x86_register() (before x86_cpu_realize() is called)
Also, the KVM CPUID filtering will now be done at the same place where
the TCG CPUID feature filtering is done. Later, the code can be changed
to use the same filtering code for the "check" and "enforce" modes, as
now the cpu.c code knows exactly which CPU features are going to be
exposed to the guest (and much earlier).
One thing I was worrying about when doing this is that
kvm_arch_get_supported_cpuid() depends on kvm_irqchip_in_kernel(), and
maybe the 'kvm_kernel_irqchip' global variable wasn't initialized yet at
CPU creation time. But kvm_kernel_irqchip is initialized during
kvm_init(), that is called very early (much earlier than the machine
init function), and kvm_init() is already a requirement to run the
GET_SUPPORTED_CPUID ioctl() (as kvm_init() initializes the kvm_state
global variable).
Side note: it would be nice to keep KVM-specific code inside kvm.c. The
problem is that properly implementing -cpu check/enforce code (that's
inside cpu.c) depends directly on the feature bit filtering done using
kvm_arch_get_supported_cpuid(). Currently -cpu check/enforce is broken
because it simply uses the host CPU feature bits instead of
GET_SUPPORTED_CPUID, and we need to fix that.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
This way all the filtering by GET_SUPPORTED_CPUID is being done at the
same place in the code.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Instead of masking the KVM feature bits very late (while building the
KVM_SET_CPUID2 data), mask it out on env->cpuid_kvm_features, at the
same point where the other feature words are masked out.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
This is necessary so that x2apic is not improperly enabled when the
in-kernel irqchip is disabled.
This won't generate a warning with "-cpu ...,check" because the current
check/enforce code is broken (it checks the host CPU data directly,
instead of using kvm_arch_get_supported_cpuid()), but it will be
eventually fixed to properly report the missing x2apic flag.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
This moves the CPUID_EXT_TSC_DEADLINE_TIMER CPUID flag hacking from
kvm_arch_init_vcpu() to kvm_arch_get_supported_cpuid().
Full git grep for kvm_arch_get_supported_cpuid:
kvm.h:uint32_t kvm_arch_get_supported_cpuid(KVMState *env, uint32_t function,
target-i386/cpu.c: x86_cpu_def->cpuid_7_0_ebx_features = kvm_arch_get_supported_cpuid(kvm_state, 0x7, 0, R_EBX);
target-i386/cpu.c: *eax = kvm_arch_get_supported_cpuid(s, 0xA, count, R_EAX);
target-i386/cpu.c: *ebx = kvm_arch_get_supported_cpuid(s, 0xA, count, R_EBX);
target-i386/cpu.c: *ecx = kvm_arch_get_supported_cpuid(s, 0xA, count, R_ECX);
target-i386/cpu.c: *edx = kvm_arch_get_supported_cpuid(s, 0xA, count, R_EDX);
target-i386/cpu.c: *eax = kvm_arch_get_supported_cpuid(s, 0xd, count, R_EAX);
target-i386/cpu.c: *ebx = kvm_arch_get_supported_cpuid(s, 0xd, count, R_EBX);
target-i386/cpu.c: *ecx = kvm_arch_get_supported_cpuid(s, 0xd, count, R_ECX);
target-i386/cpu.c: *edx = kvm_arch_get_supported_cpuid(s, 0xd, count, R_EDX);
target-i386/kvm.c:uint32_t kvm_arch_get_supported_cpuid(KVMState *s, uint32_t function,
target-i386/kvm.c: cpuid_1_edx = kvm_arch_get_supported_cpuid(s, 1, 0, R_EDX);
target-i386/kvm.c: env->cpuid_features &= kvm_arch_get_supported_cpuid(s, 1, 0, R_EDX);
* target-i386/kvm.c: env->cpuid_ext_features &= kvm_arch_get_supported_cpuid(s, 1, 0, R_ECX);
target-i386/kvm.c: env->cpuid_ext2_features &= kvm_arch_get_supported_cpuid(s, 0x80000001,
target-i386/kvm.c: env->cpuid_ext3_features &= kvm_arch_get_supported_cpuid(s, 0x80000001,
target-i386/kvm.c: env->cpuid_svm_features &= kvm_arch_get_supported_cpuid(s, 0x8000000A,
target-i386/kvm.c: kvm_arch_get_supported_cpuid(s, KVM_CPUID_FEATURES, 0, R_EAX);
target-i386/kvm.c: kvm_arch_get_supported_cpuid(s, 0xC0000001, 0, R_EDX);
Note that there is only one call for CPUID[1].ECX above (*), and it is
the one that gets hacked to include CPUID_EXT_TSC_DEADLINE_TIMER, so we
can simply make kvm_arch_get_supported_cpuid() set it, to let the rest
of the code know the flag can be safely set by QEMU.
One thing I was worrying about when doing this is that now
kvm_arch_get_supported_cpuid() depends on kvm_irqchip_in_kernel(). But
the 'kvm_kernel_irqchip' global variable is initialized during
kvm_init(), that is called very early, and kvm_init() is already a
requirement to run the GET_SUPPORTED_CPUID ioctl() (as kvm_init() is the
function that initializes the 'kvm_state' global variable).
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Additional fixups will be added, and making them a single 'if/else if'
chain makes it clearer than two nested switch statements.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
The reg switch will be moved to a separate function, so store the entry
pointer in a variable.
No behavior change, just code movement.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Instead of a function-specific has_kvm_features variable, simply use a
"found" variable that will be checked in case we have to use the legacy
get_para_features() interface.
No behavior change, just code cleanup.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
The for loop will become a separate function, so clean it up so it can
become independent from the bit hacking for R_EDX.
No behavior change[1], just code movement.
[1] Well, only if the kernel returned CPUID leafs 1 or 0x80000001 as
unsupported, but there's no kernel version that does that.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Change return type to bool, move to include/qemu/cpu.h and
add documentation.
Signed-off-by: Andreas Färber <afaerber@suse.de>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
[AF: Updated new caller qemu_in_vcpu_thread()]
Simplifies the call in apic_sipi() again and needed for moving halted
field to CPUState.
Signed-off-by: Andreas Färber <afaerber@suse.de>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Prepares for using a link<> property to connect APIC with CPU and for
changing the CPU APIs to CPUState.
Resolve Coding Style warnings by moving the closing parenthesis of
foreach_apic() macro to next line.
Signed-off-by: Andreas Färber <afaerber@suse.de>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
This prepares for changing the variable type from void*.
Signed-off-by: Andreas Färber <afaerber@suse.de>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
(L)APIC is a part of cpu [1] so move APIC initialization inside of
x86_cpu object. Since cpu_model and override flags currently specify
whether APIC should be created or not, APIC creation&initialization is
moved into x86_cpu_apic_init() which is called from x86_cpu_realize().
[1] - all x86 cpus have integrated APIC if we overlook existence of i486,
and it's more convenient to model after majority of them.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Enable KVM PV EOI by default. You can still disable it with
-kvm_pv_eoi cpu flag. To avoid breaking cross-version migration,
enable only for qemu 1.3 (or in the future, newer) machine type.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
I removed a line by mistake on commit
3b671a40ca, containing the flags lm/i64,
3dnow, and 3dnowext. This patch restores the removed line.
Reviewed-by: Don Slutz <Don@cloudswitch.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Rename helper flags to the new ones. This is purely a mechanical change,
it's possible to use better flags by looking at the helpers.
Reviewed-by: Richard Henderson <rth@twiddle.net>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
target_phys_addr_t is unwieldly, violates the C standard (_t suffixes are
reserved) and its purpose doesn't match the name (most target_phys_addr_t
addresses are not target specific). Replace it with a finger-friendly,
standards conformant hwaddr.
Outstanding patchsets can be fixed up with the command
git rebase -i --exec 'find -name "*.[ch]"
| xargs s/target_phys_addr_t/hwaddr/g' origin
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Move the DUMP_FPU and DUMP_CCOP flags for cpu_dump_state() from being
x86-specific flags to being generic ones. This allows us to drop some
TARGET_I386 ifdefs in various places, and means that we can (potentially)
be more consistent across architectures about which monitor commands or
debug abort printouts include FPU register contents and info about
QEMU's condition-code optimisations.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This patch implements Supervisor Mode Execution Prevention (SMEP) and
Supervisor Mode Access Prevention (SMAP) for x86. The purpose of the
patch, obviously, is to help kernel developers debug the support for
those features.
A fair bit of the code relates to the handling of CPUID features. The
CPUID code probably would get greatly simplified if all the feature
bit words were unified into a single vector object, but in the
interest of producing a minimal patch for SMEP/SMAP, and because I had
very limited time for this project, I followed the existing style.
[ v2: don't change the definition of the qemu64 CPU shorthand, since
that breaks loading old snapshots. Per Anthony Liguori this can be
fixed once the CPU feature set is snapshot.
Change the coding style slightly to conform to checkpatch.pl. ]
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
The -cpu configuration interface is based on a list of feature names or
properties, on a single namespace, so there's no need to mention on
which CPUID leaf/register each flag is located.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Don Slutz <Don@CloudSwitch.com>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Instead of having duplicate feature names on the ext2_feature array for
the AMD feature bit aliases, we keep the feature names only on the
feature_name[] array, and copy the corresponding bits to
cpuid_ext2_features in case the CPU vendor is AMD.
This will:
- Make sure we don't set the feature bit aliases on Intel CPUs;
- Make it easier to convert feature bits to CPU properties, as now we
have a single bit on the x86_def_t struct for each CPU feature.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Don Slutz <Don@CloudSwitch.com>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Both constants have the same value, but CPUID_EXT2_AMD_ALIASES is
defined without using magic numbers.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Don Slutz <Don@CloudSwitch.com>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Instea of using a hardcoded hex constant, define CPUID_EXT2_AMD_ALIASES
as the set of CPUID[8000_0001].EDX bits that on AMD are the same as the
bits of CPUID[1].EDX.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-By: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Don Slutz <Don@CloudSwitch.com>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Bit 10 of CPUID[8000_0001].EDX is not defined as an alias of
CPUID[1].EDX[10], so do not duplicate it on
kvm_arch_get_supported_cpuid().
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-By: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Don Slutz <Don@CloudSwitch.com>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
For all targets that currently call tcg_gen_debug_insn_start,
add CPU_LOG_TB_OP_OPT to the condition that gates it.
This is useful for comparing optimization dumps, when the
pre-optimization dump is merely noise.
Signed-off-by: Richard Henderson <rth@twiddle.net>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
* stefanha/trivial-patches:
w32: Always use standard instead of native format strings
net/socket: Fix compiler warning (regression for MinGW)
linux-user: Remove redundant null check and replace free by g_free
qemu-timer: simplify qemu_run_timers
TextConsole: saturate escape parameter in TTY_STATE_CSI
curses: don't initialize curses when qemu is daemonized
dtrace backend: add function to reserved words
pflash_cfi01: Fix warning caused by unreachable code
ioh3420: Remove unreachable code
lm4549: Fix buffer overflow
cadence_uart: Fix buffer overflow
qemu-sockets: Fix potential memory leak
qemu-ga: Remove unreachable code after g_error
target-i386: Allow tsc-frequency to be larger then 2.147G
The check using INT_MAX (2147483647) is wrong in this case.
Signed-off-by: Fred Oliveira <foliveira@cloudswitch.com>
Signed-off-by: Don Slutz <Don@CloudSwitch.com>
Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
It was only used by now removed setfeatures() function.
Suggested-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
It's nice to have a flexible system to maintain CPU models as data, but
this is holding us from making improvements in the CPU code because it's
not using the common infra-structure, and because the machine-type data
is still inside C code.
Users who want to configure CPU features directly may simply use the
"-cpu" command-line option (and maybe an equivalent -device option in
the future) to set CPU features.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Those models are maintained by QEMU and may require compatibility code
to be added when making some changes. Keeping the data in the C source
code should make it simpler to handle those details.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Don Slutz <Don@CloudSwitch.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Those constants will be used by new CPU model definitions.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Since the only user of the extended cpu_list_id() format
was the x86 ?model/?dump/?cpuid output, we can drop it
completely.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Commit c8057f95 (accidentally) disabled the ability to pass
option strings starting with '?' to the target-specific
cpu_list function, so the target-i386 specific "-cpu ?dump",
"-cpu ?cpuid" and "-cpu ?model" stopped working.
Since these options are undocumented and not used by libvirt,
simply drop them completely rather than reinstating them
with new style syntax. Instead, we fold the ?model and ?cpuid
output into the output of the plain "-cpu help" output. The
detailed output produced by ?dump is dropped.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
These helpers abstract the interaction of upcoming pci-assign with the
KVM kernel services. Put them under i386 only as other archs will
implement device pass-through via VFIO and not this classic interface.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Acked-by: Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
Commit ef8621b1a3 added an include
file which is not available for MinGW compilations.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Support get/set of new PV EOI MSR, for migration.
Add an optional section for MSR value - send it
out in case MSR was changed from the default value (0).
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
We have a problem with how we handle migration with KVM paravirt features.
We unconditionally enable paravirt features regardless of whether we know how
to migrate them.
We also don't tie paravirt features to specific machine types so an old QEMU on
a new kernel would expose features that never existed.
The 1.2 cycle is over and as things stand, migration is broken. Michael has
another series that adds support for migrating PV EOI and attempts to make it
work correctly for different machine types.
After speaking with Michael on IRC, we agreed to take this patch plus 1 & 4
from his series. This makes sure QEMU can migrate PV EOI if it's enabled, but
does not enable it by default.
This also means that we won't unconditionally enable new features for guests
future proofing us from this happening again in the future.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
> This instruction is always treated as a register-to-register (MOD = 11)
> instruction, regardless of the encoding of the MOD field in the MODR/M
> byte.
Also, Microport UNIX System V/386 v 2.1 (ca 1987) runs fine on
real Intel 386 and 486 CPU's (at least), but does not run in qemu without
this patch.
Signed-off-by: Matthew Ogilvie <mmogilvi_qemu@miniinfo.net>
Signed-off-by: malc <av1474@comtv.ru>
mingw32 seems to want the declaration to also carry the weak attribute.
Strangely, gcc on Linux absolutely does not want the declaration to be marked
as weak. This may not be the right fix, but it seems to do the trick.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Add an explicit CPUX86State parameter instead of relying on AREG0.
Remove temporary wrappers and switch to AREG0 free mode.
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Add an explicit CPUX86State parameter instead of relying on AREG0.
Rename remains of op_helper.c to seg_helper.c.
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Make FPU helpers take a parameter for CPUState instead
of relying on global env.
Introduce temporary wrappers for FPU load and store ops. Remove
wrappers for non-AREG0 code. Don't call unconverted helpers
directly.
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
* qmp/queue/qmp: (48 commits)
target-ppc: add implementation of query-cpu-definitions (v2)
target-i386: add implementation of query-cpu-definitions (v2)
qapi: add query-cpu-definitions command (v2)
compiler: add macro for GCC weak symbols
qapi: add query-machines command
qapi: mark QOM commands stable
qmp: introduce device-list-properties command
qmp: add SUSPEND_DISK event
qmp: qmp-events.txt: add missing doc for the SUSPEND event
qmp: qmp-events.txt: put events in alphabetical order
qmp: emit the WAKEUP event when the guest is put to run
qmp: don't emit the RESET event on wakeup from S3
scripts: qapi-commands.py: qmp-commands.h: include qdict.h
docs: writing-qmp-commands.txt: update error section
error, qerror: drop QDict member
qerror: drop qerror_table and qerror_format()
error, qerror: pass desc string to error calls
error: drop error_get_qobject()/error_set_qobject()
qemu-ga: switch to the new error format on the wire
qmp: switch to the new error format on the wire
...
* qemu-kvm/uq/master:
kvm: Add documentation comment for kvm_irqchip_in_kernel()
kvm: Decouple 'GSI routing' from 'kernel irqchip'
kvm: Decouple 'MSI routing via irqfds' from 'kernel irqchip'
kvm: Decouple 'irqfds usable' from 'kernel irqchip'
kvm: Move kvm_allows_irq0_override() to target-i386, fix return type
kvm: Rename kvm_irqchip_set_irq() to kvm_set_irq()
kvm: Decouple 'async interrupt delivery' from 'kernel irqchip'
configure: Don't implicitly hardcode list of KVM architectures
kvm: Check if smp_cpus exceeds max cpus supported by kvm
* 'x86cpu_qom_tcg_v2' of git://github.com/imammedo/qemu:
target-i386: move tcg initialization into x86_cpu_initfn()
cleanup cpu_set_debug_excp_handler
target-xtensa: drop usage of prev_debug_excp_handler
target-i386: drop usage of prev_debug_excp_handler
Don't assume having an in-kernel irqchip means that GSI
routing is enabled.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Avi Kivity <avi@redhat.com>
Decouple another x86-specific assumption about what irqchips imply.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Avi Kivity <avi@redhat.com>
Instead of assuming that we can use irqfds if and only if
kvm_irqchip_in_kernel(), add a bool to the KVMState which
indicates this, and is set only on x86 and only if the
irqchip is in the kernel.
The kernel documentation implies that the only thing
you need to use KVM_IRQFD is that KVM_CAP_IRQFD is
advertised, but this seems to be untrue. In particular
the kernel does not (alas) return a sensible error if you
try to set up an irqfd when you haven't created an irqchip.
If it did we could remove all this nonsense and let the
kernel return the error code.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Acked-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
kvm_allows_irq0_override() is a totally x86 specific concept:
move it to the target-specific source file where it belongs.
This means we need a new header file for the prototype:
kvm_i386.h, in line with the existing kvm_ppc.h.
While we are moving it, fix the return type to be 'bool' rather
than 'int'.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Avi Kivity <avi@redhat.com>
Moving reset callback into cpu object from board level and
resetting cpu at the end of x86_cpu_realize() will allow properly
create cpu object during run-time (hotplug) without calling reset externaly.
When reset over QOM hierarchy is implemented, reset callback
should be removed.
v2:
- leave cpu_reset in pc_new_cpu() for now, it's to be cleaned up when APIC
init is moved in cpu.c
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
MP initialization protocol differs between cpu families, and for P6 and
onward models it is up to CPU to decide if it will be BSP using this
protocol, so try to model this. However there is no point in implementing
MP initialization protocol in qemu. Thus first CPU is always marked as BSP.
This patch:
- moves decision to designate BSP from board into cpu, making cpu
self-sufficient in this regard. Later it will allow to cleanup hw/pc.c
and remove cpu_reset and wrappers from there.
- stores flag that CPU is BSP in IA32_APIC_BASE to model behavior
described in Inted SDM vol 3a part 1 chapter 8.4.1
- uses MSR_IA32_APICBASE_BSP flag in apic_base for checking if cpu is BSP
patch is based on Jan Kiszka's proposal:
http://thread.gmane.org/gmane.comp.emulators.qemu/100806
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
According to the Intel manual
"Intel® 64 and IA-32 Architectures Software Developer’s Manual
Volume 3", "3.4.4 Segment Loading Instructions in IA-32e Mode":
"When in compatibility mode, FS and GS overrides operate as defined by
32-bit mode behavior regardless of the value loaded into the upper 32
linear-address bits of the hidden descriptor register base field.
Compatibility mode ignores the upper 32 bits when calculating an effective address."
However, the code misses the 64-bit mode case, where an instruction with
address and segment size override would be translated incorrectly. For example,
inc dword ptr gs:260h[ebx*4] gets incorrectly translated to:
(uint32_t)(gs.base + ebx * 4 + 0x260)
instead of
gs.base + (uint32_t)(ebx * 4 + 0x260)
Signed-off-by: Vitaly Chipounov <vitaly.chipounov@epfl.ch>
Reviewed-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
This patch makes Qemu recognize the PCID feature specified from configuration or command line options.
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
