- 13 Oct, 2007 40 commits
-
-
Laurent Vivier authored
... instead of a x86_emulate_ctxt, so that other callers can use it easily. Signed-off-by:
Laurent Vivier <Laurent.Vivier@bull.net> Signed-off-by:
Avi Kivity <avi@qumranet.com>
-
Rusty Russell authored
Changes some svm.c internal function names: 1) io_adress -> io_address (de-germanify the spelling) 2) kvm_reput_irq -> reput_irq (it's not a generic kvm function) 3) kvm_do_inject_irq -> (it's not a generic kvm function) Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
-
Rusty Russell authored
container_of is wonderful, but not casting at all is better. This patch changes svm.c's internal functions to pass "struct vcpu_svm" instead of "struct kvm_vcpu" and using container_of. Signed-off-by:
-
Rusty Russell authored
There are several places where hardcoded numbers are used in place of the easily-available constant, which is poor form. Signed-off-by:
-
Rusty Russell authored
container_of is wonderful, but not casting at all is better. This patch changes vmx.c's internal functions to pass "struct vcpu_vmx" instead of "struct kvm_vcpu" and using container_of. Signed-off-by:
-
Rusty Russell authored
Now that kvm generally runs with preemption enabled, we need to protect the fpu intialization sequence. Signed-off-by:
-
Shaohua Li authored
This allows the kvm mmu to perform sleepy operations, such as memory allocation. Signed-off-by:
Shaohua Li <shaohua.li@intel.com> Signed-off-by:
-
Avi Kivity authored
Current kvm disables preemption while the new virtualization registers are in use. This of course is not very good for latency sensitive workloads (one use of virtualization is to offload user interface and other latency insensitive stuff to a container, so that it is easier to analyze the remaining workload). This patch re-enables preemption for kvm; preemption is now only disabled when switching the registers in and out, and during the switch to guest mode and back. Contains fixes from Shaohua Li <shaohua.li@intel.com>. Signed-off-by: -
Jeff Dike authored
Add the hypercall number to kvm_run and initialize it. This changes the ABI, but as this particular ABI was unusable before this no users are affected. Signed-off-by:
Jeff Dike <jdike@linux.intel.com> Signed-off-by:
-
Yang, Sheng authored
Put cpu feature detecting part in hardware_setup, and stored the vmcs condition in global variable for further check. [glommer: fix for some i386-only machines not supporting CR8 load/store exiting] Signed-off-by:
Sheng Yang <sheng.yang@intel.com> Signed-off-by:
Glauber de Oliveira Costa <gcosta@redhat.com> Signed-off-by:
-
Rusty Russell authored
This patch converts the vcpus array in "struct kvm" to a pointer array, and changes the "vcpu_create" and "vcpu_setup" hooks into one "vcpu_create" call which does the allocation and initialization of the vcpu (calling back into the kvm_vcpu_init core helper). Signed-off-by:
-
Gregory Haskins authored
struct kvm_vcpu has vmx-specific members; remove them to a private structure. Signed-off-by:
Gregory Haskins <ghaskins@novell.com> Signed-off-by:
-
Rusty Russell authored
load_pdptrs can be handed an invalid cr3, and it should not oops. This can happen because we injected #gp in set_cr3() after we set vcpu->cr3 to the invalid value, or from kvm_vcpu_ioctl_set_sregs(), or memory configuration changes after the guest did set_cr3(). We should also copy the pdpte array once, before checking and assigning, otherwise an SMP guest can potentially alter the values between the check and the set. Finally one nitpick: ret = 1 should be done as late as possible: this allows GCC to check for unset "ret" should the function change in future. Signed-off-by:
-
Aurelien Jarno authored
The writeback fixes (02c03a32) let some dead code in the cmpxchg instruction emulation. Remove it. Signed-off-by:
Aurelien Jarno <aurelien@aurel32.net> Signed-off-by:
-
Yang, Sheng authored
This patch mainly imports some constants and rename two exist constants of vmcs according to IA32 SDM. It also adds two constants to indicate Lock bit and Enable bit in MSR_IA32_FEATURE_CONTROL, and replace the hardcode _5_ with these two bits. Signed-off-by:
-
Shaohua Li authored
gfn_to_page might sleep with swap support. Move it out of the kmap calls. Signed-off-by:
-
Shaohua Li authored
vmx_cpu_run doesn't handle error correctly and kvm_mmu_reload might sleep with mutex changes, so I move it above. Signed-off-by:
-
Rusty Russell authored
Don't fall through and turn on PAE in this case. Signed-off-by:
-
Avi Kivity authored
Right now, the bug is harmless as we never emulate one-byte 0xb6 or 0xb7. But things may change. Noted by the mysterious Gabriel C. Signed-off-by: -
Avi Kivity authored
The writeback fixes (02c03a32) broke cmov emulation. Fix. Signed-off-by:
-
Rusty Russell authored
Intel manual (and KVM definition) say the TPR is 4 bits wide. Also fix CR8_RESEVED_BITS typo. Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
-
Jeff Dike authored
Signed-off-by:
-
Rusty Russell authored
Creating one's own BITMAP macro seems suboptimal: if we use manual arithmetic in the one place exposed to userspace, we can use standard macros elsewhere. Signed-off-by:
-
Rusty Russell authored
On this machine (Intel), writing to the CR4 bits 0x00000800 and 0x00001000 cause a GPF. The Intel manual is a little unclear, but AFIACT they're reserved, too. Also fix spelling of CR4_RESEVED_BITS. Signed-off-by:
-
Rusty Russell authored
The kernel now has asm/cpu-features.h: use those macros instead of inventing our own. Also spell out definition of CR3_RESEVED_BITS, fix spelling and tighten it for the non-PAE case. Signed-off-by:
-
Rusty Russell authored
The kernel now has asm/cpu-features.h: use those macros instead of inventing our own. Also spell out definition of CR0_RESEVED_BITS (no code change) and fix typo. Signed-off-by:
-
Rusty Russell authored
Don't pre-declare hardware_disable: shuffle the reboot hook down. Signed-off-by:
-
Rusty Russell authored
Speling error in comment. Signed-off-by:
-
Rusty Russell authored
I have shied away from touching x86_emulate.c (it could definitely use some love, but it is forked from the Xen code, and it would be more productive to cross-merge fixes). Signed-off-by:
-
Rusty Russell authored
Signed-off-by:
-
Rusty Russell authored
KVM interface is no longer experimental. Signed-off-by:
-
Eddie Dong authored
Add string pio write support to support some version of Windows. Signed-off-by:
Yaozu (Eddie) Dong <eddie.dong@intel.com> Signed-off-by:
-
Avi Kivity authored
Note that as the size of struct kvm_run is not part of the ABI, we can add things at the end. Signed-off-by: -
Qing He authored
This patch adds a `vcpu_id' field in `struct vcpu', so we can differentiate BSP and APs without pointer comparison or arithmetic. Signed-off-by:
Qing He <qing.he@intel.com> Signed-off-by:
-
Nguyen Anh Quynh authored
*nopage() in kvm_main.c should only store the type of mmap() fault if the pointers are not NULL. This patch fixes the problem. Signed-off-by:
Nguyen Anh Quynh <aquynh@gmail.com> Signed-off-by:
-
Avi Kivity authored
KVM reuses the IOAPIC register definitions, and needs them even if the host is not compiled with IOAPIC support. Move the #ifdef below so that only the IOAPIC variables and functions are protected, and the register definitions are available to all. Signed-off-by: -
Jeff Garzik authored
Fix DMI const-ification fallout that appeared when merging subsystem trees. Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Nick Piggin authored
According to latest memory ordering specification documents from Intel and AMD, both manufacturers are committed to in-order loads from cacheable memory for the x86 architecture. Hence, smp_rmb() may be a simple barrier. Also according to those documents, and according to existing practice in Linux (eg. spin_unlock doesn't enforce ordering), stores to cacheable memory are visible in program order too. Special string stores are safe -- their constituent stores may be out of order, but they must complete in order WRT surrounding stores. Nontemporal stores to WB memory can go out of order, and so they should be fenced explicitly to make them appear in-order WRT other stores. Hence, smp_wmb() may be a simple barrier. http://developer.intel.com/products/processor/manuals/318147.pdf http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf In userspace microbenchmarks on a core2 system, fence instructions range anywhere from around 15 cycles to 50, which may not be totally insignificant in performance critical paths (code size will go down too). However the primary motivation for this is to have the canonical barrier implementation for x86 architecture. smp_rmb on buggy pentium pros remains a locked op, which is apparently required. Signed-off-by:Nick Piggin <npiggin@suse.de> Signed-off-by:
-
Nick Piggin authored
wmb() on x86 must always include a barrier, because stores can go out of order in many cases when dealing with devices (eg. WC memory). Signed-off-by:
-
Nick Piggin authored
movnt* instructions are not strongly ordered with respect to other stores, so if we are to assume stores are strongly ordered in the rest of the 64 bit code, we must fence these off (see similar examples in 32 bit code). [ The AMD memory ordering document seems to say that nontemporal stores can also pass earlier regular stores, so maybe we need sfences _before_ movnt* everywhere too? ] Signed-off-by:
-
