This will reuse the existing check/enforce logic in
x86_cpu_filter_features() to check the xsave component bits
against GET_SUPPORTED_CPUID.
Backports commit 96193c22ab39ea24f81e386ad7883260ff24f5fd from qemu
Instead of doing complex calculations and calling
kvm_arch_get_supported_cpuid() inside cpu_x86_cpuid(), calculate
the set of required XSAVE components earlier, at realize time.
Backports commit 2ca8a8becc2eeb5262e478ce502f5daa53f3d0bc from qemu
Instead of requiring users and management software to be aware of
required CPUID level/xlevel/xlevel2 values for each feature,
automatically increase those values when features need them.
This was already done for CPUID[7].EBX, and is now made generic
for all CPUID feature flags. Unit test included, to make sure we
don't break ABI on older machine-types and don't mess with the
CPUID level values if they are explicitly set by the user.
Backports commit c39c0edf9bb3b968ba95484465a50c7b19f4aa3a from qemu
Instead of using cpuid_level, use an empty struct as a marker
(like we already did with {start,end}_init_save). This will avoid
accidentaly resetting the wrong fields if we change the field
ordering on CPUX86State.
Backports commit 5e992a8e337e710ea2d02f35668ac55a80e15f99 from qemu
This avoids a double hand-full of magic numbers in the
xsave and xrstor helper functions.
Backports commit 3f32bd21df655e62eb271182a5c63280d631c7b3 from qemu
Make sure reset zeroes TSC_AUX, XCR0, PKRU. Move XSTATE_BV from the
"vmstate only" section to the "KVM only" section.
Backports commit 7616f1c2da1c0f336a474a56ad6d32e15ccd666e from qemu
Some software algorithms are based on the hardware's cache info, for example,
for x86 linux kernel, when cpu1 want to wakeup a task on cpu2, cpu1 will trigger
a resched IPI and told cpu2 to do the wakeup if they don't share low level
cache. Oppositely, cpu1 will access cpu2's runqueue directly if they share llc.
The relevant linux-kernel code as bellow:
static void ttwu_queue(struct task_struct *p, int cpu)
{
struct rq *rq = cpu_rq(cpu);
......
if (... && !cpus_share_cache(smp_processor_id(), cpu)) {
......
ttwu_queue_remote(p, cpu); /* will trigger RES IPI */
return;
}
......
ttwu_do_activate(rq, p, 0); /* access target's rq directly */
......
}
In real hardware, the cpus on the same socket share L3 cache, so one won't
trigger a resched IPIs when wakeup a task on others. But QEMU doesn't present a
virtual L3 cache info for VM, then the linux guest will trigger lots of RES IPIs
under some workloads even if the virtual cpus belongs to the same virtual socket.
For KVM, there will be lots of vmexit due to guest send IPIs.
The workload is a SAP HANA's testsuite, we run it one round(about 40 minuates)
and observe the (Suse11sp3)Guest's amounts of RES IPIs which triggering during
the period:
No-L3 With-L3(applied this patch)
cpu0: 363890 44582
cpu1: 373405 43109
cpu2: 340783 43797
cpu3: 333854 43409
cpu4: 327170 40038
cpu5: 325491 39922
cpu6: 319129 42391
cpu7: 306480 41035
cpu8: 161139 32188
cpu9: 164649 31024
cpu10: 149823 30398
cpu11: 149823 32455
cpu12: 164830 35143
cpu13: 172269 35805
cpu14: 179979 33898
cpu15: 194505 32754
avg: 268963.6 40129.8
The VM's topology is "1*socket 8*cores 2*threads".
After present virtual L3 cache info for VM, the amounts of RES IPIs in guest
reduce 85%.
For KVM, vcpus send IPIs will cause vmexit which is expensive, so it can cause
severe performance degradation. We had tested the overall system performance if
vcpus actually run on sparate physical socket. With L3 cache, the performance
improves 7.2%~33.1%(avg:15.7%).
Backports commit 14c985cffa6cb177fc01a163d8bcf227c104718c from qemu
These are both stored in CPUID[EAX=7,EBX=0].ECX. KVM is going to
be able to emulate both (albeit with a performance loss in the case
of RDPID, which therefore will be in KVM_GET_EMULATED_CPUID rather
than KVM_GET_SUPPORTED_CPUID).
It's also possible to implement both in TCG, but this is for 2.8.
Backports commit c2f193b538032accb9db504998bf2ea7c0ef65af from qemu
These properties will be used by as address where to plug
CPU with help -device/device_add commands.
Backports commit d89c2b8b98e097b9cad5104b0f178bde1cfa011b from qemu
Add the host-phys-bits boolean property, if true, take phys-bits
from the hosts physical bits value, overriding either the default
or the user specified value.
We can also use the value we read from the host to check the users
explicitly set value and warn them if it doesn't match.
Note:
a) We only read the hosts value in KVM mode (because on non-x86
we get an abort if we try)
b) We don't warn about trying to use host-phys-bits in TCG mode,
we just fall back to the TCG default. This allows the machine
type to set the host-phys-bits flag if it wants and then to
work in both TCG and KVM.
Backports commit 11f6fee576680a2d482123535da920f8ceb33eb5 from qemu
Redo 9886e834 (target-i386: Require APIC ID to be explicitly set before
CPU realize) in another way that doesn't use int64_t to detect
if apic-id property has been set.
Use the fact that 0xFFFFFFFF is the broadcast
value that a CPU can't have and set default
uint32_t apic_id to it instead of using int64_t.
Later uint32_t apic_id will be used to drop custom
property setter/getter in favor of static property.
Backports commit d9c84f196970f78d4b55ab87e03cbcad7c65f86f from qemu
Fill the bits between 51..number-of-physical-address-bits in the
MTRR_PHYSMASKn variable range mtrr masks so that they're consistent
in the migration stream irrespective of the physical address space
of the source VM in a migration.
Backports commit fcc35e7ccaed771790940524f3b0eef7aebfc9b1 from qemu
Currently QEMU sets the x86 number of physical address bits to the
magic number 40. This is only correct on some small AMD systems;
Intel systems tend to have 36, 39, 46 bits, and large AMD systems
tend to have 48.
Having the value different from your actual hardware is detectable
by the guest and in principal can cause problems;
The current limit of 40 stops TB VMs being created by those lucky
enough to have that much.
This patch lets you set the physical bits by a cpu property but
defaults to the same 40bits which matches TCGs setup.
I've removed the ancient warning about the 42 bit limit in exec.c;
I can't find that limit in there and no one else seems to know where
it is.
We use a magic value of 0 as the property default so that we can
later distinguish between the default and a user set value.
Backports commit af45907a132857cfd47acc998bf5f7c26cd13071 from qemu
'HF_SOFTMMU_MASK' is only set when 'CONFIG_SOFTMMU' is defined. So
there's no need in this flag: test 'CONFIG_SOFTMMU' instead.
Backports commit da6d48e3348bbc266896cf8adf0c33f1eaf5b31f from qemu
Most of them use guard symbols like CPU_$target_H, but we also have
__MIPS_CPU_H__ and __TRICORE_CPU_H__. They all upset
scripts/clean-header-guards.pl.
The script dislikes CPU_$target_H because they don't match their file
name (they should, to make guard collisions less likely). The others
are reserved identifiers.
Clean them all up: use guard symbol $target_CPU_H for
target-$target/cpu.h.
Backports commit 07f5a258750b3b9a6e10fd5ec3e29c9a943b650e from qemu
It's a prerequisite that certain bits of MSR_IA32_FEATURE_CONTROL should
be set before some features (e.g. VMX and LMCE) can be used, which is
usually done by the firmware. This patch adds a fw_cfg file
"etc/msr_feature_control" which contains the advised value of
MSR_IA32_FEATURE_CONTROL and can be used by guest firmware (e.g. SeaBIOS).
Backports commit 217f1b4a72153cf8d556e9d45919e9222c38d25e from qemu
This patch adds the support to inject SRAR and SRAO as LMCE, i.e. they
are injected to only one VCPU rather than broadcast to all VCPUs. As KVM
reports LMCE support on Intel platforms, this features is only available
on Intel platforms.
LMCE is disabled by default and can be enabled/disabled by cpu option
'lmce=on/off'.
Backports commit 87f8b626041ceaea9adcfdbd549359f0ca7b871d from qemu
This change adds hyperv feature words report through qom rpc.
When VM is configured with hyperv features enabled
libvirt will check that required feature words are set
in cpuid leaf 40000003 through qom request.
Currently qemu does not report hyperv feature words
which prevents windows guests from starting with libvirt.
To avoid conflicting with current hyperv properties all added feature
words cannot be set directly with -cpu +feature yet.
Backports commit c35bd19a5c9140bce8b913cc5cefe6f071135bdb from qemu
Making x86_cpu_parse_featurestr() a pure convertor
of legacy feature string into global properties, needs
it to be called before a CPU instance is created so
parser shouldn't modify CPUState directly or access
it at all. Hence move current hack that directly pokes
into CPUState, to set/unset +-feats, from parser to
CPU's realize method.
Backports commit dc15c0517b010a9444a2c05794dae980f2a2cbd9 from qemu
I looked at a dozen Intel CPU that have this CPUID and all of them
always had Core offset as 1 (a wasted bit when hyperthreading is
disabled) and Package offset at least 4 (wasted bits at <= 4 cores).
QEMU uses more compact IDs and it doesn't make much sense to change it
now. I keep the SMT and Core sub-leaves even if there is just one
thread/core; it makes the code simpler and there should be no harm.
Backports commit 5232d00a041c8f3628b3532ef35d703a1f0dac19 from qemu
x86_cpudef_init() doesn't do anything anymore, cpudef_init(),
cpudef_setup(), and x86_cpudef_init() can be finally removed.
Backports commit 3e2c0e062f0963a6b73b0cd1990fad79495463d9 from qemu
Add structs that define the layout of the xsave areas used by
Intel processors. Add some QEMU_BUILD_BUG_ON lines to ensure the
structs match the XSAVE_* macros in target-i386/kvm.c and the
offsets and sizes at target-i386/cpu.c:ext_save_areas.
Backports commit b503717d28e8f7eff39bf38624e6cf42687d951a from qemu
exec-all.h contains TCG-specific definitions. It is not needed outside
TCG-specific files such as translate.c, exec.c or *helper.c.
One generic function had snuck into include/exec/exec-all.h; move it to
include/qom/cpu.h.
Backports commit 63c915526d6a54a95919ebece83fa9ca631b2508 from qemu
Make X86CPU an opaque type within cpu-qom.h, and move all definitions of
private methods, as well as all type definitions that require knowledge
of the layout to cpu.h. This helps making files independent of NEED_CPU_H
if they only need to pass around CPU pointers.
Backports commit 4da6f8d954429c0cd1471d25cb9dbe909607374e from qemu
We are inconsistent with the type of tb->flags: usage varies loosely
between int and uint64_t. Settle to uint32_t everywhere, which is
superior to both: at least one target (aarch64) uses the most significant
bit in the u32, and uint64_t is wasteful.
Compile-tested for all targets.
Backports commit 89fee74a0f066dfd73830a7b5fa137e87888c870 from qemu
The xsave and xrstor helpers are accessing the x86_ext_save_areas array
using a bit mask instead of a bit position. Provide two sets of XSTATE_*
definitions and use XSTATE_*_BIT when a bit position is requested.
Backports commit cfc3b074de4b4ccee2540edbf8cfdb026dc19943 from qemu
This patch enables migrating vcpu's TSC rate. If KVM on the
destination machine supports TSC scaling, guest programs will
observe a consistent TSC rate across the migration.
If TSC scaling is not supported on the destination machine, the
migration will not be aborted and QEMU on the destination will
not set vcpu's TSC rate to the migrated value.
If vcpu's TSC rate specified by CPU option 'tsc-freq' on the
destination machine is inconsistent with the migrated TSC rate,
the migration will be aborted.
For backwards compatibility, the migration of vcpu's TSC rate is
disabled on pc-*-2.5 and older machine types.
Backports relevant parts of commit 36f96c4b6bd25f43000c317518ff3df10202bc75 from qemu
This will ensure we never use the MMX_* and ZMM_* macros with the
wrong struct type.
Backports commit f23a9db6bca5b9a228c77bbcaa06d01510e148b7 from qemu
Add a new field and reorder MMXReg fields, to make MMXReg and
ZMMReg field lists look the same (except for the array sizes).
Backports commit 9253e1a7923e94598419ac9a7df7b8bc6cba65a5 from qemu
They are helpers for the ZMMReg fields, so name them accordingly.
This is just a global search+replace, no other changes are being
introduced.
Backports commit 19cbd87c14ab208858ee1233b790f37cfefed4b9 from qemu
The struct represents a 512-bit register, so name it accordingly.
This is just a global search+replace, no other changes are being
introduced.
Backports commit fa4518741ed69aa7993f9c15bb52eacc375681fc from qemu
Make MMXReg use the same field names used on XMMReg, so we can
try to reuse macros and other code later.
Backports commit 9618f40f06e90c8fa8ae06b56c7404a7cc937e22 from qemu
Rename the function so that the reason for its existence is
clearer: it does x86-specific initialization of TCG structures.
Backports commit 63618b4ed48f0fc2a7a3fd1117e2f0b512248dab from qemu
The TARGET_HAS_ICE #define is intended to indicate whether a target-*
guest CPU implementation supports the breakpoint handling. However,
all our guest CPUs have that support (the only two which do not
define TARGET_HAS_ICE are unicore32 and openrisc, and in both those
cases the bp support is present and the lack of the #define is just
a bug). So remove the #define entirely: all new guest CPU support
should include breakpoint handling as part of the basic implementation.
Backports commit ec53b45bcd1f74f7a4c31331fa6d50b402cd6d26 from qemu
Introduce helper_get_dr so that we don't have to put CR4[DE]
into the scarce HFLAGS resource. At the same time, rename
helper_movl_drN_T0 to helper_set_dr and set the helper flags.
Backports commit d0052339236072bbf08c1d600c0906126b1ab258 from qemu
This moves the last of the iteration over breakpoints into
the bpt_helper.c file. This also allows us to make several
breakpoint functions static.
Backports commit 93d00d0fbe4711061834730fb70525d167b6f908 from qemu
When doing a re-initialization of a CPU core, the default state is to _not_
have 64-bit long mode enabled. This means the LME (long mode enable) and LMA
(long mode active) bits in the EFER model-specific register should be cleared.
However, the EFER state is part of the CPU environment which is
preserved by do_cpu_init(), so if EFER.LME and EFER.LMA were set at the
time an INIT IPI was received, they will remain set after the init completes.
This is contrary to what the Intel architecture manual describes and what
happens on real hardware, and it leaves the CPU in a weird state that the
guest can't clear.
To fix this, the 'efer' member of the CPUX86State structure has been moved
to an area outside the region preserved by do_cpu_init(), so that it can
be properly re-initialized by x86_cpu_reset().
Backports commit 2188cc52cb363433751f72b991d8fb05fc60e39d from qemu
Rename ELF_MACHINE to be I386 specific. This is used as-is by the
multiboot loader.
Linux-user previously used this definition but will not anymore,
falling back to the default bahaviour of using ELF_ARCH as ELF_MACHINE.
This removes another architecture specific definition from the global
namespace.
Backports commit a5e8788f89312f19f54dba0454ee5bf7209b4cd7 from qemu
