- 31 10月, 2012 2 次提交
-
-
由 Eduardo Habkost 提交于
Cosmetic, but it will also help to make futher patches easier to review. Signed-off-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
-
由 Eduardo Habkost 提交于
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: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
-
- 29 10月, 2012 1 次提交
-
-
由 Michael S. Tsirkin 提交于
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: NMichael S. Tsirkin <mst@redhat.com>
-
- 28 10月, 2012 1 次提交
-
-
由 Eduardo Habkost 提交于
I removed a line by mistake on commit 3b671a40, containing the flags lm/i64, 3dnow, and 3dnowext. This patch restores the removed line. Reviewed-by: NDon Slutz <Don@cloudswitch.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>
-
- 05 10月, 2012 1 次提交
-
-
由 Peter Maydell 提交于
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: NPeter Maydell <peter.maydell@linaro.org>
-
- 01 10月, 2012 1 次提交
-
-
由 H. Peter Anvin 提交于
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: NH. Peter Anvin <hpa@linux.intel.com> Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
-
- 30 9月, 2012 3 次提交
-
-
由 Eduardo Habkost 提交于
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: NEduardo Habkost <ehabkost@redhat.com> Reviewed-by: NDon Slutz <Don@CloudSwitch.com> Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>
-
由 Eduardo Habkost 提交于
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: NEduardo Habkost <ehabkost@redhat.com> Reviewed-by: NDon Slutz <Don@CloudSwitch.com> Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>
-
由 Eduardo Habkost 提交于
Both constants have the same value, but CPUID_EXT2_AMD_ALIASES is defined without using magic numbers. Signed-off-by: NEduardo Habkost <ehabkost@redhat.com> Reviewed-by: NDon Slutz <Don@CloudSwitch.com> Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>
-
- 23 9月, 2012 1 次提交
-
-
由 Don Slutz 提交于
The check using INT_MAX (2147483647) is wrong in this case. Signed-off-by: NFred Oliveira <foliveira@cloudswitch.com> Signed-off-by: NDon Slutz <Don@CloudSwitch.com> Signed-off-by: NStefan Hajnoczi <stefanha@gmail.com>
-
- 21 9月, 2012 6 次提交
-
-
由 Andreas Färber 提交于
It was only used by now removed setfeatures() function. Suggested-by: NIgor Mammedov <imammedo@redhat.com> Signed-off-by: NAndreas Färber <afaerber@suse.de>
-
由 Eduardo Habkost 提交于
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: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NAndreas Färber <afaerber@suse.de>
-
由 Eduardo Habkost 提交于
Make source code lines shorter. Signed-off-by: NEduardo Habkost <ehabkost@redhat.com> Reviewed-by: NDon Slutz <Don@CloudSwitch.com> Signed-off-by: NAndreas Färber <afaerber@suse.de>
-
由 Eduardo Habkost 提交于
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: NEduardo Habkost <ehabkost@redhat.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NDon Slutz <Don@CloudSwitch.com> Signed-off-by: NAndreas Färber <afaerber@suse.de>
-
由 Peter Maydell 提交于
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: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com> Signed-off-by: NAndreas Färber <afaerber@suse.de>
-
由 Peter Maydell 提交于
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: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com> Signed-off-by: NAndreas Färber <afaerber@suse.de>
-
- 31 8月, 2012 1 次提交
-
-
由 Stefan Weil 提交于
Commit ef8621b1 added an include file which is not available for MinGW compilations. Signed-off-by: NStefan Weil <sw@weilnetz.de> Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
-
- 29 8月, 2012 1 次提交
-
-
由 Anthony Liguori 提交于
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: NAnthony Liguori <aliguori@us.ibm.com>
-
- 16 8月, 2012 1 次提交
-
-
由 Anthony Liguori 提交于
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: NAnthony Liguori <aliguori@us.ibm.com>
-
- 14 8月, 2012 1 次提交
-
-
由 Anthony Liguori 提交于
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com> Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
-
- 01 8月, 2012 2 次提交
-
-
由 Igor Mammedov 提交于
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: NIgor Mammedov <imammedo@redhat.com> Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
-
由 Igor Mammedov 提交于
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/100806Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
-
- 21 7月, 2012 1 次提交
-
-
由 Mao, Junjie 提交于
This patch makes Qemu recognize the PCID feature specified from configuration or command line options. Signed-off-by: NJunjie Mao <junjie.mao@intel.com> Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>
-
- 04 7月, 2012 1 次提交
-
-
由 Michael S. Tsirkin 提交于
Support the new PV EOI flag in kvm - it recently got merged into kvm.git. Set by default with -cpu kvm. Set for -cpu qemu by adding +kvm_pv_eoi. Clear by adding -kvm_pv_eoi to -cpu option. Signed-off-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
-
- 25 6月, 2012 1 次提交
-
-
由 Igor Mammedov 提交于
In order to make cpu object not depended on external ad-hoc initialization routines, move tcg initialization from cpu_x86_init inside cpu object "x86_cpu_initfn()". Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NAndreas Färber <afaerber@suse.de>
-
- 22 6月, 2012 1 次提交
-
-
由 Stefan Weil 提交于
This new 'QEmu' was recently added. Replace it by the official all upper case 'QEMU'. Signed-off-by: NStefan Weil <sw@weilnetz.de> Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>
-
- 20 6月, 2012 1 次提交
-
-
由 Crístian Viana 提交于
QEMU exposes its version to the guest's hardware and in some cases that is wrong (e.g. Windows prints messages about driver updates when you switch the QEMU version). There is a new field now on the struct QEmuMachine, hw_version, which may contain the version that the specific machine should report. If that field is set, then that machine will report that version to the guest. Signed-off-by: NCrístian Viana <vianac@linux.vnet.ibm.com> Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
-
- 08 6月, 2012 1 次提交
-
-
由 Andreas Färber 提交于
This simplifies the code and resolves TODOs. Signed-off-by: NAndreas Färber <afaerber@suse.de> Reviewed-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
- 30 5月, 2012 1 次提交
-
-
由 Eduardo Habkost 提交于
Changes v2 -> v3; - Check for kvm_enabled() before setting cpuid_7_0_ebx_features Changes v1 -> v2: - Use kvm_arch_get_supported_cpuid() instead of host_cpuid() on cpu_x86_fill_host(). We should use GET_SUPPORTED_CPUID for all bits on "-cpu host" eventually, but I am not changing all the other CPUID leaves because we may not be able to test such an intrusive change in time for 1.1. Description of the bug: Since QEMU 0.15, the CPUID information on CPUID[EAX=7,ECX=0] is being returned unfiltered to the guest, directly from the GET_SUPPORTED_CPUID return value. The problem is that this makes the resulting CPU feature flags unpredictable and dependent on the host CPU and kernel version. This breaks live-migration badly if migrating from a host CPU that supports some features on that CPUID leaf (running a recent kernel) to a kernel or host CPU that doesn't support it. Migration also is incorrect (the virtual CPU changes under the guest's feet) if you migrate in the opposite direction (from an old CPU/kernel to a new CPU/kernel), but with less serious consequences (guests normally query CPUID information only once on boot). Fortunately, the bug affects only users using cpudefs with level >= 7. The right behavior should be to explicitly enable those features on [cpudef] config sections or on the "-cpu" command-line arguments. Right now there is no predefined CPU model on QEMU that has those features: the latest Intel model we have is Sandy Bridge. I would like to get this fixed on 1.1, so I am submitting this patch, that enables those features only if "-cpu host" is being used (as we don't have any pre-defined CPU model that actually have those features). After 1.1 is released, we can make those features properly configurable on [cpudef] and -cpu configuration. One problem is: with this patch, users with the following setup: - Running QEMU 1.0; - Using a cpudef having level >= 7; - Running a kernel that supports the features on CPUID leaf 7; and - Running on a CPU that supports some features on CPUID leaf 7 won't be able to live-migrate to QEMU 1.1. But for these users live-migration is already broken (they can't live-migrate to hosts with older CPUs or older kernels, already), I don't see how to avoid this problem. Signed-off-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
-
- 12 5月, 2012 1 次提交
-
-
由 Andreas Färber 提交于
Commit de024815 (target-i386: QOM'ify CPU init) moved mce_init() call from helper.c:cpu_x86_init() into X86CPU's cpu.c:x86_cpu_initfn(). mce_init() checks for a family >= 6 though, so we could end up with a sequence such as for -cpu somecpu,family=6: x86_cpu_initfn => X86CPU::family == 5 mce_init => no-op cpu_x86_register => X86CPU::family = 6 => MCE unexpectedly not init'ed or for -cpu someothercpu,family=5: x86_cpu_initfn => X86CPU::family == 6 mce_init => init'ed cpu_x86_register => X86CPU::family = 5 => MCE unexpectedly init'ed Therefore partially revert the above commit. To avoid moving mce_init() back into helper.c, foresightedly move it into a new x86_cpu_realize() function and, in lack of ObjectClass::realize, call it directly from cpu_x86_init(). While at it, move the qemu_init_vcpu() call that used to follow mce_init() in cpu_x86_init() into the new realizefn as well. Reported-by: NIgor Mammedov <imammedo@redhat.com> Signed-off-by: NAndreas Färber <afaerber@suse.de> Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
-
- 27 4月, 2012 1 次提交
-
-
由 Andreas Färber 提交于
Don't assume zeroed cpuid_model[] fields. This didn't break anything yet but QOM properties should be able to set the value to something else without setting an intermediate zero string. Signed-off-by: NAndreas Färber <afaerber@suse.de> Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
-
- 25 4月, 2012 9 次提交
-
-
由 Andreas Färber 提交于
Use Hz as unit. Signed-off-by: NAndreas Färber <afaerber@suse.de> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
-
由 Andreas Färber 提交于
Using it now would incur converting the three x86_def_t vendor words into a string for object_property_set_str(), then back to three words in the "vendor" setter. The built-in CPU definitions use numeric preprocessor defines to initialize the three words in a charset-safe way, so do not change the fields to char[12] just to use the setter. Signed-off-by: NAndreas Färber <afaerber@suse.de> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
-
由 Andreas Färber 提交于
Signed-off-by: NAndreas Färber <afaerber@suse.de> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
-
由 Andreas Färber 提交于
Signed-off-by: NAndreas Färber <afaerber@suse.de> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
-
由 Andreas Färber 提交于
Signed-off-by: NAndreas Färber <afaerber@suse.de> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
-
由 Andreas Färber 提交于
Signed-off-by: NAndreas Färber <afaerber@suse.de> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
-
由 Andreas Färber 提交于
Signed-off-by: NAndreas Färber <afaerber@suse.de> Reviewed-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Andreas Färber 提交于
Signed-off-by: NAndreas Färber <afaerber@suse.de> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
-
由 Andreas Färber 提交于
Signed-off-by: NAndreas Färber <afaerber@suse.de> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
-