- 18 10月, 2016 9 次提交
-
-
由 Radim Krčmář 提交于
Every configuration has only up to one APIC class and we'll be extending the class with a function that can be called without an instanced object, so a direct access to the class is convenient. This patch will break compilation if some code uses apic_get_class() with CONFIG_USER_ONLY. Suggested-by: NEduardo Habkost <ehabkost@redhat.com> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Reviewed-by: NPeter Xu <peterx@redhat.com> Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Eduardo Habkost 提交于
x86_cpu_filter_features() will be reused by code that shouldn't print any warning. Move the warning code to a new x86_cpu_report_filtered_features() function, and call it from x86_cpu_realizefn(). Reviewed-by: NIgor Mammedov <imammedo@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Eduardo Habkost 提交于
Instead of treating the FP and SSE bits as special cases, add them to the x86_ext_save_areas array. This will simplify the code that calculates the supported xsave components and the size of the xsave area. Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Eduardo Habkost 提交于
Instead of keeping the aliases inside the feature name arrays and require parsing the strings, just register alias properties manually. This simplifies the code for property registration and lookup. Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Eduardo Habkost 提交于
Instead of translating the feature name entries when adding property names, store the actual property names in the feature name array. For reference, here is the full list of functions that use FeatureWordInfo::feat_names: * x86_cpu_get_migratable_flags(): not affected, as it just check for non-NULL values. * report_unavailable_features(): informative only. It will start printing feature names with hyphens. * x86_cpu_list(): informative only. It will start printing feature names with hyphens * x86_cpu_register_feature_bit_props(): not affected, as it was already calling feat2prop(). Now we can remove the feat2prop() calls safely. So, the only user-visible effect of this patch are the new names being used in help and error messages for users. Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Eduardo Habkost 提交于
Instead of using custom feature name lookup code for plus_features/minus_features, save the property names used in "[+-]feature" and use object_property_set_bool() to set them. We don't need a feat2prop() call because we now have alias properties for the old names containing underscores. Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Eduardo Habkost 提交于
Registering the actual names containing underscores as aliases will allow management software to be aware that the old compatibility names are suported, and will make feat2prop() calls unnecessary when using feature names. Also, this will help us avoid making the code support underscores on feature names that never had them in the first place. e.g. "+tsc_deadline" was never supported and doesn't need to be translated to "+tsc-deadline". In other word: this will require less magic translation of strings, and simple 1:1 match between the config options and actual QOM properties. Note that the underscores are still present in the FeatureWordInfo::feat_names arrays, because add_flagname_to_bitmaps() needs them to be kept. The next patches will remove add_flagname_to_bitmaps() and will allow us to finally remove the aliases from feat_names. Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Eduardo Habkost 提交于
VME is already disabled automatically when using TCG. So, instead of pretending it is there when reporting CPU model data on query-cpu-* QMP commands (making every CPU model to be reported as not runnable), we can disable it by default on all CPU models when using TCG. Do that by adding a tcg_default_props array that will work like kvm_default_props. Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 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>
-