aboutsummaryrefslogtreecommitdiff
path: root/target/i386/kvm.c
AgeCommit message (Collapse)Author
2018-01-17i386: Add support for SPEC_CTRL MSRPaolo Bonzini
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20180109154519.25634-3-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2018-01-16irq: fix memory leaklinzhecheng
entry is moved from list but is not freed. Signed-off-by: linzhecheng <linzhecheng@huawei.com> Message-Id: <20171225024704.19540-1-linzhecheng@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-01-16target/i386: move hflags update code to a functionTao Wu
We will share the same code for hax/kvm. Signed-off-by: Tao Wu <lepton@google.com> Message-Id: <20180110195056.85403-1-lepton@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-01-12i386/cpu/kvm: look at PMU's CPUID before setting MSRsJan Dakinevich
Certain PMU-related MSRs are not supported for CPUs with PMU architecture below version 2. KVM rejects any access to them (see intel_is_valid_msr_idx routine in KVM), and QEMU fails on the following assertion: kvm_put_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. QEMU also could fail if KVM exposes less fixed counters then 3. It could happen if host system run inside another hypervisor, which is tweaking PMU-related CPUID. To prevent possible fail, number of fixed counters now is obtained in the same way as number of GP counters. Reviewed-by: Roman Kagan <rkagan@virtuozzo.com> Signed-off-by: Jan Dakinevich <jan.dakinevich@virtuozzo.com> Message-Id: <1514383466-7257-1-git-send-email-jan.dakinevich@virtuozzo.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-12-22i386: hvf: refactor event injection code for hvfSergio Andres Gomez Del Real
This patch refactors the event-injection code for hvf by using the appropriate fields already provided by CPUX86State. At vmexit, it fills these fields so that hvf_inject_interrupts can just retrieve them without calling into hvf. Signed-off-by: Sergio Andres Gomez Del Real <Sergio.G.DelReal@gmail.com> Message-Id: <20170913090522.4022-14-Sergio.G.DelReal@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-12-21hyperv: make SynIC version msr constantRoman Kagan
The value of HV_X64_MSR_SVERSION is initialized once at vcpu init, and is reset to zero on vcpu reset, which is wrong. It is supposed to be a constant, so drop the field from X86CPU, set the msr with the constant value, and don't bother getting it. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> Message-Id: <20171122181418.14180-4-rkagan@virtuozzo.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-12-21hyperv: ensure SINTx msrs are reset properlyRoman Kagan
Initially SINTx msrs should be in "masked" state. To ensure that happens on *every* reset, move setting their values to kvm_arch_vcpu_reset. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> Message-Id: <20171122181418.14180-3-rkagan@virtuozzo.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-12-21hyperv: set partition-wide MSRs only on first vcpuEvgeny Yakovlev
Hyper-V has a notion of partition-wide MSRs. Those MSRs are read and written as usual on each VCPU, however the hypervisor maintains a single global value for all VCPUs. Thus writing such an MSR from any single VCPU affects the global value that is read by all other VCPUs. This leads to an issue during VCPU hotplug: the zero-initialzied values of those MSRs get synced into KVM and override the global values as has already been set by the guest. This change makes the partition-wide MSRs only be synchronized on the first vcpu. Signed-off-by: Evgeny Yakovlev <eyakovlev@virtuozzo.com> Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> Message-Id: <20171122181418.14180-2-rkagan@virtuozzo.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-12-18Remove empty statementsLadi Prosek
Thanks to Laszlo Ersek for spotting the double semicolon in target/i386/kvm.c I have trivially grepped the tree for ';;' in C files. Suggested-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Ladi Prosek <lprosek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2017-09-19hyperv: add header with protocol definitionsRoman Kagan
The definitions for Hyper-V emulation are currently taken from a header imported from the Linux kernel. However, as these describe a third-party protocol rather than a kernel API, it probably wasn't a good idea to publish it in the kernel uapi. This patch introduces a header that provides all the necessary definitions, superseding the one coming from the kernel. The new header supports (temporary) coexistence with the kernel one. The constants explicitly named in the Hyper-V specification (e.g. msr numbers) are defined in a non-conflicting way. Other constants and types have got new names. While at this, the protocol data structures are defined in a more conventional way, without bitfields, enums, and excessive unions. The code using this stuff is adjusted, too; it can now be built both with and without the kernel header in the tree. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> Message-Id: <20170713201522.13765-2-rkagan@virtuozzo.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-09-19i386/cpu/hyperv: support over 64 vcpus for windows guestsGonglei
Starting with Windows Server 2012 and Windows 8, if CPUID.40000005.EAX contains a value of -1, Windows assumes specific limit to the number of VPs. In this case, Windows Server 2012 guest VMs may use more than 64 VPs, up to the maximum supported number of processors applicable to the specific Windows version being used. https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/reference/tlfs For compatibility, Let's introduce a new property for X86CPU, named "x-hv-max-vps" as Eduardo's suggestion, and set it to 0x40 before machine 2.10. (The "x-" prefix indicates that the property is not supposed to be a stable user interface.) Signed-off-by: Gonglei <arei.gonglei@huawei.com> Message-Id: <1505143227-14324-1-git-send-email-arei.gonglei@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-09-19i386/kvm: advertise Hyper-V frequency MSRsLadi Prosek
As of kernel commit eb82feea59d6 ("KVM: hyperv: support HV_X64_MSR_TSC_FREQUENCY and HV_X64_MSR_APIC_FREQUENCY"), KVM supports two new MSRs which are required for nested Hyper-V to read timestamps with RDTSC + TSC page. This commit makes QEMU advertise the MSRs with CPUID.40000003H:EAX[11] and CPUID.40000003H:EDX[8] as specified in the Hyper-V TLFS and experimentally verified on a Hyper-V host. The feature is enabled with the existing hv-time CPU flag, and only if the TSC frequency is stable across migrations and known. Signed-off-by: Ladi Prosek <lprosek@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Message-Id: <20170807085703.32267-5-lprosek@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-09-19i386/kvm: introduce tsc_is_stable_and_known()Ladi Prosek
Move the "is TSC stable and known" condition to a reusable helper. Signed-off-by: Ladi Prosek <lprosek@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Message-Id: <20170807085703.32267-4-lprosek@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-09-19i386/kvm: set tsc_khz before configuring Hyper-V CPUIDLadi Prosek
Timing-related Hyper-V enlightenments will benefit from knowing the final tsc_khz value. This commit just moves the code in preparation for further changes. Signed-off-by: Ladi Prosek <lprosek@redhat.com> Message-Id: <20170807085703.32267-3-lprosek@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-09-19i386/kvm: use a switch statement for MSR detectionLadi Prosek
Switch is easier on the eye and might lead to better codegen. Signed-off-by: Ladi Prosek <lprosek@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Message-Id: <20170807085703.32267-2-lprosek@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-08-01target-i386: kvm_get/put_vcpu_events don't handle sipi_vectorPeng Hao
qemu call kvm_get_vcpu_events, and kernel return sipi_vector always 0, never valid when reporting to user space. But when qemu calls kvm_put_vcpu_events will make sipi_vector in kernel be 0. This will accidently modify sipi_vector when sipi_vector in kernel is not 0. Signed-off-by: Peng Hao <peng.hao2@zte.com.cn> Reviewed-by: Liu Yi <liu.yi24@zte.com.cn> Message-Id: <1500047256-8911-1-git-send-email-peng.hao2@zte.com.cn> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-07-13Convert error_report() to warn_report()Alistair Francis
Convert all uses of error_report("warning:"... to use warn_report() instead. This helps standardise on a single method of printing warnings to the user. All of the warnings were changed using these two commands: find ./* -type f -exec sed -i \ 's|error_report(".*warning[,:] |warn_report("|Ig' {} + Indentation fixed up manually afterwards. The test-qdev-global-props test case was manually updated to ensure that this patch passes make check (as the test cases are case sensitive). Signed-off-by: Alistair Francis <alistair.francis@xilinx.com> Suggested-by: Thomas Huth <thuth@redhat.com> Cc: Jeff Cody <jcody@redhat.com> Cc: Kevin Wolf <kwolf@redhat.com> Cc: Max Reitz <mreitz@redhat.com> Cc: Ronnie Sahlberg <ronniesahlberg@gmail.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Peter Lieven <pl@kamp.de> Cc: Josh Durgin <jdurgin@redhat.com> Cc: "Richard W.M. Jones" <rjones@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Cc: Peter Crosthwaite <crosthwaite.peter@gmail.com> Cc: Richard Henderson <rth@twiddle.net> Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> Cc: Greg Kurz <groug@kaod.org> Cc: Rob Herring <robh@kernel.org> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Peter Chubb <peter.chubb@nicta.com.au> Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: David Gibson <david@gibson.dropbear.id.au> Cc: Alexander Graf <agraf@suse.de> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jason Wang <jasowang@redhat.com> Cc: Marcelo Tosatti <mtosatti@redhat.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: Cornelia Huck <cohuck@redhat.com> Cc: Stefan Hajnoczi <stefanha@redhat.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Acked-by: Greg Kurz <groug@kaod.org> Acked-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed by: Peter Chubb <peter.chubb@data61.csiro.au> Acked-by: Max Reitz <mreitz@redhat.com> Acked-by: Marcel Apfelbaum <marcel@redhat.com> Message-Id: <e1cfa2cd47087c248dd24caca9c33d9af0c499b0.1499866456.git.alistair.francis@xilinx.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2017-07-04xsave_helper: pull xsave and xrstor out of kvm.c into helper functionSergio Andres Gomez Del Real
This patch pulls out of kvm.c and into the new files the implementation for the xsave and xrstor instructions. This so they can be shared by kvm and hvf. Signed-off-by: Sergio Andres Gomez Del Real <Sergio.G.DelReal@gmail.com> Message-Id: <20170626200832.11058-1-Sergio.G.DelReal@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Sergio Andres Gomez Del Real <sergio.g.delreal@gmail.com>
2017-06-07kvm: don't register smram_listener when smm is offGonglei
If the user set disable smm by '-machine smm=off', we should not register smram_listener so that we can avoid waster memory in kvm since the added sencond address space. Meanwhile we should assign value of the global kvm_state before invoking the kvm_arch_init(), because pc_machine_is_smm_enabled() may use it by kvm_has_mm(). Signed-off-by: Gonglei <arei.gonglei@huawei.com> Message-Id: <1496316915-121196-1-git-send-email-arei.gonglei@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-06-07i386/kvm: do not zero out segment flags if segment is unusable or not presentRoman Pen
This is a fix for the problem [1], where VMCB.CPL was set to 0 and interrupt was taken on userspace stack. The root cause lies in the specific AMD CPU behaviour which manifests itself as unusable segment attributes on SYSRET[2]. Here in this patch flags are not touched even segment is unusable or is not present, therefore CPL (which is stored in DPL field) should not be lost and will be successfully restored on kvm/svm kernel side. Also current patch should not break desired behavior described in this commit: 4cae9c97967a ("target-i386: kvm: clear unusable segments' flags in migration") since present bit will be dropped if segment is unusable or is not present. This is the second part of the whole fix of the corresponding problem [1], first part is related to kvm/svm kernel side and does exactly the same: segment attributes are not zeroed out. [1] Message id: CAJrWOzD6Xq==b-zYCDdFLgSRMPM-NkNuTSDFEtX=7MreT45i7Q@mail.gmail.com [2] Message id: 5d120f358612d73fc909f5bfa47e7bd082db0af0.1429841474.git.luto@kernel.org Signed-off-by: Roman Pen <roman.penyaev@profitbricks.com> Signed-off-by: Mikhail Sennikovskii <mikhail.sennikovskii@profitbricks.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: Michael Chapman <mike@very.puzzling.org> Cc: qemu-devel@nongnu.org Message-Id: <20170601085604.12980-1-roman.penyaev@profitbricks.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-06-06kvm: irqchip: skip update msi when disabledPeter Xu
It's possible that one device kept its irqfd/virq there even when MSI/MSIX was disabled globally for that device. One example is virtio-net-pci (see commit f1d0f15a6 and virtio_pci_vq_vector_mask()). It is used as a fast path to avoid allocate/release irqfd/virq frequently when guest enables/disables MSIX. However, this fast path brought a problem to msi_route_list, that the device MSIRouteEntry is still dangling there even if MSIX disabled - then we cannot know which message to fetch, even if we can, the messages are meaningless. In this case, we can just simply ignore this entry. It's safe, since when MSIX is enabled again, we'll rebuild them no matter what. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1448813 Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <1494309644-18743-4-git-send-email-peterx@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-05-23shutdown: Add source information to SHUTDOWN and RESETEric Blake
Time to wire up all the call sites that request a shutdown or reset to use the enum added in the previous patch. It would have been less churn to keep the common case with no arguments as meaning guest-triggered, and only modified the host-triggered code paths, via a wrapper function, but then we'd still have to audit that I didn't miss any host-triggered spots; changing the signature forces us to double-check that I correctly categorized all callers. Since command line options can change whether a guest reset request causes an actual reset vs. a shutdown, it's easy to also add the information to reset requests. Signed-off-by: Eric Blake <eblake@redhat.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> [ppc parts] Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> [SPARC part] Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> [s390x parts] Message-Id: <20170515214114.15442-5-eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2017-05-17migration: Create migration/blocker.hJuan Quintela
This allows us to remove lots of includes of migration/migration.h Signed-off-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2017-03-14kvm: Print MSR information if KVM_{GET,SET}_MSRS failedEduardo Habkost
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-10i386/kvm: Blacklist TSX on known broken hostsEduardo Habkost
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-03x86: Work around SMI migration breakagesDr. David Alan Gilbert
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-03KVM: do not use sigtimedwait to catch SIGBUSPaolo Bonzini
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 Bonzini
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 Bonzini
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 Bonzini
This patch should have no semantic change. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-01-27x86-KVM: Supply TSC and APIC clock rates to guest like VMWarePhil Dennis-Jordan
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-24migration: disallow migrate_add_blocker during migrationAshijeet Acharya
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-23kvm: Allow invtsc migration if tsc-khz is set explicitlyEduardo Habkost
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 Habkost
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-19kvm: move cpu synchronization codeVincent Palatin
Move the generic cpu_synchronize_ functions to the common hw_accel.h header, in order to prepare for the addition of a second hardware accelerator. Signed-off-by: Stefan Weil <sw@weilnetz.de> Signed-off-by: Vincent Palatin <vpalatin@chromium.org> Message-Id: <f5c3cffe8d520011df1c2e5437bb814989b48332.1484045952.git.vpalatin@chromium.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-12-22kvmclock: reduce kvmclock difference on migrationMarcelo Tosatti
Check for KVM_CAP_ADJUST_CLOCK capability KVM_CLOCK_TSC_STABLE, which indicates that KVM_GET_CLOCK returns a value as seen by the guest at that moment. For new machine types, use this value rather than reading from guest memory. This reduces kvmclock difference on migration from 5s to 0.1s (when max_downtime == 5s). Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com> Message-Id: <20161121105052.598267440@redhat.com> [Add comment explaining what is going on. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-12-20Move target-* CPU file into a target/ folderThomas Huth
We've currently got 18 architectures in QEMU, and thus 18 target-xxx folders in the root folder of the QEMU source tree. More architectures (e.g. RISC-V, AVR) are likely to be included soon, too, so the main folder of the QEMU sources slowly gets quite overcrowded with the target-xxx folders. To disburden the main folder a little bit, let's move the target-xxx folders into a dedicated target/ folder, so that target-xxx/ simply becomes target/xxx/ instead. Acked-by: Laurent Vivier <laurent@vivier.eu> [m68k part] Acked-by: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> [tricore part] Acked-by: Michael Walle <michael@walle.cc> [lm32 part] Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> [s390x part] Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> [s390x part] Acked-by: Eduardo Habkost <ehabkost@redhat.com> [i386 part] Acked-by: Artyom Tarasenko <atar4qemu@gmail.com> [sparc part] Acked-by: Richard Henderson <rth@twiddle.net> [alpha part] Acked-by: Max Filippov <jcmvbkbc@gmail.com> [xtensa part] Reviewed-by: David Gibson <david@gibson.dropbear.id.au> [ppc part] Acked-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> [cris&microblaze part] Acked-by: Guan Xuetao <gxt@mprc.pku.edu.cn> [unicore32 part] Signed-off-by: Thomas Huth <thuth@redhat.com>
generated by cgit v1.2.3 (git 2.26.2) at 2025-02-06 18:56:17 +0000