- 18 10月, 2016 1 次提交
-
-
由 Eduardo Habkost 提交于
Instead of using the builtin_x86_defs array, use the QOM subclass list to list CPU models on "-cpu ?" and "query-cpu-definitions". Signed-off-by: NAndreas Färber <afaerber@suse.de> [ehabkost: copied code from a patch by Andreas: "target-i386: QOM'ify CPU", from March 2012] Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
- 04 10月, 2016 2 次提交
-
-
由 Evgeny Yakovlev 提交于
Current CPU definition for AMD Opteron third generation includes features like SSE4a and LAHF_LM support in emulated CPUID. These features are present in K8 rev.E or K10 CPUs and later. However, current G3 family and model describe 2nd generation K8 cores instead. This is incorrect but was considered harmless until our tests found a problem with linux kernels >= 3.10 (and maybe earlier) which specifically check for Opteron K8 model when parsing CPUID leaf 0x80000001: http://lxr.free-electrons.com/source/arch/x86/kernel/cpu/amd.c?v=3.16#L552 This code will disable LAHF_LM feature in /proc/cpuinfo if model number is inconsistent. This change sets Opteron_G3 family/model/stepping to 16/2/3 which is a proper Opteron 3rd generation 2350 CPU. Signed-off-by: NEvgeny Yakovlev <eyakovlev@virtuozzo.com> Signed-off-by: NDenis V. Lunev <den@openvz.org> CC: Paolo Bonzini <pbonzini@redhat.com> CC: Richard Henderson <rth@twiddle.net> CC: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Eduardo Habkost 提交于
A regression was introduced by commit 96193c22 "target-i386: Move xsave component mask to features array": all CPUID[EAX=0xD,ECX=0]:EAX bits were being reported as unmigratable because they don't have feature names defined. This broke "-cpu host" because it enables only migratable features by default. This adds a new field to FeatureWordInfo: migratable_flags, which will make those features be reported as migratable even if they don't have a property name defined. Reported-by: NWanpeng Li <wanpeng.li@hotmail.com> Cc: Paolo Bonzini <bonzini@gnu.org> Reviewed-by: NWanpeng Li <wanpeng.li@hotmail.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
- 28 9月, 2016 13 次提交
-
-
由 Eduardo Habkost 提交于
This will ensure all checks for features[FEAT_KVM] in the code will be correct in case the KVM CPUID leaf is completely disabled. Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Eduardo Habkost 提交于
This will reuse the existing check/enforce logic in x86_cpu_filter_features() to check the xsave component bits against GET_SUPPORTED_CPUID. Reviewed-by: NRichard Henderson <rth@twiddle.net> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Eduardo Habkost 提交于
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. Signed-off-by: NEduardo Habkost <ehabkost@redhat.com> Reviewed-by: NRichard Henderson <rth@twiddle.net> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Eduardo Habkost 提交于
Move the xsave area size calculation from cpu_x86_cpuid() inside its own function. While doing it, change it to use the XSAVE area struct sizes for the initial size, instead of the magic 0x240 number. Reviewed-by: NRichard Henderson <rth@twiddle.net> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Eduardo Habkost 提交于
Instead of assigning individual bits in a loop, just copy the values from ena_mask. Reviewed-by: NRichard Henderson <rth@twiddle.net> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Eduardo Habkost 提交于
Instead of checking both env->features and ena_mask at two different places in the CPUID code, initialize ena_mask based on the features that are enabled for the CPU, and then clear unsupported bits based on kvm_arch_get_supported_cpuid(). The results should be exactly the same, but it will make it easier to move the mask calculation elsewhare, and reuse x86_cpu_filter_features() for the kvm_arch_get_supported_cpuid() check. Reviewed-by: NRichard Henderson <rth@twiddle.net> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Eduardo Habkost 提交于
The code that calculates the set of supported XSAVE components on CPUID looks at ext_save_areas to find out which components should be enabled. However, if there are zeroed entries in the ext_save_areas array, the ((env->features[esa->feature] & esa->bits) == esa->bits) check will always succeed and QEMU will unconditionally try to enable the component. Luckily this never caused any problems because the only missing entry in ext_save_areas is the PT State component (bit 8), and KVM currently doesn't support it (so it was cleared on ena_mask). But the code was still incorrect and would break if KVM starts returning CPUID[EAX=0xD,ECX=0].EAX[bit 8] as supported on GET_SUPPORTED_CPUID. Fix the problem by changing the code to not enable a XSAVE component if ExtSaveArea::bits is zero. Reviewed-by: NRichard Henderson <rth@twiddle.net> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Eduardo Habkost 提交于
It makes it easier to guarantee the arrays are the right size, and to find information when looking at the code. Reviewed-by: NRichard Henderson <rth@twiddle.net> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Marc-André Lureau 提交于
Those are unneeded now that CPUState nr_{cores,threads} is always initialized. Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Acked-by: NDavid Gibson <david@gibson.dropbear.id.au> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Eduardo Habkost 提交于
SVM needs CPUID[0x8000000A] to be available. So if SVM is enabled in a CPU model or explicitly in the command-line, adjust CPUID xlevel to expose the CPUID[0x8000000A] leaf. Reviewed-by: NRichard Henderson <rth@twiddle.net> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Eduardo Habkost 提交于
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. Reviewed-by: NRichard Henderson <rth@twiddle.net> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Eduardo Habkost 提交于
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. Reviewed-by: NRichard Henderson <rth@twiddle.net> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Eduardo Habkost 提交于
No CPU model in builtin_x86_defs has xlevel2 set, so it is always zero. Delete the field. Note that this is not an user-visible change. It doesn't remove the ability to set xlevel2 on the command-line, it just removes an unused field in builtin_x86_defs. Reviewed-by: NRichard Henderson <rth@twiddle.net> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
- 20 9月, 2016 1 次提交
-
-
由 Richard Henderson 提交于
This avoids a double hand-full of magic numbers in the xsave and xrstor helper functions. Signed-off-by: NRichard Henderson <rth@twiddle.net> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
- 10 9月, 2016 1 次提交
-
-
由 Longpeng(Mike) 提交于
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%). Signed-off-by: NLongpeng(Mike) <longpeng2@huawei.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
- 06 9月, 2016 1 次提交
-
-
由 Luwei Kang 提交于
Add more AVX512 feature bits, include AVX512DQ, AVX512IFMA, AVX512BW, AVX512VL, AVX512VBMI. Its spec can be found at: https://software.intel.com/sites/default/files/managed/b4/3a/319433-024.pdfSigned-off-by: NLuwei Kang <luwei.kang@intel.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
- 20 7月, 2016 12 次提交
-
-
由 Igor Mammedov 提交于
First remove VCPU from exec loop and only then remove lapic. Signed-off-by: NChen Fan <chen.fan.fnst@cn.fujitsu.com> Signed-off-by: NGu Zheng <guz.fnst@cn.fujitsu.com> Signed-off-by: NZhu Guihua <zhugh.fnst@cn.fujitsu.com> Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Igor Mammedov 提交于
Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Igor Mammedov 提交于
Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Igor Mammedov 提交于
object_property_add_child() silently fails with error that it can't create duplicate propery 'apic' as we already have 'apic' property registered for 'apic' feature. As result generic device_realize puts apic into unattached container. As it's programming error, abort if name collision happens in future and fix property name for apic_state to 'lapic', this way apic is a child of cpu instance. Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Paolo Bonzini 提交于
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. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Igor Mammedov 提交于
These properties will be used by as address where to plug CPU with help -device/device_add commands. Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Igor Mammedov 提交于
Custom apic-id setter/getter doesn't do any property specific checks anymore, so clean it up and use more compact static property DEFINE_PROP_UINT32 instead. Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Igor Mammedov 提交于
Machine code knows about all possible APIC IDs so use that instead of hack which does O(n^2) complexity duplicate checks, interating over global CPUs list. As result duplicate check is done only once with O(log n) complexity. Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Dr. David Alan Gilbert 提交于
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. Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Igor Mammedov 提交于
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. Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Dr. David Alan Gilbert 提交于
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. Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Suggested-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Dr. David Alan Gilbert 提交于
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. Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
- 19 7月, 2016 1 次提交
-
-
由 Sergey Fedorov 提交于
'HF_SOFTMMU_MASK' is only set when 'CONFIG_SOFTMMU' is defined. So there's no need in this flag: test 'CONFIG_SOFTMMU' instead. Suggested-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NSergey Fedorov <serge.fdrv@gmail.com> Signed-off-by: NSergey Fedorov <sergey.fedorov@linaro.org> Reviewed-by: NAlex Bennée <alex.bennee@linaro.org> Message-Id: <20160715175852.30749-6-sergey.fedorov@linaro.org> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 08 7月, 2016 7 次提交
-
-
由 Haozhong Zhang 提交于
If -cpu host is used, LMCE will be automatically enabled when it's supported by host. Signed-off-by: NHaozhong Zhang <haozhong.zhang@intel.com> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Ashok Raj 提交于
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'. Signed-off-by: NAshok Raj <ashok.raj@intel.com> [Haozhong: Enable LMCE only on Intel platforms Disable LMCE by default and add a cpu option 'lmce' Handle the error if LMCE is enabled w/o host support Remove MCG_LMCE_P from MCE_CAP_DEF Add migration support for LMCE Minor code style changes] Signed-off-by: NHaozhong Zhang <haozhong.zhang@intel.com> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Evgeny Yakovlev 提交于
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. Signed-off-by: NEvgeny Yakovlev <eyakovlev@virtuozzo.com> Signed-off-by: NDenis V. Lunev <den@openvz.org> CC: Paolo Bonzini <pbonzini@redhat.com> CC: Richard Henderson <rth@twiddle.net> CC: Eduardo Habkost <ehabkost@redhat.com> CC: Marcelo Tosatti <mtosatti@redhat.com> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Igor Mammedov 提交于
Considering that features are converted to global properties and global properties are automatically applied to every new instance of created CPU (at object_new() time), there is no point in parsing cpu_model string every time a CPU created. So move parsing outside CPU creation loop and do it only once. Parsing also should be done before any CPU is created so that features would affect the first CPU a well. Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Igor Mammedov 提交于
Currently CPUClass->parse_features() is used to parse -cpu features string and set properties on created CPU instances. But considering that features specified by -cpu apply to every created CPU instance, it doesn't make sense to parse the same features string for every CPU created. It also makes every target that cares about parsing features string explicitly call CPUClass->parse_features() parser, which gets in a way if we consider using generic device_add for CPU hotplug as device_add has not a clue about CPU specific hooks. Turns out we can use global properties mechanism to set properties on every created CPU instance for a given type. That way it's possible to convert CPU features into a set of global properties for CPU type specified by -cpu cpu_model and common Device.device_post_init() will apply them to CPU of given type automatically regardless whether it's manually created CPU or CPU created with help of device_add. Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Paolo Bonzini 提交于
x86_cpu_parse_featurestr has a "val = num;" assignment just before num goes out of scope. Push num up to fix the issue. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Paolo Bonzini 提交于
ERMS just says "rep movsb" and "rep stosb" are fast. It does not imply any new instruction, so we can support it easily. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
- 20 6月, 2016 1 次提交
-
-
由 Eduardo Habkost 提交于
This patch simplifies code that uses a local_err variable just to immediately use it for an error_propagate() call. Coccinelle patch used to perform the changes added to scripts/coccinelle/remove_local_err.cocci. Reviewed-by: NEric Blake <eblake@redhat.com> Acked-by: NCornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com> Message-Id: <1465855078-19435-3-git-send-email-ehabkost@redhat.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> [Blank line in s390-virtio-ccw.c restored] Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
-