aboutsummaryrefslogtreecommitdiff
path: root/target-i386
AgeCommit message (Collapse)Author
2016-09-27target-i386: Add a marker to end of the region zeroed on resetEduardo Habkost
Instead of using cpuid_level, use an empty struct as a marker (like we already did with {start,end}_init_save). This will avoid accidentaly resetting the wrong fields if we change the field ordering on CPUX86State. Reviewed-by: Richard Henderson <rth@twiddle.net> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-09-27target-i386: Remove unused X86CPUDefinition::xlevel2 fieldEduardo Habkost
No CPU model in builtin_x86_defs has xlevel2 set, so it is always zero. Delete the field. Note that this is not an user-visible change. It doesn't remove the ability to set xlevel2 on the command-line, it just removes an unused field in builtin_x86_defs. Reviewed-by: Richard Henderson <rth@twiddle.net> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-09-27cpus: pass CPUState to run_on_cpu helpersAlex Bennée
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)
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 Gilbert
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 Bonzini
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 Henderson
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 Kumar
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 Shmarov
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 Bonzini
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 Gilbert
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)
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 Kang
Add more AVX512 feature bits, include AVX512DQ, AVX512IFMA, AVX512BW, AVX512VL, AVX512VBMI. Its spec can be found at: https://software.intel.com/sites/default/files/managed/b4/3a/319433-024.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 Habkost
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 Vivier
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 Armbruster
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 Hansen
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 Maydell
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 Xu
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 Xu
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 Xu
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 Xu
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 Xu
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 Mammedov
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 Mammedov
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 Mammedov
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 Mammedov
object_property_add_child() silently fails with error that it can't create duplicate propery 'apic' as we already have 'apic' property registered for 'apic' feature. As result generic device_realize puts apic into unattached container. As it's programming error, abort if name collision happens in future and fix property name for apic_state to 'lapic', this way apic is a child of cpu instance. Signed-off-by: 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 Bonzini
These are both stored in CPUID[EAX=7,EBX=0].ECX. KVM is going to be able to emulate both (albeit with a performance loss in the case of RDPID, which therefore will be in KVM_GET_EMULATED_CPUID rather than KVM_GET_SUPPORTED_CPUID). It's also possible to implement both in TCG, but this is for 2.8. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-07-20target-i386: Add socket/core/thread properties to X86CPUIgor Mammedov
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 Mammedov
Custom apic-id setter/getter doesn't do any property specific checks anymore, so clean it up and use more compact static property DEFINE_PROP_UINT32 instead. Signed-off-by: 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 Mammedov
Machine code knows about all possible APIC IDs so use that instead of hack which does O(n^2) complexity duplicate checks, interating over global CPUs list. As result duplicate check is done only once with O(log n) complexity. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-07-20target-i386: Set physical address bits based on hostDr. David Alan Gilbert
Add the host-phys-bits boolean property, if true, take phys-bits from the hosts physical bits value, overriding either the default or the user specified value. We can also use the value we read from the host to check the users explicitly set value and warn them if it doesn't match. Note: a) We only read the hosts value in KVM mode (because on non-x86 we get an abort if we try) b) We don't warn about trying to use host-phys-bits in TCG mode, we just fall back to the TCG default. This allows the machine type to set the host-phys-bits flag if it wants and then to work in both TCG and KVM. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-07-20target-i386: Use uint32_t for X86CPU.apic_idIgor Mammedov
Redo 9886e834 (target-i386: Require APIC ID to be explicitly set before CPU realize) in another way that doesn't use int64_t to detect if apic-id property has been set. Use the fact that 0xFFFFFFFF is the broadcast value that a CPU can't have and set default uint32_t apic_id to it instead of using int64_t. Later uint32_t apic_id will be used to drop custom property setter/getter in favor of static property. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-07-20target-i386: Fill high bits of mtrr maskDr. David Alan Gilbert
Fill the bits between 51..number-of-physical-address-bits in the MTRR_PHYSMASKn variable range mtrr masks so that they're consistent in the migration stream irrespective of the physical address space of the source VM in a migration. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-07-20target-i386: Mask mtrr mask based on CPU physical address limitsDr. David Alan Gilbert
The CPU GPs if we try and set a bit in a variable MTRR mask above the limit of physical address bits on the host. We hit this when loading a migration from a host with a larger physical address limit than our destination (e.g. a Xeon->i7 of same generation) but previously used to get away with it until 48e1a45 started checking that msr writes actually worked. It seems in our case the GP probably comes from KVM emulating that GP. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-07-20target-i386: Allow physical address bits to be setDr. David Alan Gilbert
Currently QEMU sets the x86 number of physical address bits to the magic number 40. This is only correct on some small AMD systems; Intel systems tend to have 36, 39, 46 bits, and large AMD systems tend to have 48. Having the value different from your actual hardware is detectable by the guest and in principal can cause problems; The current limit of 40 stops TB VMs being created by those lucky enough to have that much. This patch lets you set the physical bits by a cpu property but defaults to the same 40bits which matches TCGs setup. I've removed the ancient warning about the 42 bit limit in exec.c; I can't find that limit in there and no one else seems to know where it is. We use a magic value of 0 as the property default so that we can later distinguish between the default and a user set value. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-07-20target-i386: Provide TCG_PHYS_ADDR_BITSDr. David Alan Gilbert
Provide a constant for the number of address bits supported under TCG. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Suggested-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-07-19target-i386: Remove redundant HF_SOFTMMU_MASKSergey Fedorov
'HF_SOFTMMU_MASK' is only set when 'CONFIG_SOFTMMU' is defined. So there's no need in this flag: test 'CONFIG_SOFTMMU' instead. Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Sergey Fedorov <serge.fdrv@gmail.com> Signed-off-by: Sergey Fedorov <sergey.fedorov@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20160715175852.30749-6-sergey.fedorov@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-07-12Clean up ill-advised or unusual header guardsMarkus Armbruster
Cleaned up with scripts/clean-header-guards.pl. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Richard Henderson <rth@twiddle.net>
2016-07-12Clean up header guards that don't match their file nameMarkus Armbruster
Header guard symbols should match their file name to make guard collisions less likely. Offenders found with scripts/clean-header-guards.pl -vn. Cleaned up with scripts/clean-header-guards.pl, followed by some renaming of new guard symbols picked by the script to better ones. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Richard Henderson <rth@twiddle.net>
2016-07-12target-*: Clean up cpu.h header guardsMarkus Armbruster
Most of them use guard symbols like CPU_$target_H, but we also have __MIPS_CPU_H__ and __TRICORE_CPU_H__. They all upset scripts/clean-header-guards.pl. The script dislikes CPU_$target_H because they don't match their file name (they should, to make guard collisions less likely). The others are reserved identifiers. Clean them all up: use guard symbol $target_CPU_H for target-$target/cpu.h. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Richard Henderson <rth@twiddle.net>
2016-07-12Fix confusing argument names in some common functionsSergey Sorokin
There are functions tlb_fill(), cpu_unaligned_access() and do_unaligned_access() that are called with access type and mmu index arguments. But these arguments are named 'is_write' and 'is_user' in their declarations. The patches fix the arguments to avoid a confusion. Signed-off-by: Sergey Sorokin <afarallax@yandex.ru> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Message-id: 1465907177-1399402-1-git-send-email-afarallax@yandex.ru Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-07-07target-i386: Enable LMCE for '-cpu host' if supported by hostHaozhong Zhang
If -cpu host is used, LMCE will be automatically enabled when it's supported by host. Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-07-07target-i386: Publish advised value of MSR_IA32_FEATURE_CONTROL via fw_cfgHaozhong Zhang
It's a prerequisite that certain bits of MSR_IA32_FEATURE_CONTROL should be set before some features (e.g. VMX and LMCE) can be used, which is usually done by the firmware. This patch adds a fw_cfg file "etc/msr_feature_control" which contains the advised value of MSR_IA32_FEATURE_CONTROL and can be used by guest firmware (e.g. SeaBIOS). Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-07-07target-i386: kvm: Add basic Intel LMCE supportAshok Raj
This patch adds the support to inject SRAR and SRAO as LMCE, i.e. they are injected to only one VCPU rather than broadcast to all VCPUs. As KVM reports LMCE support on Intel platforms, this features is only available on Intel platforms. LMCE is disabled by default and can be enabled/disabled by cpu option 'lmce=on/off'. Signed-off-by: Ashok Raj <ashok.raj@intel.com> [Haozhong: Enable LMCE only on Intel platforms Disable LMCE by default and add a cpu option 'lmce' Handle the error if LMCE is enabled w/o host support Remove MCG_LMCE_P from MCE_CAP_DEF Add migration support for LMCE Minor code style changes] Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-07-07target-i386: Report hyperv feature words through qomEvgeny Yakovlev
This change adds hyperv feature words report through qom rpc. When VM is configured with hyperv features enabled libvirt will check that required feature words are set in cpuid leaf 40000003 through qom request. Currently qemu does not report hyperv feature words which prevents windows guests from starting with libvirt. To avoid conflicting with current hyperv properties all added feature words cannot be set directly with -cpu +feature yet. 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> CC: Marcelo Tosatti <mtosatti@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-07-07target-i386: Show host and VM TSC frequencies on mismatchEduardo Habkost
Improve the TSC frequency mismatch warning to show the host and VM TSC frequencies. Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-07-07pc: Parse CPU features only onceIgor Mammedov
Considering that features are converted to global properties and global properties are automatically applied to every new instance of created CPU (at object_new() time), there is no point in parsing cpu_model string every time a CPU created. So move parsing outside CPU creation loop and do it only once. Parsing also should be done before any CPU is created so that features would affect the first CPU a well. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2016-07-07cpu: Use CPUClass->parse_features() as convertor to global propertiesIgor Mammedov
Currently CPUClass->parse_features() is used to parse -cpu features string and set properties on created CPU instances. But considering that features specified by -cpu apply to every created CPU instance, it doesn't make sense to parse the same features string for every CPU created. It also makes every target that cares about parsing features string explicitly call CPUClass->parse_features() parser, which gets in a way if we consider using generic device_add for CPU hotplug as device_add has not a clue about CPU specific hooks. Turns out we can use global properties mechanism to set properties on every created CPU instance for a given type. That way it's possible to convert CPU features into a set of global properties for CPU type specified by -cpu cpu_model and common Device.device_post_init() will apply them to CPU of given type automatically regardless whether it's manually created CPU or CPU created with help of device_add. 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-07target-i386: Avoid using locals outside their scopePaolo Bonzini
x86_cpu_parse_featurestr has a "val = num;" assignment just before num goes out of scope. Push num up to fix the issue. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-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.3 (git 2.25.1) at 2024-05-17 20:38:01 +0000