Avi Kivity wrote:
> You can pull from my repository by issuing the command
>
> git pull git://kvm.qumranet.com/home/avi/kvm/linux-2.6
Please note that the url has now changed:
git pull git://kvm.qumranet.com/home/avi/kvm.git master
For future reference, see instructions at
http://kvm.qumran
> Hi Leonard,
>
> Why not factor the common code into kvm_main.c and add a set_tsc_offset
> member to the kvm ops function table?
Good idea, I put it on the todo list.
> Regards,
>
> Anthony Liguori
Thanks,
-- Leonard
-
Make the key column wider, so the keys are fully shown.
Signed-off-by: Leonard Norrgård <[EMAIL PROTECTED]>
=== kvm_stat
==
--- kvm_stat (revision 20893)
+++ kvm_stat (local)
@@ -39,9 +39,9 @@
for key in sorted(s.keys()):
The previous patch introduces an IPI on every vcpu migration on SMP
machines to find out the TSC value on the previous cpu. We might be
able to avoid this IPI on systems that have a synchronized TSC by
checking for it in svm/vmx_vcpu_load:
+ /* If this isn't the first vcpu_load and i
When a vcpu is migrated to another cpu, an unexpected difference in
current and previous cpu TSC values can cause a guest to wait
indefinitely. A known workaround has been to run kvm with taskset,
locking it to a single cpu. This patch modifies the guest viewable TSC
so that the TSC is guaranteed t
When a vcpu is migrated to another cpu, an unexpected difference in
current and previous cpu TSC values can cause a guest to wait
indefinitely. A known workaround has been to run kvm with taskset,
locking it to a single cpu. This patch series modifies the guest TSC
offset as needed to guarantee tha
Dor Laor wrote:
> Hi Leonard,
>
> Can you try the attached patch and tell me what's going on?
> Sorry for the delay response, I was a little busy.
>
> The patch zero's the svm interrupt vector after vmexit, right after we
> checked for pending irq's that were not injected.
> Although the IRQ_MASK i
Dor Laor wrote:
> Finally I manage to reproduce the problem. I did manage to play the
> puzzle without problems, but I discovered that under load there are
> problems with the mouse.
> I didn't have any problems with 100% cpu consumption (Operton cpu).
>
I'll try to find a good way to reproduce
Seeing the message from Matthew Hall on "KVM, AMD & interrupts" (25th
Jan.), I tried rebooting the host kernel with "noapic", "nolapic" and
"noapic nolapic".
- For noapic, no change in behaviour was seen. Mouse/keyboard problem
still frequent.
- For nolapic, the network didn't come up (aborted te
Dor Laor wrote:
>> The guest OS is 32-bit Debian Etch (KDE), the host AMD64 X2 5200+.
>> Kvm runs in SDL, command line: kvm -m 80 -hda disk.qcow
>>
>> All of this happens with kvm trunk.
>>
>
>
> I'm trying to replicate the problem. Running your Guest on AMD operton.
> So far every thing works
I've been looking at the guest reboot problem, which currently reboots
the host on svm when a Linux guest issues "# shutdown -r now".
(By the way, with a Linux guest, the rebooting can be worked around by
adding the kernel parameter reboot=b to the guest, this makes Linux use
an alternative reboot
On AMD processors, executing "shutdown -r now" in a Linux guest actually
reboots the host. While investigating that, I noticed this likely typo.
This patch isn't in itself the complete fix the host reboot, so be
prepared if you test the shutdown command in a Linux guest.
Note: "shutdown -h now" wo
12 matches
Mail list logo
