- 16 Jul, 2007 40 commits
-
-
Avi Kivity authored
Only at the CPU_DYING stage can we be sure that no user process will be scheduled onto the cpu and oops when trying to use virtualization extensions. Signed-off-by: Avi Kivity <avi@qumranet.com>
-
Avi Kivity authored
The hotplug IPIs can be called from the cpu on which we are currently running on, so use on_cpu(). Similarly, drop on_each_cpu() for the suspend/resume callbacks, as we're in atomic context here and only one cpu is up anyway. Signed-off-by: Avi Kivity <avi@qumranet.com>
-
Avi Kivity authored
By keeping track of which cpus have virtualization enabled, we prevent double-enable or double-disable during hotplug, which is a very fatal oops. Signed-off-by: Avi Kivity <avi@qumranet.com>
-
Avi Kivity authored
This removes the requirement for callers to get_cpu() to check in simple cases. This patch is for !CONFIG_SMP. Cc: Andi Kleen <ak@suse.de> Signed-off-by: Avi Kivity <avi@qumranet.com>
-
Avi Kivity authored
This removes the requirement for callers to get_cpu() to check in simple cases. Cc: Andi Kleen <ak@suse.de> Signed-off-by: Avi Kivity <avi@qumranet.com>
-
Avi Kivity authored
This removes the requirement for callers to get_cpu() to check in simple cases. Cc: Andi Kleen <ak@suse.de> Signed-off-by: Avi Kivity <avi@qumranet.com>
-
Avi Kivity authored
CPU_DYING is notified in atomic context, so no taking mutexes here. Signed-off-by: Avi Kivity <avi@qumranet.com>
-
Avi Kivity authored
CPU_DYING is called in atomic context, so don't try to take any locks. Signed-off-by: Avi Kivity <avi@qumranet.com>
-
Avi Kivity authored
KVM wants a notification when a cpu is about to die, so it can disable hardware extensions, but at a time when user processes cannot be scheduled on the cpu, so it doesn't try to use virtualization extensions after they have been disabled. This adds a CPU_DYING notification. The notification is called in atomic context on the doomed cpu. Signed-off-by: Avi Kivity <avi@qumranet.com>
-
Avi Kivity authored
Remove unnecessary ones, and rearange the remaining in the standard order. Signed-off-by: Avi Kivity <avi@qumranet.com>
-
Avi Kivity authored
kvm uses a pseudo filesystem, kvmfs, to generate inodes, a job that the new anonymous inodes source does much better. Cc: Davide Libenzi <davidel@xmailserver.org> Signed-off-by: Avi Kivity <avi@qumranet.com>
-
Joerg Roedel authored
This patch adds an implementation to the svm is_disabled function to detect reliably if the BIOS disabled the SVM feature in the CPU. This fixes the issues with kernel panics when loading the kvm-amd module on machines where SVM is available but disabled. Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Avi Kivity <avi@qumranet.com>
-
Avi Kivity authored
A vmexit implicitly flushes the tlb; the code is bogus. Noted by Shaohua Li. Signed-off-by: Avi Kivity <avi@qumranet.com>
-
Shaohua Li authored
Need to flush the tlb after updating a pte, not before. Signed-off-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Avi Kivity <avi@qumranet.com>
-
Avi Kivity authored
Protected mode code may have corrupted the real-mode tss, so re-initialize it when switching to real mode. Signed-off-by: Avi Kivity <avi@qumranet.com>
-
Luca Tettamanti authored
When writing to normal memory and the memory area is unchanged the write can be safely skipped, avoiding the costly kvm_mmu_pte_write. Signed-Off-By: Luca Tettamanti <kronos.it@gmail.com> Signed-off-by: Avi Kivity <avi@qumranet.com>
-
Luca Tettamanti authored
When the old value and new one are the same the emulator skips the write; this is undesirable when the destination is a MMIO area and the write shall be performed regardless of the previous value. This optimization breaks e.g. a Linux guest APIC compiled without X86_GOOD_APIC. Remove the check and perform the writeback stage in the emulation unless it's explicitly disabled (currently push and some 2 bytes instructions may disable the writeback). Signed-Off-By: Luca Tettamanti <kronos.it@gmail.com> Signed-off-by: Avi Kivity <avi@qumranet.com>
-
Eddie Dong authored
Useful for the PIC and PIT. Signed-off-by: Yaozu (Eddie) Dong <eddie.dong@intel.com> Signed-off-by: Avi Kivity <avi@qumranet.com>
-
Gregory Haskins authored
With kernel-injected interrupts, we need to check for interrupts on lightweight exits too. Signed-off-by: Gregory Haskins <ghaskins@novell.com> Signed-off-by: Avi Kivity <avi@qumranet.com>
-
Gregory Haskins authored
Signed-off-by: Gregory Haskins <ghaskins@novell.com> Signed-off-by: Avi Kivity <avi@qumranet.com>
-
Nitin A Kamble authored
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com> Signed-off-by: Avi Kivity <avi@qumranet.com>
-
Nitin A Kamble authored
For use in real mode. Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com> Signed-off-by: Avi Kivity <avi@qumranet.com>
-
Avi Kivity authored
If the time stamp counter goes backwards, a guest delay loop can become infinite. This can happen if a vcpu is migrated to another cpu, where the counter has a lower value than the first cpu. Since we're doing an IPI to the first cpu anyway, we can use that to pick up the old tsc, and use that to calculate the adjustment we need to make to the tsc offset. Signed-off-by: Avi Kivity <avi@qumranet.com>
-
Avi Kivity authored
Needs to be set on vcpu 0 only. Signed-off-by: Avi Kivity <avi@qumranet.com>
-
Shani Moideen authored
Signed-off-by: Shani Moideen <shani.moideen@wipro.com> Signed-off-by: Avi Kivity <avi@qumranet.com>
-
Shani Moideen authored
Signed-off-by: Shani Moideen <shani.moideen@wipro.com> Signed-off-by: Avi Kivity <avi@qumranet.com>
-
Avi Kivity authored
When a vcpu causes a shadow tlb entry to have reduced permissions, it must also clear the tlb on remote vcpus. We do that by: - setting a bit on the vcpu that requests a tlb flush before the next entry - if the vcpu is currently executing, we send an ipi to make sure it exits before we continue Signed-off-by: Avi Kivity <avi@qumranet.com>
-
Avi Kivity authored
That way, we don't need to loop for KVM_MAX_VCPUS for a single vcpu vm. Signed-off-by: Avi Kivity <avi@qumranet.com>
-
Avi Kivity authored
This has two use cases: the bios can't boot from disk, and guest smp bootstrap. Signed-off-by: Avi Kivity <avi@qumranet.com>
-
Avi Kivity authored
Will soon have a thid user. Signed-off-by: Avi Kivity <avi@qumranet.com>
-
Avi Kivity authored
As we don't support guest tlb shootdown yet, this is only reliable for real-mode guests. Signed-off-by: Avi Kivity <avi@qumranet.com>
-
Avi Kivity authored
If we add the vm once per vcpu, we corrupt the list if the guest has multiple vcpus. Signed-off-by: Avi Kivity <avi@qumranet.com>
-
Avi Kivity authored
A vcpu can pin up to four mmu shadow pages, which means the freeing loop will never terminate. Fix by first unpinning shadow pages on all vcpus, then freeing shadow pages. Signed-off-by: Avi Kivity <avi@qumranet.com>
-
Nguyen Anh Quynh authored
Signed-off-by: Avi Kivity <avi@qumranet.com>
-
Robert P. J. Day authored
Signed-off-by: Robert P. J. Day <rpjday@mindspring.com> Signed-off-by: Avi Kivity <avi@qumranet.com>
-
Avi Kivity authored
Switch guest paging context may require us to allocate memory, which might fail. Instead of wiring up error paths everywhere, make context switching lazy and actually do the switch before the next guest entry, where we can return an error if allocation fails. Signed-off-by: Avi Kivity <avi@qumranet.com>
-
Avi Kivity authored
This has not been used for some time, as the same information is available in the page header. Signed-off-by: Avi Kivity <avi@qumranet.com>
-
Avi Kivity authored
This was once used to avoid accessing the guest pte when upgrading the shadow pte from read-only to read-write. But usually we need to set the guest pte dirty or accessed bits anyway, so this wasn't really exploited. Signed-off-by: Avi Kivity <avi@qumranet.com>
-
Avi Kivity authored
Always set the accessed and dirty bit (since having them cleared causes a read-modify-write cycle), always set the present bit, and copy the nx bit from the guest. Signed-off-by: Avi Kivity <avi@qumranet.com>
-
Avi Kivity authored
No longer needed as we do everything in one place. Signed-off-by: Avi Kivity <avi@qumranet.com>
-