summaryrefslogtreecommitdiff
path: root/target-i386
AgeCommit message (Collapse)AuthorFilesLines
2016-10-04hmp: fix qemu crash due to ioapic state dump w/ split irqchipWanpeng Li1-1/+2
The qemu will crash when info ioapic through hmp if irqchip is split. Below message is splat: KVM_GET_IRQCHIP failed: Unknown error -6 This patch fix it by dumping the ioapic state from the qemu emulated ioapic if irqchip is split. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com> Message-Id: <1474602456-3232-1-git-send-email-wanpeng.li@hotmail.com> Reviewed-by: Peter Xu <peterx@redhat.com> Message-ID: <20160923090824.GF15411@pxdev.xzpeter.org> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2016-10-03target-i386: Correct family/model/stepping for Opteron_G3Evgeny Yakovlev1-3/+3
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: Evgeny Yakovlev <eyakovlev@virtuozzo.com> Signed-off-by: Denis 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: Eduardo Habkost <ehabkost@redhat.com>
2016-10-03target-i386: Report known CPUID[EAX=0xD,ECX=0]:EAX bits as migratableEduardo Habkost1-8/+11
A regression was introduced by commit 96193c22a "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: Wanpeng Li <wanpeng.li@hotmail.com> Cc: Paolo Bonzini <bonzini@gnu.org> Reviewed-by: Wanpeng Li <wanpeng.li@hotmail.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-09-28Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into stagingPeter Maydell2-15/+10
* thread-safe tb_flush (Fred, Alex, Sergey, me, Richard, Emilio,... :-) * license clarification for compiler.h (Felipe) * glib cflags improvement (Marc-André) * checkpatch silencing (Paolo) * SMRAM migration fix (Paolo) * Replay improvements (Pavel) * IOMMU notifier improvements (Peter) * IOAPIC now defaults to version 0x20 (Peter) # gpg: Signature made Tue 27 Sep 2016 10:57:40 BST # gpg: using RSA key 0xBFFBD25F78C7AE83 # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" # gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1 # Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83 * remotes/bonzini/tags/for-upstream: (28 commits) replay: allow replay stopping and restarting replay: vmstate for replay module replay: move internal data to the structure cpus-common: lock-free fast path for cpu_exec_start/end tcg: Make tb_flush() thread safe cpus-common: Introduce async_safe_run_on_cpu() cpus-common: simplify locking for start_exclusive/end_exclusive cpus-common: remove redundant call to exclusive_idle() cpus-common: always defer async_run_on_cpu work items docs: include formal model for TCG exclusive sections cpus-common: move exclusive work infrastructure from linux-user cpus-common: fix uninitialized variable use in run_on_cpu cpus-common: move CPU work item management to common code cpus-common: move CPU list management to common code linux-user: Add qemu_cpu_is_self() and qemu_cpu_kick() linux-user: Use QemuMutex and QemuCond cpus: Rename flush_queued_work() cpus: Move common code out of {async_, }run_on_cpu() cpus: pass CPUState to run_on_cpu helpers build-sys: put glib_cflags in QEMU_CFLAGS ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-09-27target-i386: Remove has_msr_* global vars for KVM featuresEduardo Habkost1-15/+6
The global variables are not necessary because we can check KVM feature flags in X86CPU directly. Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-09-27target-i386: Clear KVM CPUID features if KVM is disabledEduardo Habkost1-0/+4
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: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-09-27target-i386: Remove has_msr_hv_tsc global variableEduardo Habkost1-6/+8
The global variable is not necessary because we can check cpu->hyperv_time directly. We just need to ensure cpu->hyperv_time will be cleared if the feature is not really being exposed to the guest due to missing KVM_CAP_HYPERV_TIME capability. Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-09-27target-i386: Remove has_msr_hv_apic global variableEduardo Habkost1-5/+3
The global variable is not necessary because we can check cpu->hyperv_vapic directly. Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-09-27target-i386: Remove has_msr_mtrr global variableEduardo Habkost1-6/+2
The global variable is not necessary because we can check the CPU feature flags directly. Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-09-27target-i386: Move xsave component mask to features arrayEduardo Habkost2-15/+30
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: Richard Henderson <rth@twiddle.net> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-09-27target-i386: xsave: Calculate set of xsave components on realizeEduardo Habkost2-23/+33
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: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Richard Henderson <rth@twiddle.net> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-09-27target-i386: xsave: Helper function to calculate xsave area sizeEduardo Habkost1-7/+15
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: Richard Henderson <rth@twiddle.net> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-09-27target-i386: xsave: Simplify CPUID[0xD,0].{EAX,EDX} calculationEduardo Habkost1-6/+2
Instead of assigning individual bits in a loop, just copy the values from ena_mask. Reviewed-by: Richard Henderson <rth@twiddle.net> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-09-27target-i386: xsave: Calculate enabled components only onceEduardo Habkost1-10/+16
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: Richard Henderson <rth@twiddle.net> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-09-27target-i386: Don't try to enable PT State xsave componentEduardo Habkost1-3/+3
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: Richard Henderson <rth@twiddle.net> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-09-27target-i386: Move feature name arrays inside FeatureWordInfoEduardo Habkost1-200/+170
It makes it easier to guarantee the arrays are the right size, and to find information when looking at the code. Reviewed-by: Richard Henderson <rth@twiddle.net> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-09-27linux-user: remove #define smp_{cores, threads}Marc-André Lureau1-4/+4
Those are unneeded now that CPUState nr_{cores,threads} is always initialized. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-09-27target-i386: Enable CPUID[0x8000000A] if SVM is enabledEduardo Habkost1-0/+4
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: Richard Henderson <rth@twiddle.net> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-09-27target-i386: Automatically set level/xlevel/xlevel2 when neededEduardo Habkost2-13/+83
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: Richard Henderson <rth@twiddle.net> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-09-27target-i386: Add a marker to end of the region zeroed on resetEduardo Habkost2-1/+2
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: Richard Henderson <rth@twiddle.net> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-09-27target-i386: Remove unused X86CPUDefinition::xlevel2 fieldEduardo Habkost1-2/+0
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: Richard Henderson <rth@twiddle.net> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-09-27cpus: pass CPUState to run_on_cpu helpersAlex Bennée2-15/+10
CPUState is a fairly common pointer to pass to these helpers. This means if you need other arguments for the async_run_on_cpu case you end up having to do a g_malloc to stuff additional data into the routine. For the current users this isn't a massive deal but for MTTCG this gets cumbersome when the only other parameter is often an address. This adds the typedef run_on_cpu_func for helper functions which has an explicit CPUState * passed as the first parameter. All the users of run_on_cpu and async_run_on_cpu have had their helpers updated to use CPUState where available. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> [Sergey Fedorov: - eliminate more CPUState in user data; - remove unnecessary user data passing; - fix target-s390x/kvm.c and target-s390x/misc_helper.c] Signed-off-by: Sergey Fedorov <sergey.fedorov@linaro.org> Acked-by: David Gibson <david@gibson.dropbear.id.au> (ppc parts) Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> (s390 parts) Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <1470158864-17651-3-git-send-email-alex.bennee@linaro.org> Reviewed-by: Richard Henderson <rth@twiddle.net> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-09-22kvm: fix events.flags (KVM_VCPUEVENT_VALID_SMM) overwritten by 0Herongguang (Stephen)1-1/+1
Fix events.flags (KVM_VCPUEVENT_VALID_SMM) overwritten by 0. Signed-off-by: He Rongguang <herongguang.he@huawei.com> Message-Id: <57E38EAC.3020108@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-09-22kvm: apic: set APIC base as part of kvm_apic_putDr. David Alan Gilbert2-0/+10
The parsing of KVM_SET_LAPIC's input depends on the current value of the APIC base MSR---which indeed is stored in APICCommonState---but for historical reasons APIC base is set through KVM_SET_SREGS together with cr8 (which is really just the APIC TPR) and the actual "special CPU registers". APIC base must now be set before the actual LAPIC registers, so do that in kvm_apic_put. It will be set again to the same value with KVM_SET_SREGS, but that's not a big issue. This only happens since Linux 4.8, which checks for x2apic mode in KVM_SET_LAPIC. However it's really a QEMU bug; until the recent commit 78d6a05 ("x86/lapic: Load LAPIC state at post_load", 2016-09-13) QEMU was indeed setting APIC base (via KVM_SET_SREGS) before the other LAPIC registers. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-09-22target-i386: introduce kvm_put_one_msrPaolo Bonzini1-9/+11
Avoid further code duplication in the next patch. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-09-19target-i386: Use struct X86XSaveArea in fpu_helper.cRichard Henderson3-58/+67
This avoids a double hand-full of magic numbers in the xsave and xrstor helper functions. Signed-off-by: Richard Henderson <rth@twiddle.net> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-09-16target-i386: Generate fences for x86Pranith Kumar1-0/+8
Signed-off-by: Pranith Kumar <bobby.prani@gmail.com> Message-Id: <20160714202026.9727-15-bobby.prani@gmail.com> Signed-off-by: Richard Henderson <rth@twiddle.net>
2016-09-14target-i386: Fixed syscall posssible segfaultStanislav Shmarov1-17/+19
In user-mode emulation env->idt.base memory is allocated in linux-user/main.c with size 8*512 = 4096 (for 64-bit). When fake interrupt EXCP_SYSCALL is thrown do_interrupt_user checks destination privilege level for this fake exception, and tries to read 4 bytes at address base + (256 * 2^4)=4096, that causes segfault. Privlege level was checked only for int's, so lets read dpl from memory only for this case. Signed-off-by: Stanislav Shmarov <snarpix@gmail.com> Message-Id: <1473773008-2588376-1-git-send-email-snarpix@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-09-14target-i386: fix ordering of fields in CPUX86StatePaolo Bonzini1-6/+6
Make sure reset zeroes TSC_AUX, XCR0, PKRU. Move XSTATE_BV from the "vmstate only" section to the "KVM only" section. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-09-13x86/lapic: Load LAPIC state at post_loadDr. David Alan Gilbert1-17/+0
Load the LAPIC state during post_load (rather than when the CPU starts). This allows an interrupt to be delivered from the ioapic to the lapic prior to cpu loading, in particular the RTC that starts ticking as soon as we load it's state. Fixes a case where Windows hangs after migration due to RTC interrupts disappearing. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-09-09target-i386: present virtual L3 cache info for vcpusLongpeng(Mike)2-5/+50
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: Longpeng(Mike) <longpeng2@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-09-05target-i386: Add more Intel AVX-512 instructions supportLuwei Kang2-5/+14
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.pdf Signed-off-by: Luwei Kang <luwei.kang@intel.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-08-16target-i386: kvm: Report kvm_pv_unhalt as unsupported w/o kernel_irqchipEduardo Habkost1-0/+7
The kvm_pv_unhalt feature doesn't work if kernel_irqchip is disabled, so we need to report it as unsupported. Tested-by: Peter Xu <peterx@redhat.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-08-12trace-events: fix first line comment in trace-eventsLaurent Vivier1-1/+1
Documentation is docs/tracing.txt instead of docs/trace-events.txt. find . -name trace-events -exec \ sed -i "s?See docs/trace-events.txt for syntax documentation.?See docs/tracing.txt for syntax documentation.?" \ {} \; Signed-off-by: Laurent Vivier <lvivier@redhat.com> Message-id: 1470669081-17860-1-git-send-email-lvivier@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2016-08-08error: Strip trailing '\n' from error string arguments (again)Markus Armbruster1-1/+1
Commit 9af9e0f, 6daf194d, be62a2eb and 312fd5f got rid of a bunch, but they keep coming back. checkpatch.pl tries to flag them since commit 5d596c2, but it's not very good at it. Offenders tracked down with Coccinelle script scripts/coccinelle/err-bad-newline.cocci, an updated version of the script from commit 312fd5f. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <1470224274-31522-2-git-send-email-armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2016-08-02target-i386: fix typo in xsetbv implementationDave Hansen1-1/+1
QEMU 2.6 added support for the XSAVE family of instructions, which includes the XSETBV instruction which allows setting the XCR0 register. But, when booting Linux kernels with XSAVE support enabled, I was getting very early crashes where the instruction pointer was set to 0x3. I tracked it down to a jump instruction generated by this: gen_jmp_im(s->pc - pc_start); where s->pc is pointing to the instruction after XSETBV and pc_start is pointing _at_ XSETBV. Subtract the two and you get 0x3. Whoops. The fix is to replace this typo with the pattern found everywhere else in the file when folks want to end the translation buffer. Richard Henderson confirmed that this is a bug and that this is the correct fix. Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: qemu-stable@nongnu.org Cc: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Richard Henderson <rth@twiddle.net> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-07-21Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into stagingPeter Maydell2-2/+114
pc, pci, virtio: new features, cleanups, fixes - interrupt remapping for intel iommus - a bunch of virtio cleanups - fixes all over the place Signed-off-by: Michael S. Tsirkin <mst@redhat.com> # gpg: Signature made Thu 21 Jul 2016 18:49:30 BST # gpg: using RSA key 0x281F0DB8D28D5469 # gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" # gpg: aka "Michael S. Tsirkin <mst@redhat.com>" # Primary key fingerprint: 0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67 # Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA 8A0D 281F 0DB8 D28D 5469 * remotes/mst/tags/for_upstream: (57 commits) intel_iommu: avoid unnamed fields virtio: Update migration docs virtio-gpu: Wrap in vmstate virtio-gpu: Use migrate_add_blocker for virgl migration blocking virtio-input: Wrap in vmstate 9pfs: Wrap in vmstate virtio-serial: Wrap in vmstate virtio-net: Wrap in vmstate virtio-balloon: Wrap in vmstate virtio-rng: Wrap in vmstate virtio-blk: Wrap in vmstate virtio-scsi: Wrap in vmstate virtio: Migration helper function and macro virtio-serial: Remove old migration version support virtio-net: Remove old migration version support virtio-scsi: Replace HandleOutput typedef Revert "mirror: Workaround for unexpected iohandler events during completion" virtio-scsi: Call virtio_add_queue_aio virtio-blk: Call virtio_add_queue_aio virtio: Introduce virtio_add_queue_aio ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-07-21kvm-irqchip: do explicit commit when update irqPeter Xu1-0/+1
In the past, we are doing gsi route commit for each irqchip route update. This is not efficient if we are updating lots of routes in the same time. This patch removes the committing phase in kvm_irqchip_update_msi_route(). Instead, we do explicit commit after all routes updated. Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-07-21kvm-irqchip: x86: add msi route notify fnPeter Xu2-0/+31
One more IEC notifier is added to let msi routes know about the IEC changes. When interrupt invalidation happens, all registered msi routes will be updated for all PCI devices. Since both vfio and vhost are possible gsi route consumers, this patch will go one step further to keep them safe in split irqchip mode and when irqfd is enabled. Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> [move trace-events lines into target-i386/trace-events] Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-07-21kvm-irqchip: i386: add hook for add/remove virqPeter Xu2-0/+50
Adding two hooks to be notified when adding/removing msi routes. There are two kinds of MSI routes: - in kvm_irqchip_add_irq_route(): before assigning IRQFD. Used by vhost, vfio, etc. - in kvm_irqchip_send_msi(): when sending direct MSI message, if direct MSI not allowed, we will first create one MSI route entry in the kernel, then trigger it. This patch only hooks the first one (irqfd case). We do not need to take care for the 2nd one, since it's only used by QEMU userspace (kvm-apic) and the messages will always do in-time translation when triggered. While we need to note them down for the 1st one, so that we can notify the kernel when cache invalidation happens. Also, we do not hook IOAPIC msi routes (we have explicit notifier for IOAPIC to keep its cache updated). We only need to care about irqfd users. Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-07-21kvm-irqchip: simplify kvm_irqchip_add_msi_routePeter Xu1-2/+1
Changing the original MSIMessage parameter in kvm_irqchip_add_msi_route into the vector number. Vector index provides more information than the MSIMessage, we can retrieve the MSIMessage using the vector easily. This will avoid fetching MSIMessage every time before adding MSI routes. Meanwhile, the vector info will be used in the coming patches to further enable gsi route update notifications. Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-07-21intel_iommu: add support for split irqchipPeter Xu2-0/+31
In split irqchip mode, IOAPIC is working in user space, only update kernel irq routes when entry changed. When IR is enabled, we directly update the kernel with translated messages. It works just like a kernel cache for the remapping entries. Since KVM irqfd is using kernel gsi routes to deliver interrupts, as long as we can support split irqchip, we will support irqfd as well. Also, since kernel gsi routes will cache translated interrupts, irqfd delivery will not suffer from any performance impact due to IR. And, since we supported irqfd, vhost devices will be able to work seamlessly with IR now. Logically this should contain both vhost-net and vhost-user case. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> [move trace-events lines into target-i386/trace-events] Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-07-20target-i386: Add x86_cpu_unrealizefn()Igor Mammedov1-0/+16
First remove VCPU from exec loop and only then remove lapic. Signed-off-by: Chen Fan <chen.fan.fnst@cn.fujitsu.com> Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com> Signed-off-by: Zhu Guihua <zhugh.fnst@cn.fujitsu.com> Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-07-20pc: cpu: Allow device_add to be used with x86 cpuIgor Mammedov1-0/+1
Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-07-20target-i386: Fix apic object leak when CPU is deletedIgor Mammedov1-0/+1
Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-07-20target-i386: cpu: Do not ignore error and fix apic parentIgor Mammedov1-2/+3
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: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-07-20target-i386: Add support for UMIP and RDPID CPUID bitsPaolo Bonzini2-2/+4
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: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-07-20target-i386: Add socket/core/thread properties to X86CPUIgor Mammedov2-0/+10
These properties will be used by as address where to plug CPU with help -device/device_add commands. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-07-20target-i386: Replace custom apic-id setter/getter with static propertyIgor Mammedov1-39/+6
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: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-07-20pc: cpu: Consolidate apic-id validity checks in pc_cpu_pre_plug()Igor Mammedov1-13/+0
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: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
generated by cgit v1.2.1 (git 2.18.0) at 2024-07-07 11:39:26 +0000