summaryrefslogtreecommitdiff
path: root/target/i386
AgeCommit message (Collapse)AuthorFilesLines
2017-08-31qdev: Replace cannot_instantiate_with_device_add_yet with !user_creatableEduardo Habkost1-1/+1
cannot_instantiate_with_device_add_yet was introduced by commit efec3dd631d94160288392721a5f9c39e50fb2bc to replace no_user. It was supposed to be a temporary measure. When it was introduced, we had 54 cannot_instantiate_with_device_add_yet=true lines in the code. Today (3 years later) this number has not shrunk: we now have 57 cannot_instantiate_with_device_add_yet=true lines. I think it is safe to say it is not a temporary measure, and we won't see the flag go away soon. Instead of a long field name that misleads people to believe it is temporary, replace it a shorter and less misleading field: user_creatable. Except for code comments, changes were generated using the following Coccinelle patch: @@ expression DC; @@ ( -DC->cannot_instantiate_with_device_add_yet = false; +DC->user_creatable = true; | -DC->cannot_instantiate_with_device_add_yet = true; +DC->user_creatable = false; ) @@ typedef ObjectClass; expression dc; identifier class, data; @@ static void device_class_init(ObjectClass *class, void *data) { ... dc->hotpluggable = true; +dc->user_creatable = true; ... } @@ @@ struct DeviceClass { ... -bool cannot_instantiate_with_device_add_yet; +bool user_creatable; ... } @@ expression DC; @@ ( -!DC->cannot_instantiate_with_device_add_yet +DC->user_creatable | -DC->cannot_instantiate_with_device_add_yet +!DC->user_creatable ) Cc: Alistair Francis <alistair.francis@xilinx.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Thomas Huth <thuth@redhat.com> Acked-by: Alistair Francis <alistair.francis@xilinx.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Acked-by: Marcel Apfelbaum <marcel@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170503203604.31462-2-ehabkost@redhat.com> [ehabkost: kept "TODO remove once we're there" comment] Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> (cherry picked from commit e90f2a8c3e0e677eeea46a9b401c3f98425ffa37) Conflicts: include/hw/qdev-core.h * remove context dep on 08f00df Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-04-10target/i386/misc_helper: wrap BQL around another IRQ generatorAlex Bennée1-0/+3
Anything that calls into HW emulation must be protected by the BQL. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <rth@twiddle.net> Acked-by: Eduardo Habkost <ehabkost@redhat.com>
2017-04-02target-i386: fix "info lapic" segfault on isapcTejaswini Poluri1-0/+4
Start QEMU with "qemu-system-x86_64 -nographic -M isapc -serial none-monitor stdio" and enter "info lapic" at the monitor prompt ⇒ Segmentation fault Signed-off-by: Tejaswini Poluri <tejaswinipoluri3@gmail.com> Message-Id: <1490685583-16987-1-git-send-email-tejaswinipoluri3@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-03-31hmp: fix "dump-quest-memory" segfaultIwona Kotlarska1-2/+1
Running QEMU with "qemu-system-x86_64 -M none -nographic -m 256" and executing "dump-guest-memory /dev/null 0 8192" results in segfault. Fix by checking if we have CPU. Signed-off-by: Iwona Kotlarska <iwona260909@gmail.com> Message-Id: <20170330050924.22134-1-iwona260909@gmail.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Fixed up title
2017-03-28i386: Don't override -cpu options on -cpu host/maxEduardo Habkost2-4/+11
The existing code for "host" and "max" CPU models overrides every single feature in the CPU object at realize time, even the ones that were explicitly enabled or disabled by the user using "feat=on" or "feat=off", while features set using +feat/-feat are kept. This means "-cpu host,+invtsc" works as expected, while "-cpu host,invtsc=on" doesn't. This was a known bug, already documented in a comment inside x86_cpu_expand_features(). What makes this bug worse now is that libvirt 3.0.0 and newer now use "feat=on|off" instead of +feat/-feat when it detects a QEMU version that supports it (see libvirt commit d47db7b16dd5422c7e487c8c8ee5b181a2f9cd66). Change the feature property getter/setter to set a env->user_features field, to keep track of features that were explicitly changed using QOM properties. Then make the max_features code not override user features when handling "-cpu host" and "-cpu max". This will also allow us to remove the plus_features/minus_features hack in the future, but I plan to do that after 2.9.0 is released. Reported-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170327144815.8043-3-ehabkost@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Tested-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-03-28i386: Replace uint32_t* with FeatureWord on feature getter/setterEduardo Habkost1-8/+11
Instead of passing a pointer to the feature property getter and setter functions, pass a FeatureWord enum so they can perform other actions related to the feature flag. This will be used to add a new "user_features" field to keep track of features that were explicitly set by the user. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170327144815.8043-2-ehabkost@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Tested-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-03-24tcg/i386: Check the size of instruction being translatedPranith Kumar1-0/+7
This fixes the bug: 'user-to-root privesc inside VM via bad translation caching' reported by Jann Horn here: https://bugs.chromium.org/p/project-zero/issues/detail?id=1122 Reviewed-by: Richard Henderson <rth@twiddle.net> CC: Peter Maydell <peter.maydell@linaro.org> CC: Paolo Bonzini <pbonzini@redhat.com> Reported-by: Jann Horn <jannh@google.com> Signed-off-by: Pranith Kumar <bobby.prani@gmail.com> Message-Id: <20170323175851.14342-1-bobby.prani@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-03-14kvm: Print MSR information if KVM_{GET,SET}_MSRS failedEduardo Habkost1-0/+12
When a KVM_{GET,SET}_MSRS ioctl() fails, it is difficult to find out which MSR caused the problem. Print an error message for debugging, before we trigger the (ret == cpu->kvm_msr_buf->nmsrs) assert. Suggested-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170309194634.28457-1-ehabkost@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-03-13Merge remote-tracking branch 'remotes/ehabkost/tags/x86-pull-request' into ↵Peter Maydell3-1/+38
staging x86: Haswell TSX blacklist fix for 2.9 # gpg: Signature made Fri 10 Mar 2017 18:45:08 GMT # gpg: using RSA key 0x2807936F984DC5A6 # gpg: Good signature from "Eduardo Habkost <ehabkost@redhat.com>" # Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF D1AA 2807 936F 984D C5A6 * remotes/ehabkost/tags/x86-pull-request: i386: Change stepping of Haswell to non-blacklisted value i386/kvm: Blacklist TSX on known broken hosts i386: host_vendor_fms() helper function Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-03-10i386: Change stepping of Haswell to non-blacklisted valueEduardo Habkost1-1/+1
glibc blacklists TSX on Haswell CPUs with model==60 and stepping < 4. To make the Haswell CPU model more useful, make those guests actually use TSX by changing CPU stepping to 4. References: * glibc commit 2702856bf45c82cf8e69f2064f5aa15c0ceb6359 https://sourceware.org/git/?p=glibc.git;a=commit;h=2702856bf45c82cf8e69f2064f5aa15c0ceb6359 Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170309181212.18864-4-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-03-10i386/kvm: Blacklist TSX on known broken hostsEduardo Habkost1-0/+17
Some Intel CPUs are known to have a broken TSX implementation. A microcode update from Intel disabled TSX on those CPUs, but GET_SUPPORTED_CPUID might be reporting it as supported if the hosts were not updated yet. Manually fixup the GET_SUPPORTED_CPUID data to ensure we will never enable TSX when running on those hosts. Reference: * glibc commit 2702856bf45c82cf8e69f2064f5aa15c0ceb6359: https://sourceware.org/git/?p=glibc.git;a=commit;h=2702856bf45c82cf8e69f2064f5aa15c0ceb6359 Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170309181212.18864-3-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-03-10i386: host_vendor_fms() helper functionEduardo Habkost2-0/+20
Helper function for code that needs to check the host CPU vendor/family/model/stepping values. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170309181212.18864-2-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-03-09target-i386: defer VMEXIT to do_interruptPaolo Bonzini3-18/+26
Paths through the softmmu code during code generation now need to be audited to check for double locking of tb_lock. In particular, VMEXIT can take tb_lock through cpu_vmexit -> cpu_x86_update_cr4 -> tlb_flush. To avoid this, split VMEXIT delivery in two parts, similar to what is done with exceptions. cpu_vmexit only records the VMEXIT exit code and information, and cc->do_interrupt can then deliver it when it is safe to take the lock. Reported-by: Alexander Boettcher <alexander.boettcher@genode-labs.com> Suggested-by: Richard Henderson <rth@twiddle.net> Tested-by: Alexander Boettcher <alexander.boettcher@genode-labs.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <rth@twiddle.net>
2017-03-09target/i386/cpu.h: declare TCG_GUEST_DEFAULT_MOAlex Bennée1-0/+3
This suppresses the incorrect warning when forcing MTTCG for x86 guests on x86 hosts. A future patch will still warn when TARGET_SUPPORT_MTTCG hasn't been defined for the guest (which is still pending for x86). Reported-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <rth@twiddle.net> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Acked-by: Eduardo Habkost <ehabkost@redhat.com>
2017-03-03x86: Work around SMI migration breakagesDr. David Alan Gilbert3-1/+11
Migration from a 2.3.0 qemu results in a reboot on the receiving QEMU due to a disagreement about SM (System management) interrupts. 2.3.0 didn't have much SMI support, but it did set CPU_INTERRUPT_SMI and this gets into the migration stream, but on 2.3.0 it never got delivered. ~2.4.0 SMI interrupt support was added but was broken - so that when a 2.3.0 stream was received it cleared the CPU_INTERRUPT_SMI but never actually caused an interrupt. The SMI delivery was recently fixed by 68c6efe07a, but the effect now is that an incoming 2.3.0 stream takes the interrupt it had flagged but it's bios can't actually handle it(I think partly due to the original interrupt not being taken during boot?). The consequence is a triple(?) fault and a reboot. Tested from: 2.3.1 -M 2.3.0 2.7.0 -M 2.3.0 2.8.0 -M 2.3.0 2.8.0 -M 2.8.0 This corresponds to RH bugzilla entry 1420679. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20170223133441.16010-1-dgilbert@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-03-03qapi: flatten GuestPanicInformation unionAnton Nefedov1-9/+6
Signed-off-by: Anton Nefedov <anton.nefedov@virtuozzo.com> Signed-off-by: Denis V. Lunev <den@openvz.org> CC: Paolo Bonzini <pbonzini@redhat.com> CC: Eric Blake <eblake@redhat.com> Message-Id: <1487614915-18710-3-git-send-email-den@openvz.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-03-03KVM: do not use sigtimedwait to catch SIGBUSPaolo Bonzini1-3/+2
Call kvm_on_sigbus_vcpu asynchronously from the VCPU thread. Information for the SIGBUS can be stored in thread-local variables and processed later in kvm_cpu_exec. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-03-03KVM: remove kvm_arch_on_sigbusPaolo Bonzini1-35/+5
Build it on kvm_arch_on_sigbus_vcpu instead. They do the same for "action optional" SIGBUSes, and the main thread should never get "action required" SIGBUSes because it blocks the signal. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-03-03cpus: reorganize signal handling codePaolo Bonzini1-13/+2
Move the KVM "eat signals" code under CONFIG_LINUX, in preparation for moving it to kvm-all.c; reraise non-MCE SIGBUS immediately, without passing it to KVM. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-03-03KVM: x86: cleanup SIGBUS handlersPaolo Bonzini1-39/+42
This patch should have no semantic change. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-03-02Merge remote-tracking branch 'remotes/ehabkost/tags/x86-pull-request' into ↵Peter Maydell3-80/+385
staging x86 queue, 2017-02-27 "-cpu max" and query-cpu-model-expansion support for x86. This should be the last x86 pull request before 2.9 soft freeze. # gpg: Signature made Mon 27 Feb 2017 16:24:15 GMT # gpg: using RSA key 0x2807936F984DC5A6 # gpg: Good signature from "Eduardo Habkost <ehabkost@redhat.com>" # Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF D1AA 2807 936F 984D C5A6 * remotes/ehabkost/tags/x86-pull-request: i386: Improve query-cpu-model-expansion full mode i386: Implement query-cpu-model-expansion QMP command i386: Define static "base" CPU model i386: Don't set CPUClass::cpu_def on "max" model i386: Make "max" model not use any host CPUID info on TCG i386: Create "max" CPU model qapi-schema: Comment about full expansion of non-migration-safe models i386: Reorganize and document CPUID initialization steps i386: Rename X86CPU::host_features to X86CPU::max_features i386: Add ordering field to CPUClass i386: Unset cannot_destroy_with_object_finalize_yet on "host" model Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-02-27linux-user: Add signal handling support for x86_64Pranith Kumar2-0/+14
Note that x86_64 has only _rt signal handlers. This implementation attempts to share code with the x86_32 implementation. CC: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Allan Wirth <awirth@akamai.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Pranith Kumar <bobby.prani@gmail.com> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20170226165345.8757-1-bobby.prani@gmail.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2017-02-27i386: Improve query-cpu-model-expansion full modeEduardo Habkost1-3/+31
This keeps the same results on type=static expansion, but make type=full expansion return every single QOM property on the CPU object that have a different value from the "base' CPU model, plus all the CPU feature flag properties. Cc: Jiri Denemark <jdenemar@redhat.com> Message-Id: <20170222190029.17243-4-ehabkost@redhat.com> Tested-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-02-27i386: Implement query-cpu-model-expansion QMP commandEduardo Habkost1-1/+190
Implement query-cpu-model-expansion for target-i386. This should meet all the requirements while being simple. In the case of static expansion, it will use the new "base" CPU model, and in the case of full expansion, it will keep the original CPU model name+props, and append extra properties. A future follow-up should improve the implementation of type=full, so that it returns more detailed data, including every writable QOM property in the CPU object. Cc: libvir-list@redhat.com Cc: Jiri Denemark <jdenemar@redhat.com> Message-Id: <20170222190029.17243-3-ehabkost@redhat.com> Tested-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-02-27i386: Define static "base" CPU modelEduardo Habkost2-0/+22
The query-cpu-model-expand QMP command needs at least one static model, to allow the "static" expansion mode to be implemented. Instead of defining static versions of every CPU model, define a "base" CPU model that has absolutely no feature flag enabled. Despite having no CPUID data set at all, "-cpu base" is even a functional CPU: * It can boot a Slackware Linux 1.01 image with a Linux 0.99.12 kernel[1]. * It is even possible to boot[2] a modern Fedora x86_64 guest by manually enabling the following CPU features: -cpu base,+lm,+msr,+pae,+fpu,+cx8,+cmov,+sse,+sse2,+fxsr [1] http://www.qemu-advent-calendar.org/2014/#day-1 [2] This is what can be seen in the guest: [root@localhost ~]# cat /proc/cpuinfo processor : 0 vendor_id : unknown cpu family : 0 model : 0 model name : 00/00 stepping : 0 physical id : 0 siblings : 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu msr pae cx8 cmov fxsr sse sse2 lm nopl bugs : bogomips : 5832.70 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: [root@localhost ~]# x86info -v -a x86info v1.30. Dave Jones 2001-2011 Feedback to <davej@redhat.com>. No TSC, MHz calculation cannot be performed. Unknown vendor (0) MP Table: Family: 0 Model: 0 Stepping: 0 CPU Model (x86info's best guess): eax in: 0x00000000, eax = 00000001 ebx = 00000000 ecx = 00000000 edx = 00000000 eax in: 0x00000001, eax = 00000000 ebx = 00000800 ecx = 00000000 edx = 07008161 eax in: 0x80000000, eax = 80000001 ebx = 00000000 ecx = 00000000 edx = 00000000 eax in: 0x80000001, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 20000000 Feature flags: fpu Onboard FPU msr Model-Specific Registers pae Physical Address Extensions cx8 CMPXCHG8 instruction cmov CMOV instruction fxsr FXSAVE and FXRSTOR instructions sse SSE support sse2 SSE2 support Long NOPs supported: yes Address sizes : 0 bits physical, 0 bits virtual 0MHz processor (estimate). running at an estimated 0MHz [root@localhost ~]# Message-Id: <20170222190029.17243-2-ehabkost@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Tested-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-02-27i386: Don't set CPUClass::cpu_def on "max" modelEduardo Habkost2-25/+24
Host CPUID info is used by the "max" CPU model only in KVM mode. Move the initialization of CPUID data for "max" from class_init to instance_init, and don't set CPUClass::cpu_def for "max". Message-Id: <20170222183919.11928-4-ehabkost@redhat.com> Tested-by: Richard W.M. Jones <rjones@redhat.com> Tested-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-02-27i386: Make "max" model not use any host CPUID info on TCGEduardo Habkost1-0/+9
Instead of reporting host CPUID data on "max", use the qemu64 CPU model as reference to initialize CPUID vendor/family/model/stepping/model-id. Message-Id: <20170222183919.11928-3-ehabkost@redhat.com> Tested-by: Richard W.M. Jones <rjones@redhat.com> Tested-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-02-27i386: Create "max" CPU modelEduardo Habkost1-14/+32
Rename the existing "host" CPU model to "max, and set it to kvm_enabled=false. The new "max" CPU model will be able to enable all features supported by TCG out of the box, because its logic is based on x86_cpu_get_supported_feature_word(), which already works with TCG. A new KVM-specific "host" class was added, that simply inherits everything from "max" except the 'ordering' and 'description' fields. Message-Id: <20170222183919.11928-2-ehabkost@redhat.com> Tested-by: Richard W.M. Jones <rjones@redhat.com> Tested-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-02-27i386: Reorganize and document CPUID initialization stepsEduardo Habkost1-31/+71
CPU runnability checks and CPU model expansion have slightly different requirements. Document the steps involved in loading a CPU model and realizing a CPU, so their requirements and purpose are clearly defined. This patch doesn't change any implementation. It just add comments, rename the x86_cpu_load_features() function for clarity (so it won't be confused with x86_cpu_load_def()), and move x86_cpu_filter_features() closer to it. Message-Id: <20170116211124.29245-2-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-02-27i386: Rename X86CPU::host_features to X86CPU::max_featuresEduardo Habkost2-4/+4
Rename the field and add a small comment to make its purpose clearer. Message-Id: <20170119210449.11991-4-ehabkost@redhat.com> Tested-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-02-27i386: Add ordering field to CPUClassEduardo Habkost2-4/+6
Instead of using kvm_enabled to order the "-cpu help" list, use a new "ordering" field for that. Message-Id: <20170119210449.11991-3-ehabkost@redhat.com> Tested-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-02-27i386: Unset cannot_destroy_with_object_finalize_yet on "host" modelEduardo Habkost1-2/+0
The class is now safe because the assert(kvm_enabled()) line was removed by commit e435601058e656e6d24e3e87b187e5518f7bf16a. Message-Id: <20170119210449.11991-2-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-02-25Merge remote-tracking branch 'remotes/stsquad/tags/pull-mttcg-240217-1' into ↵Peter Maydell1-0/+7
staging This is the MTTCG pull-request as posted yesterday. # gpg: Signature made Fri 24 Feb 2017 11:17:51 GMT # gpg: using RSA key 0xFBD0DB095A9E2A44 # gpg: Good signature from "Alex Bennée (Master Work Key) <alex.bennee@linaro.org>" # Primary key fingerprint: 6685 AE99 E751 67BC AFC8 DF35 FBD0 DB09 5A9E 2A44 * remotes/stsquad/tags/pull-mttcg-240217-1: (24 commits) tcg: enable MTTCG by default for ARM on x86 hosts hw/misc/imx6_src: defer clearing of SRC_SCR reset bits target-arm: ensure all cross vCPUs TLB flushes complete target-arm: don't generate WFE/YIELD calls for MTTCG target-arm/powerctl: defer cpu reset work to CPU context cputlb: introduce tlb_flush_*_all_cpus[_synced] cputlb: atomically update tlb fields used by tlb_reset_dirty cputlb: add tlb_flush_by_mmuidx async routines cputlb and arm/sparc targets: convert mmuidx flushes from varg to bitmap cputlb: introduce tlb_flush_* async work. cputlb: tweak qemu_ram_addr_from_host_nofail reporting cputlb: add assert_cpu_is_self checks tcg: handle EXCP_ATOMIC exception for system emulation tcg: enable thread-per-vCPU tcg: enable tb_lock() for SoftMMU tcg: remove global exit_request tcg: drop global lock during TCG code execution tcg: rename tcg_current_cpu to tcg_current_rr_cpu tcg: add kick timer for single-threaded vCPU emulation tcg: add options for enabling MTTCG ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-02-24tcg: drop global lock during TCG code executionJan Kiszka1-0/+7
This finally allows TCG to benefit from the iothread introduction: Drop the global mutex while running pure TCG CPU code. Reacquire the lock when entering MMIO or PIO emulation, or when leaving the TCG loop. We have to revert a few optimization for the current TCG threading model, namely kicking the TCG thread in qemu_mutex_lock_iothread and not kicking it in qemu_cpu_kick. We also need to disable RAM block reordering until we have a more efficient locking mechanism at hand. Still, a Linux x86 UP guest and my Musicpal ARM model boot fine here. These numbers demonstrate where we gain something: 20338 jan 20 0 331m 75m 6904 R 99 0.9 0:50.95 qemu-system-arm 20337 jan 20 0 331m 75m 6904 S 20 0.9 0:26.50 qemu-system-arm The guest CPU was fully loaded, but the iothread could still run mostly independent on a second core. Without the patch we don't get beyond 32206 jan 20 0 330m 73m 7036 R 82 0.9 1:06.00 qemu-system-arm 32204 jan 20 0 330m 73m 7036 S 21 0.9 0:17.03 qemu-system-arm We don't benefit significantly, though, when the guest is not fully loading a host CPU. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Message-Id: <1439220437-23957-10-git-send-email-fred.konrad@greensocs.com> [FK: Rebase, fix qemu_devices_reset deadlock, rm address_space_* mutex] Signed-off-by: KONRAD Frederic <fred.konrad@greensocs.com> [EGC: fixed iothread lock for cpu-exec IRQ handling] Signed-off-by: Emilio G. Cota <cota@braap.org> [AJB: -smp single-threaded fix, clean commit msg, BQL fixes] Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <rth@twiddle.net> Reviewed-by: Pranith Kumar <bobby.prani@gmail.com> [PM: target-arm changes] Acked-by: Peter Maydell <peter.maydell@linaro.org>
2017-02-23util/cutils: Change qemu_strtosz*() from int64_t to uint64_tMarkus Armbruster1-2/+2
This will permit its use in parse_option_size(). Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Cc: Eduardo Habkost <ehabkost@redhat.com> (maintainer:X86) Cc: Kevin Wolf <kwolf@redhat.com> (supporter:Block layer core) Cc: Max Reitz <mreitz@redhat.com> (supporter:Block layer core) Cc: qemu-block@nongnu.org (open list:Block layer core) Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <1487708048-2131-24-git-send-email-armbru@redhat.com>
2017-02-23util/cutils: Return qemu_strtosz*() error and value separatelyMarkus Armbruster1-2/+3
This makes qemu_strtosz(), qemu_strtosz_mebi() and qemu_strtosz_metric() similar to qemu_strtoi64(), except negative values are rejected. Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Cc: Eduardo Habkost <ehabkost@redhat.com> (maintainer:X86) Cc: Kevin Wolf <kwolf@redhat.com> (supporter:Block layer core) Cc: Max Reitz <mreitz@redhat.com> (supporter:Block layer core) Cc: qemu-block@nongnu.org (open list:Block layer core) Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <1487708048-2131-23-git-send-email-armbru@redhat.com>
2017-02-23util/cutils: Let qemu_strtosz*() optionally reject trailing crapMarkus Armbruster1-3/+2
Change the qemu_strtosz() & friends to return -EINVAL when @endptr is null and the conversion doesn't consume the string completely. Matches how qemu_strtol() & friends work. Only test_qemu_strtosz_simple() passes a null @endptr. No functional change there, because its conversion consumes the string. Simplify callers that use @endptr only to fail when it doesn't point to '\0' to pass a null @endptr instead. Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Cc: Eduardo Habkost <ehabkost@redhat.com> (maintainer:X86) Cc: Kevin Wolf <kwolf@redhat.com> (supporter:Block layer core) Cc: Max Reitz <mreitz@redhat.com> (supporter:Block layer core) Cc: qemu-block@nongnu.org (open list:Block layer core) Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <1487708048-2131-22-git-send-email-armbru@redhat.com>
2017-02-23util/cutils: New qemu_strtosz_metric()Markus Armbruster1-2/+1
To parse numbers with metric suffixes, we use qemu_strtosz_suffix_unit(nptr, &eptr, QEMU_STRTOSZ_DEFSUFFIX_B, 1000) Capture this in a new function for legibility: qemu_strtosz_metric(nptr, &eptr) Replace test_qemu_strtosz_suffix_unit() by test_qemu_strtosz_metric(). Rename qemu_strtosz_suffix_unit() to do_strtosz() and give it internal linkage. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <1487708048-2131-15-git-send-email-armbru@redhat.com>
2017-02-21monitor: Fix crashes when using HMP commands without CPUThomas Huth1-1/+15
When running certain HMP commands ("info registers", "info cpustats", "info tlb", "nmi", "memsave" or dumping virtual memory) with the "none" machine, QEMU crashes with a segmentation fault. This happens because the "none" machine does not have any CPUs by default, but these HMP commands did not check for a valid CPU pointer yet. Add such checks now, so we get an error message about the missing CPU instead. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <1484309555-1935-1-git-send-email-thuth@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2017-02-16target-i386: correctly propagate retaddr into SVM helpersPaolo Bonzini6-57/+55
Commit 2afbdf8 ("target-i386: exception handling for memory helpers", 2015-09-15) changed tlb_fill's cpu_restore_state+raise_exception_err to raise_exception_err_ra. After this change, the cpu_restore_state and raise_exception_err's cpu_loop_exit are merged into raise_exception_err_ra's cpu_loop_exit_restore. This actually fixed some bugs, but when SVM is enabled there is a second path from raise_exception_err_ra to cpu_loop_exit. This is the VMEXIT path, and now cpu_vmexit is called without a cpu_restore_state before. The fix is to pass the retaddr to cpu_vmexit (via cpu_svm_check_intercept_param). All helpers can now use GETPC() to pass the correct retaddr, too. Cc: qemu-stable@nongnu.org Fixes: 2afbdf84807d673eb682cb78158e11cdacbf4673 Reported-by: Alexander Boettcher <alexander.boettcher@genode-labs.com> Tested-by: Alexander Boettcher <alexander.boettcher@genode-labs.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-02-16report guest crash information in GUEST_PANICKED eventAnton Nefedov1-0/+1
it's not very convenient to use the crash-information property interface, so provide a CPU class callback to get the guest crash information, and pass that information in the event Signed-off-by: Anton Nefedov <anton.nefedov@virtuozzo.com> Signed-off-by: Denis V. Lunev <den@openvz.org> Message-Id: <1487053524-18674-3-git-send-email-den@openvz.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-02-16i386/cpu: add crash-information QOM propertyAnton Nefedov1-0/+50
Windows reports BSOD parameters through Hyper-V crash MSRs. This information is very useful for initial crash analysis and thus it would be nice to have a way to fetch it. Signed-off-by: Anton Nefedov <anton.nefedov@virtuozzo.com> Signed-off-by: Denis V. Lunev <den@openvz.org> Message-Id: <1487053524-18674-2-git-send-email-den@openvz.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-01-27pc: Enable vmware-cpuid-freq CPU option for 2.9+ machine typesPhil Dennis-Jordan1-1/+1
Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu> Message-Id: <1484921496-11257-4-git-send-email-phil@philjordan.eu> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-01-27x86-KVM: Supply TSC and APIC clock rates to guest like VMWarePhil Dennis-Jordan3-6/+35
This fixes timekeeping of x86-64 Darwin/OS X/macOS guests when using KVM. Darwin/OS X/macOS for x86-64 uses the TSC for timekeeping; it normally calibrates this by querying various clock frequency scaling MSRs. Details depend on the exact CPU model detected. The local APIC timer frequency is extracted from (EFI) firmware. This is problematic in the presence of virtualisation, as the MSRs in question are typically not handled by the hypervisor. VMWare (Fusion) advertises TSC and APIC frequency via a custom 0x40000010 CPUID leaf, in the eax and ebx registers respectively. This is documented at https://lwn.net/Articles/301888/ among other places. Darwin/OS X/macOS looks for the generic 0x40000000 hypervisor leaf, and if this indicates via eax that leaf 0x40000010 might be available, that is in turn queried for the two frequencies. This adds a CPU option "vmware-cpuid-freq" to enable the same behaviour when running Qemu with KVM acceleration, if the KVM TSC frequency can be determined, and it is stable. (invtsc or user-specified) The virtualised APIC bus cycle is hardcoded to 1GHz in KVM, so ebx of the CPUID leaf is also hardcoded to this value. Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu> Message-Id: <1484921496-11257-2-git-send-email-phil@philjordan.eu> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-01-27replay: improve interrupt handlingPavel Dovgalyuk1-0/+1
This patch improves interrupt handling in record/replay mode. Now "interrupt" event is saved only when cc->cpu_exec_interrupt returns true. This patch also adds missing return to cpu_exec_interrupt function. Signed-off-by: Pavel Dovgalyuk <pavel.dovgaluk@ispras.ru> Message-Id: <20170124071708.4572.64023.stgit@PASHA-ISP> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-01-24migration: disallow migrate_add_blocker during migrationAshijeet Acharya1-3/+13
If a migration is already in progress and somebody attempts to add a migration blocker, this should rightly fail. Add an errp parameter and a retcode return value to migrate_add_blocker. Signed-off-by: John Snow <jsnow@redhat.com> Signed-off-by: Ashijeet Acharya <ashijeetacharya@gmail.com> Message-Id: <1484566314-3987-5-git-send-email-ashijeetacharya@gmail.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Acked-by: Greg Kurz <groug@kaod.org> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Merged with recent 'Allow invtsc migration' change
2017-01-24migration: extend VMStateInfoJianjun Duan1-7/+19
Current migration code cannot handle some data structures such as QTAILQ in qemu/queue.h. Here we extend the signatures of put/get in VMStateInfo so that customized handling is supported. put now will return int type. Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Jianjun Duan <duanj@linux.vnet.ibm.com> Message-Id: <1484852453-12728-2-git-send-email-duanj@linux.vnet.ibm.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2017-01-23kvm: Allow invtsc migration if tsc-khz is set explicitlyEduardo Habkost1-9/+11
We can safely allow a VM to be migrated with invtsc enabled if tsc-khz is set explicitly, because: * QEMU already refuses to start if it can't set the TSC frequency to the configured value. * Management software is already required to keep device configuration (including CPU configuration) the same on migration source and destination. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170108173234.25721-3-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-01-23kvm: Simplify invtsc checkEduardo Habkost1-2/+2
Instead of searching the table we have just built, we can check the env->features field directly. Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170108173234.25721-2-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-01-23i386: Return migration-safe field on query-cpu-definitionsEduardo Habkost2-0/+5
Return the migration-safe field on query-cpu-definitions. All CPU models in x86 are migration-safe except "host". Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170116181212.31565-1-ehabkost@redhat.com> Acked-by: David Hildenbrand <david@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
generated by cgit v1.2.1 (git 2.18.0) at 2024-06-25 06:07:21 +0000