change, of one line in kvm_arch_vcpu_load, is made redundant
by a different patch sent by Zachary Amsden (and not yet applied):
kvm_arch_vcpu_load() should not read the guest TSC, and if it didn't, of
course we didn't have to change the call of kvm_get_msr() to read_l1_tsc().
Signed-off-by: Nadav
Comments inline. Sorry for top-posting. Gmail is not my normal mode
of LKML processing, but hey.
On Tue, Aug 2, 2011 at 5:54 AM, Nadav Har'El n...@il.ibm.com wrote:
This patch fixes two corner cases in nested (L2) handling of TSC-related
issues:
1. Somewhat suprisingly, according to the
Caution: this requires more care.
Pretty sure this breaks userspace suspend at the cost of supporting a
not-so-reasonable hardware feature.
On Tue, Aug 2, 2011 at 5:55 AM, Nadav Har'El n...@il.ibm.com wrote:
When the TSC MSR is read by an L2 guest (when L1 allowed this MSR to be
read without
, Jul 29, 2011, Zachary Amsden wrote about Re: Nested VMX - L1 hangs
on running L2:
...
In that case, you need to distinguish between reads of the TSC MSR by
the guest and reads by the host (as done internally to track drift and
...
Unfortunately, the layering currently doesn't seem to allow
2011/7/27 Nadav Har'El n...@math.technion.ac.il:
On Wed, Jul 20, 2011, Zachary Amsden wrote about Re: Nested VMX - L1 hangs
on running L2:
No, both patches are wrong.
kvm_get_msr(vcpu, MSR_IA32_TSC, tsc) should always return the L1 TSC,
regardless of the setting of any MSR bitmap
On 06/21/2011 01:50 AM, Jan Kiszka wrote:
On 2011-06-21 01:59, Zachary Amsden wrote:
In-Reply-To:
This is the remaining bulk of work I have related to TSC emulation.
In summary, I believe this fixes all known issues with TSC. A few
rather subtle issues are cleaned up, S4 suspend is fixed
Original Message
Subject: [KVM TSC emulation 1/9] Infrastructure for software and
hardware based TSC rate scaling
Date: Mon, 20 Jun 2011 16:59:29 -0700
From: Zachary Amsden zams...@redhat.com
To: Avi Kivity a...@redhat.com, Marcelo Tosatti mtosa...@redhat.com,
Glauber
Original Message
Subject:[KVM TSC emulation 2/9] Improve TSC offset matching
Date: Mon, 20 Jun 2011 16:59:30 -0700
From: Zachary Amsden zams...@redhat.com
To: Avi Kivity a...@redhat.com, Marcelo Tosatti mtosa...@redhat.com,
Glauber Costa glom...@redhat.com, Frank
Original Message
Subject: [KVM TSC emulation 3/9] Leave TSC synchronization window open
with each new sync
Date: Mon, 20 Jun 2011 16:59:31 -0700
From: Zachary Amsden zams...@redhat.com
To: Avi Kivity a...@redhat.com, Marcelo Tosatti mtosa...@redhat.com,
Glauber Costa
Original Message
Subject:[KVM TSC emulation 4/9] Fix last_guest_tsc / tsc_offset
semantics
Date: Mon, 20 Jun 2011 16:59:32 -0700
From: Zachary Amsden zams...@redhat.com
To: Avi Kivity a...@redhat.com, Marcelo Tosatti mtosa...@redhat.com,
Glauber Costa glom
Original Message
Subject:[KVM TSC emulation 5/9] Add last_host_tsc tracking back to KVM
Date: Mon, 20 Jun 2011 16:59:33 -0700
From: Zachary Amsden zams...@redhat.com
To: Avi Kivity a...@redhat.com, Marcelo Tosatti mtosa...@redhat.com,
Glauber Costa glom
Original Message
Subject: [KVM TSC emulation 6/9] Allow adjust_tsc_offset to be in host
or guest cycles
Date: Mon, 20 Jun 2011 16:59:34 -0700
From: Zachary Amsden zams...@redhat.com
To: Avi Kivity a...@redhat.com, Marcelo Tosatti mtosa...@redhat.com,
Glauber Costa
Original Message
Subject:[KVM TSC emulation 7/9] Don't mark TSC unstable due to S4
suspend
Date: Mon, 20 Jun 2011 16:59:35 -0700
From: Zachary Amsden zams...@redhat.com
To: Avi Kivity a...@redhat.com, Marcelo Tosatti mtosa...@redhat.com,
Glauber Costa glom
Original Message
Subject:[KVM TSC emulation 8/9] Track TSC synchronization in generations
Date: Mon, 20 Jun 2011 16:59:36 -0700
From: Zachary Amsden zams...@redhat.com
To: Avi Kivity a...@redhat.com, Marcelo Tosatti mtosa...@redhat.com,
Glauber Costa glom
Original Message
Subject:[KVM TSC emulation 9/9] Add software TSC emulation
Date: Mon, 20 Jun 2011 16:59:37 -0700
From: Zachary Amsden zams...@redhat.com
To: Avi Kivity a...@redhat.com, Marcelo Tosatti mtosa...@redhat.com,
Glauber Costa glom...@redhat.com, Frank
for 128-bit multiply
Signed-off-by: Zachary Amsden zams...@redhat.com
diff --git a/arch/x86/include/asm/pvclock.h b/arch/x86/include/asm/pvclock.h
index 31d84ac..a518c0a 100644
--- a/arch/x86/include/asm/pvclock.h
+++ b/arch/x86/include/asm/pvclock.h
@@ -22,6 +22,8 @@ static inline u64
On 05/09/2011 12:03 AM, Ulrich Obergfell wrote:
Loss of periodic timer interrupts caused by delayed callbacks and by
interrupt coalescing is compensated by gradually injecting additional
interrupts during subsequent timer intervals, starting at a rate of
one additional interrupt per interval.
On 05/08/2011 01:29 AM, Nadav Har'El wrote:
In the unlikely case that L1 does not capture MSR_IA32_TSC, L0 needs to
emulate this MSR write by L2 by modifying vmcs02.tsc_offset. We also need to
set vmcs12.tsc_offset, for this change to survive the next nested entry (see
prepare_vmcs02()).
On 05/08/2011 12:06 PM, Nikola Ciprich wrote:
OK,
I see.. the problem is, that I'm trying to hunt down bug causing hangs
when 2.6.32 guests try to run tcpdump - this seems to be reproducible even on
latest 2.6.32.x, and seems like it depends on kvm-clock..
So I was thinking about bisecting
On 05/09/2011 11:25 AM, Nikola Ciprich wrote:
The guest, because latest kernels do not suffer this problem, so I'd like to
find fix so it can be pushed to -stable (we're using 2.6.32.x)
host is currently 2.6.37 (and i'm currently testing 2.6.38 as well)
n.
That's a pretty wide range to be
On 04/29/2011 01:40 AM, Joerg Roedel wrote:
On Thu, Apr 28, 2011 at 08:00:57PM -0700, Zachary Amsden wrote:
On 04/28/2011 01:20 PM, Joerg Roedel wrote:
This code checks how many guest tsc cycles have passed since this vCPU
was de-scheduled last time (and before it is running
So I've been going over the new code changes to the TSC related code and
I don't like one particular set of changes. In particular, here:
kvm_x86_ops-vcpu_load(vcpu, cpu);
if (unlikely(vcpu-cpu != cpu) || check_tsc_unstable()) {
/* Make sure TSC doesn't go
On 04/28/2011 12:06 AM, Jan Kiszka wrote:
On 2011-04-28 08:59, Zachary Amsden wrote:
So I've been going over the new code changes to the TSC related code and
I don't like one particular set of changes. In particular, here:
kvm_x86_ops-vcpu_load(vcpu, cpu);
if (unlikely
On 04/28/2011 12:13 AM, Roedel, Joerg wrote:
On Thu, Apr 28, 2011 at 02:59:57AM -0400, Zachary Amsden wrote:
So I've been going over the new code changes to the TSC related code and
I don't like one particular set of changes. In particular, here:
kvm_x86_ops-vcpu_load(vcpu, cpu
On 04/28/2011 12:22 AM, Roedel, Joerg wrote:
On Thu, Apr 28, 2011 at 03:06:01AM -0400, Jan Kiszka wrote:
And /me still wonders (like I did when this first popped up) if the
proper place of determining TSC stability really have to be KVM.
If the Linux core fails to detect some instability
On 04/28/2011 01:20 PM, Joerg Roedel wrote:
On Thu, Apr 28, 2011 at 11:34:44AM -0700, Zachary Amsden wrote:
On 04/28/2011 12:13 AM, Roedel, Joerg wrote:
I see it different. This code wants to check if the _guest_ tsc moves
forwared (or at least not backwards). So it is fully
On 2011-04-19 08:46, Roedel, Joerg wrote:
On Mon, Apr 18, 2011 at 08:02:35PM -0400, Zachary Amsden wrote:
On Sat, Apr 16, 2011 at 06:09:17PM +0200, Jan Kiszka wrote:
On 2011-03-25 09:44, Joerg Roedel wrote:
+ tsc_delta = !vcpu
On Sat, Apr 16, 2011 at 06:09:17PM +0200, Jan Kiszka wrote:
On 2011-03-25 09:44, Joerg Roedel wrote:
+ tsc_delta = !vcpu-arch.last_guest_tsc ? 0 :
+tsc - vcpu-arch.last_guest_tsc;
This patch appears to cause troubles to Linux
On 04/11/2011 12:12 PM, Nikola Ciprich wrote:
Hello Zachary,
what is the current status, are You going to post this patch to Avi?
I'd like to see one (or both) in stable eventually, I think it's good
candidate..
BR
nik
I think for upstream the newer patch is the way to go, but I would
On 03/09/2011 05:36 PM, Nikola Ciprich wrote:
commit 387b9f97750444728962b236987fbe8ee8cc4f8c moved
kvm_request_guest_time_update(vcpu),
breaking 32bit SMP guests using kvm-clock. Fix this by moving (new) clock
update function
to proper place.
Signed-off-by: Nikola
On 03/09/2011 02:30 PM, Nikola Ciprich wrote:
Can you try moving the kvm_make_request() inside the if conditional and
see if it that also fixes it?
yes, changing to:
if (unlikely(vcpu-cpu != cpu) || check_tsc_unstable()) {
kvm_make_request(KVM_REQ_CLOCK_UPDATE, vcpu);
/*
On 03/09/2011 05:36 PM, Nikola Ciprich wrote:
commit 387b9f97750444728962b236987fbe8ee8cc4f8c moved
kvm_request_guest_time_update(vcpu),
breaking 32bit SMP guests using kvm-clock. Fix this by moving (new) clock
update function
to proper place.
Signed-off-by: Nikola
On 03/07/2011 05:18 AM, Nikola Ciprich wrote:
e48672fa25e879f7ae21785c7efd187738139593 removed
kvm_request_guest_time_update(vcpu);
this breaks 32bit SMP guests using virtio-clock.
thus add unconditional call to kvm_make_request(KVM_REQ_CLOCK_UPDATE, vcpu) to
fix the
problem.
Signed-off-by:
On 03/05/2011 02:21 AM, Nikola Ciprich wrote:
Can you try this patch to see if it fixes the problem?
You haven't read my replies, did you? ;-)
kvm_request_guest_time_update seems to have been
removed, and kvm_make_request(KVM_REQ_CLOCK_UPDATE, vcpu)
seems to be used instead, adding it
On 03/03/2011 05:01 PM, Nikola Ciprich wrote:
That sounds like a kernel which will be vulnerable to broken KVM clock
on 32-bit. There's a kernel side fix that is needed, but why the server
side change triggers the problem needs more investigation.
OK, it's important for me that I can fix
On 03/04/2011 02:09 PM, Glauber Costa wrote:
On Fri, 2011-03-04 at 19:27 +0100, Nikola Ciprich wrote:
Hello Zachary,
You don't see any messages about TSC being unstable or switching
clocksource after loading the KVM module? And you are not suspending
the host or anything?
On 03/04/2011 05:36 PM, Nikola Ciprich wrote:
I think although the long term plan is to just do this update once in
your case (stable tsc), this update is needed.
Why don't you send a patch to re-include it ?
Yes, I'll gladly submit patch, one question, is this OK
to just add calling
On 03/04/2011 05:36 PM, Nikola Ciprich wrote:
I think although the long term plan is to just do this update once in
your case (stable tsc), this update is needed.
Why don't you send a patch to re-include it ?
Yes, I'll gladly submit patch, one question, is this OK
to just add calling
On 03/03/2011 02:06 AM, Nikola Ciprich wrote:
No worries. What mess?
twice sending the same mail, nevermind :)
I have two things you can try:
first is running a single VCPU guest, if you have not done so already.
yup, UP guest is fine, just SMP doesn't work.
Second is
On 03/03/2011 04:06 PM, Nikola Ciprich wrote:
What is the exact kernel version you are using in the guest.
It's latest centos (2.6.18-194.32.1.el5), so I guess there are a lot
of fixes, but it's possible the kvm-clock is broken in it.
I can't influence what kernel is used there (at least
(resend, sorry for the mess)
No worries. What mess?
I have two things you can try:
first is running a single VCPU guest, if you have not done so already.
Second is adding the bootparameter clocksource=acpi_pm to your guest
kernel.
If either of those fixes the problem, it very well
On 02/27/2011 12:20 PM, Nikola Ciprich wrote:
I was not aware of the thread. Please cc me directly, or add a keyword
I track - timekeeping, TSC..
Hello Zachary, thanks for Your time looking at this!
That change alone may not bisect well; without further fixes on top of
it, you may
On 02/28/2011 09:32 AM, Nikola Ciprich wrote:
Does the bug you are hitting manifest on both Intel and AMD platforms?
I don't have any AMD box here, I'll try this out at my home box.
Further, do the systems you are hitting this on have stable or unstable
TSCs?
how do I find
On Mon, Feb 28, 2011 at 10:17:24AM -0500, Zachary Amsden wrote:
On 02/28/2011 09:32 AM, Nikola Ciprich wrote:
Does the bug you are hitting manifest on both Intel and AMD platforms?
I don't have any AMD box here, I'll try this out at my home box.
Further, do
c285545f813d7b0ce989fd34e42ad1fe785dc65d
Author: Zachary Amsden zams...@redhat.com
Date: Sat Sep 18 14:38:15 2010 -1000
KVM: x86: TSC catchup mode
Negate the effects of AN TYM spell while kvm thread is preempted by
tracking
conversion factor to the highest TSC rate and catching the TSC up
when it has
On 02/21/2011 12:28 PM, Roedel, Joerg wrote:
On Sun, Feb 13, 2011 at 10:19:19AM -0500, Avi Kivity wrote:
On 02/09/2011 07:29 PM, Joerg Roedel wrote:
Hi Avi, Marcelo,
here is the patch-set to implement the TSC-scaling feature of upcoming
AMD CPUs. When this feature is supported the
On 02/09/2011 12:29 PM, Joerg Roedel wrote:
With TSC scaling in SVM the tsc-offset needs to be
calculated differently. This patch propagates this
calculation into the architecture specific modules so that
this complexity can be handled there.
Signed-off-by: Joerg Roedeljoerg.roe...@amd.com
---
On 02/07/2011 06:35 AM, Jan Kiszka wrote:
On 2011-02-04 22:03, Zachary Amsden wrote:
On 02/04/2011 04:49 AM, Jan Kiszka wrote:
Code under this lock requires non-preemptibility. Ensure this also over
-rt by converting it to raw spinlock.
Oh dear, I had forgotten about
On 02/07/2011 10:00 AM, Jan Kiszka wrote:
On 2011-02-07 15:11, Zachary Amsden wrote:
On 02/07/2011 06:35 AM, Jan Kiszka wrote:
On 2011-02-04 22:03, Zachary Amsden wrote:
On 02/04/2011 04:49 AM, Jan Kiszka wrote:
Code under this lock requires non-preemptibility
On 02/04/2011 04:49 AM, Jan Kiszka wrote:
Code under this lock requires non-preemptibility. Ensure this also over
-rt by converting it to raw spinlock.
Oh dear, I had forgotten about that. I believe kvm_lock might have the
same assumption in a few places regarding clock.
--
To
On 01/14/2011 06:00 AM, Juan Quintela wrote:
Marcelo Tosattimtosa...@redhat.com wrote:
On Fri, Jan 07, 2011 at 10:44:20AM -1000, Zachary Amsden wrote:
On 01/07/2011 12:48 AM, Marcelo Tosatti wrote:
On Thu, Jan 06, 2011 at 12:10:45AM -1000, Zachary Amsden wrote
On 01/07/2011 01:23 AM, Marcelo Tosatti wrote:
On Thu, Jan 06, 2011 at 12:10:44AM -1000, Zachary Amsden wrote:
Reasons to trap the TSC are numerous, but we want to avoid it as much
as possible for performance reasons.
We provide two conservative modes via modules parameters and userspace
On 01/07/2011 12:48 AM, Marcelo Tosatti wrote:
On Thu, Jan 06, 2011 at 12:10:45AM -1000, Zachary Amsden wrote:
Use an MSR to allow soft migration to hosts which do not support
TSC trapping. Rather than make this a required element of any
migration protocol, we allow the TSC rate
On top of my last patchset, I now implement TSC trapping and
a flexible migration scheme for maintaining stable TSC across
migration. Since it is administratively configured, it can
be selectively enabled only for VMs which require it. In
particular, VMs which use KVM clock probably do not want
On 01/06/2011 12:34 AM, Alexander Graf wrote:
Am 06.01.2011 um 11:10 schrieb Zachary Amsdenzams...@redhat.com:
Use an MSR to allow soft migration to hosts which do not support
TSC trapping. Rather than make this a required element of any
migration protocol, we allow the TSC rate to be
On 01/06/2011 12:41 AM, Alexander Graf wrote:
Am 06.01.2011 um 11:10 schrieb Zachary Amsdenzams...@redhat.com:
Reasons to trap the TSC are numerous, but we want to avoid it as much
as possible for performance reasons.
We provide two conservative modes via modules parameters and userspace
On 01/06/2011 01:32 AM, Avi Kivity wrote:
On 01/06/2011 12:10 PM, Zachary Amsden wrote:
Reasons to trap the TSC are numerous, but we want to avoid it as much
as possible for performance reasons.
We provide two conservative modes via modules parameters and userspace
hinting. First, the module
On 01/06/2011 01:38 AM, Alexander Graf wrote:
On 06.01.2011, at 12:30, Zachary Amsden wrote:
On 01/06/2011 12:41 AM, Alexander Graf wrote:
Am 06.01.2011 um 11:10 schrieb Zachary Amsdenzams...@redhat.com:
Reasons to trap the TSC are numerous, but we want to avoid
On 01/06/2011 01:40 AM, Alexander Graf wrote:
On 06.01.2011, at 12:27, Zachary Amsden wrote:
On 01/06/2011 12:34 AM, Alexander Graf wrote:
Am 06.01.2011 um 11:10 schrieb Zachary Amsdenzams...@redhat.com:
Use an MSR to allow soft migration to hosts which do not support
TSC
On 01/06/2011 12:38 PM, Alexander Graf wrote:
snip
Sure, I'm not saying your patch is bad or goes in the wrong direction. I'd just
think it'd be awesome to have an easy way for the guest OS to know that
something as crucial as TSC reading speed got changed, hopefully even TSC
frequency.
On 01/04/2011 08:20 AM, Marcelo Tosatti wrote:
On Tue, Dec 28, 2010 at 07:38:20PM -1000, Zachary Amsden wrote:
On systems with synchronized TSCs, we still have VCPU individual
KVM clocks, each with their own computed offset. As this all happens
at different times, the computed KVM clock
On 01/04/2011 05:36 AM, Marcelo Tosatti wrote:
On Tue, Dec 28, 2010 at 07:38:18PM -1000, Zachary Amsden wrote:
During a host suspend, TSC may go backwards, which KVM interprets
as an unstable TSC. Technically, KVM should not be marking the
TSC unstable, which causes the TSC clocksource
A further set of improvements to KVM clock. Now it actually can
stay synchronized on SMP systems with a stable TSC, does not get
destabilized by host suspend, and is resistant to migration.
I did look a bit into the second to last remaining migration issue;
that is, we read the TSCs for all
Rather than use the host CPU TSC rate, which can change, compute
cycle to nanosecond conversion in the guest TSC rate, which is
fixed. This allows the math for write compensation detection
to be made more reliable.
Signed-off-by: Zachary Amsden zams...@redhat.com
---
arch/x86/kvm/x86.c | 58
During a host suspend, TSC may go backwards, which KVM interprets
as an unstable TSC. Technically, KVM should not be marking the
TSC unstable, which causes the TSC clocksource to go bad, but
should be adjusting the TSC offsets in such a case.
Signed-off-by: Zachary Amsden zams...@redhat.com
compare to ensure it does not happen.
This change should remove that requirement.
Signed-off-by: Zachary Amsden zams...@redhat.com
---
arch/x86/include/asm/kvm_host.h |1 +
arch/x86/kvm/x86.c | 42 ++-
2 files changed, 42 insertions(+), 1
On 12/19/2010 08:16 PM, Avi Kivity wrote:
On 12/20/2010 03:15 AM, Zachary Amsden wrote:
On 12/19/2010 05:27 AM, Avi Kivity wrote:
On 12/17/2010 07:43 PM, Zachary Amsden wrote:
On 12/15/2010 10:16 AM, Julien Desfossez wrote:
Hi,
I'm currently working with the kvm clocksource and I'm
On 12/19/2010 05:27 AM, Avi Kivity wrote:
On 12/17/2010 07:43 PM, Zachary Amsden wrote:
On 12/15/2010 10:16 AM, Julien Desfossez wrote:
Hi,
I'm currently working with the kvm clocksource and I'm wondering if
we could implement the vread function for this clock source when we
are running
On 12/15/2010 10:16 AM, Julien Desfossez wrote:
Hi,
I'm currently working with the kvm clocksource and I'm wondering if we
could implement the vread function for this clock source when we are
running on a host with constant_tsc.
If I understand correctly the hv_clock structure is per_cpu
On 11/29/2010 06:35 AM, Avi Kivity wrote:
On 11/29/2010 06:33 PM, Randy Dunlap wrote:
On Mon, 22 Nov 2010 13:26:27 -0800 Randy Dunlap wrote:
On Mon, 22 Nov 2010 13:49:11 +1100 Stephen Rothwell wrote:
Hi all,
Changes since 20101119:
kvm.c:(.init.text+0x11f49): undefined reference
On 11/29/2010 07:52 AM, Randy Dunlap wrote:
On 11/29/10 09:47, Zachary Amsden wrote:
On 11/29/2010 06:35 AM, Avi Kivity wrote:
On 11/29/2010 06:33 PM, Randy Dunlap wrote:
On Mon, 22 Nov 2010 13:26:27 -0800 Randy Dunlap wrote:
On Mon, 22 Nov 2010 13:49:11 +1100
On 11/15/2010 10:35 PM, Takuya Yoshikawa wrote:
In kvm_cpu_hotplug(), only CPU_STARTING case is protected by kvm_lock.
This patch adds missing protection for CPU_DYING case.
Signed-off-by: Takuya Yoshikawayoshikawa.tak...@oss.ntt.co.jp
---
virt/kvm/kvm_main.c |2 ++
1 files changed, 2
On 11/17/2010 04:04 PM, Takuya Yoshikawa wrote:
(2010/11/18 10:59), Zachary Amsden wrote:
On 11/15/2010 10:35 PM, Takuya Yoshikawa wrote:
In kvm_cpu_hotplug(), only CPU_STARTING case is protected by kvm_lock.
This patch adds missing protection for CPU_DYING case.
Signed-off-by: Takuya
On 11/17/2010 04:41 PM, Takuya Yoshikawa wrote:
(2010/11/18 11:33), Zachary Amsden wrote:
On 11/17/2010 04:04 PM, Takuya Yoshikawa wrote:
(2010/11/18 10:59), Zachary Amsden wrote:
On 11/15/2010 10:35 PM, Takuya Yoshikawa wrote:
In kvm_cpu_hotplug(), only CPU_STARTING case is protected
On 10/21/2010 09:49 AM, Lucas Meneghel Rodrigues wrote:
Hi folks,
I was doing some work at one of our host machines, the one that runs
upstream (Fedora 14, kvm.git as the kernel and qemu-kvm.git as
userspace), and I noticed the kernel message:
kvm: unreliable cycle conversion on adjustable
On 10/17/2010 12:16 AM, Nadav Har'El wrote:
In the unlikely case that L1 does not capture MSR_IA32_TSC, L0 needs to
emulate this MSR write by L2 by modifying vmcs02.tsc_offset.
We also need to set vmcs12.tsc_offset, for this change to survive the next
nested entry (see prepare_vmcs02()).
On 10/08/2010 10:59 PM, Arjan Koers wrote:
On 2010-10-09 08:29, Michael Tokarev wrote:
...
The result is that no released linux kernel boots
in smp in kvm, which is a linux virtual machine.
That's irony, isn't it?
I wonder how distributions (which are almost all based
on 2.6.32 nowadays)
On 10/08/2010 03:10 PM, Arjan Koers wrote:
On 2010-10-09 00:06, Marcelo Tosatti wrote:
On Thu, Oct 07, 2010 at 04:47:11PM -1000, Zachary Amsden wrote:
On 10/07/2010 02:12 PM, Arjan Koers wrote:
On 2010-10-03 01:42, Zachary Amsden wrote:
...
Umm... do you guys
On 10/08/2010 03:10 PM, Arjan Koers wrote:
On 2010-10-09 00:06, Marcelo Tosatti wrote:
On Thu, Oct 07, 2010 at 04:47:11PM -1000, Zachary Amsden wrote:
On 10/07/2010 02:12 PM, Arjan Koers wrote:
On 2010-10-03 01:42, Zachary Amsden wrote:
...
Umm... do you guys
On 10/07/2010 02:12 PM, Arjan Koers wrote:
On 2010-10-03 01:42, Zachary Amsden wrote:
...
Umm... do you guys have this commit? This is supposed to address the
issue where the guest keeps resetting the TSC. A guest which does that
will break kvmclock. It only happens on SMP, and it's
On 10/04/2010 06:50 AM, Glauber Costa wrote:
Zach,
vcpu-hv_clock.tsc_timestamp = tsc_timestamp;
vcpu-hv_clock.system_time = kernel_ns + v-kvm-arch.kvmclock_offset;
vcpu-last_kernel_ns = kernel_ns;= (1)
vcpu-last_guest_tsc = tsc_timestamp;
On 10/01/2010 09:35 PM, Michael Tokarev wrote:
02.10.2010 09:35, Zachary Amsden wrote:
[]
Can you try this patch to see if it helps? I believe it is also safe
for Xen, but cc'ing to double check.
It makes no visible difference.
For some reason one of my test guests - 2.6.35.6 32bit
30, 2010, Zachary Amsden wrote about Re: TSC in nested SVM and
VMX:
1) When reading an MSR, we are not emulating the L2 guest; we are
DIRECTLY reading the MSR for the L1 emulation. Any emulation of the L2
guest is actually done by the code running /inside/ the L1 emulation, so
MSR
On 10/02/2010 06:10 AM, Arjan Koers wrote:
On 2010-10-02 09:35, Michael Tokarev wrote:
02.10.2010 09:35, Zachary Amsden wrote:
[]
Can you try this patch to see if it helps? I believe it is also safe
for Xen, but cc'ing to double check.
It makes no visible difference
On 10/01/2010 04:46 AM, Alexander Graf wrote:
On 01.10.2010, at 13:21, Nadav Har'El wrote:
On Thu, Sep 30, 2010, Zachary Amsden wrote about Re: TSC in nested SVM and
VMX:
1) When reading an MSR, we are not emulating the L2 guest; we are
DIRECTLY reading the MSR for the L1
are enabled.
Signed-off-by: Zachary Amsden zams...@redhat.com
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 8b3bfc4..40a383b 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -351,6 +351,8 @@ notrace static void __cpuinit start_secondary(void *unused
On 09/29/2010 11:59 PM, Michael Tokarev wrote:
30.09.2010 11:55, Michael Tokarev wrote:
29.09.2010 23:26, Arjan Koers wrote:
On 2010-09-29 11:19, Michael Tokarev wrote:
29.09.2010 13:17, Michael Tokarev wrote:
[]
Avi, this is definitely a -stable material,
On 09/30/2010 01:07 PM, Michael Tokarev wrote:
01.10.2010 03:02, Michael Tokarev wrote:
30.09.2010 23:05, Marcelo Tosatti wrote:
[]
Arjan, Michael, can you try the following:
From 3823c018162dc708b543cbdc680a4c7d63533fee Mon Sep 17 00:00:00 2001
From: Zachary
On 09/30/2010 12:50 PM, Nadav Har'El wrote:
Hi,
I noticed that the TSC handling code has recently changed, and since it
wasn't done correctly in the nested VMX patch, I wanted to take the opportunity
to fix it.
I looked at what nested SVM does about TSC, and most of it I think I
understand,
On 09/20/2010 05:38 AM, Marcelo Tosatti wrote:
On Sat, Sep 18, 2010 at 02:38:15PM -1000, Zachary Amsden wrote:
Negate the effects of AN TYM spell while kvm thread is preempted by tracking
conversion factor to the highest TSC rate and catching the TSC up when it has
fallen behind the kernel
On 09/17/2010 12:31 PM, Zachary Amsden wrote:
On 09/17/2010 12:09 PM, Zachary Amsden wrote:
On 09/15/2010 08:27 AM, Jan Kiszka wrote:
Am 15.09.2010 14:32, Glauber Costa wrote:
On Wed, Sep 15, 2010 at 10:09:33AM +0200, Jan Kiszka wrote:
In any case, I'll proceed with the forcing of unstable
).
For now, this patch is sufficient to get things working again for me.
commit 1abe7e8806fd71ea802c6622ed3ce7821a18f271
Author: Zachary Amsden zams...@redhat.com
Date: Sat Sep 18 13:58:37 2010 -1000
Fix kvmclock bug
If preempted after kvmclock values are updated, but before hardware
last_tsc to the newly read tsc value so
that any computed nsec advance of kvmclock is nulled.
Signed-off-by: Zachary Amsden zams...@redhat.com
---
arch/x86/kvm/x86.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index a51635e
care to avoid an arithmetic overflow
when scaling up the tps32 value (this could not happen
with the fixed scaled value of NSEC_PER_SEC, but can
happen with scaled rates above 2^31.
Signed-off-by: Zachary Amsden zams...@redhat.com
---
arch/x86/kvm/x86.c | 30 ++
1 files
of this is possible, which only does catchup
when TSC rate drops, and which specifically targets only CPUs with broken
TSC, but since these all are considered unstable_tsc(), this patch covers
all necessary cases.
Signed-off-by: Zachary Amsden zams...@redhat.com
---
arch/x86/include/asm/kvm_host.h |6
Working on an older Fedora, I hit the need for this..
Add missing MSR definition
Signed-off-by: Zachary Amsden zams...@redhat.com
diff --git a/x86/external-module-compat.h b/x86/external-module-compat.h
index cc51b0f..8cb936d 100644
--- a/x86/external-module-compat.h
+++ b/x86/external-module
On 09/15/2010 08:27 AM, Jan Kiszka wrote:
Am 15.09.2010 14:32, Glauber Costa wrote:
On Wed, Sep 15, 2010 at 10:09:33AM +0200, Jan Kiszka wrote:
In any case, I'll proceed with the forcing of unstable TSC and HPET
clocksource and see what happens.
I tried that before, but it
On 09/17/2010 12:09 PM, Zachary Amsden wrote:
On 09/15/2010 08:27 AM, Jan Kiszka wrote:
Am 15.09.2010 14:32, Glauber Costa wrote:
On Wed, Sep 15, 2010 at 10:09:33AM +0200, Jan Kiszka wrote:
In any case, I'll proceed with the forcing of unstable TSC and HPET
clocksource and see what happens
On 09/14/2010 12:40 AM, Jan Kiszka wrote:
Am 14.09.2010 11:27, Avi Kivity wrote:
On 09/14/2010 11:10 AM, Jan Kiszka wrote:
Am 20.08.2010 10:07, Zachary Amsden wrote:
When CPUs with unstable TSCs enter deep C-state, TSC may stop
running. This causes us to require
On 09/14/2010 12:26 PM, Jan Kiszka wrote:
Am 14.09.2010 21:32, Zachary Amsden wrote:
On 09/14/2010 12:40 AM, Jan Kiszka wrote:
Am 14.09.2010 11:27, Avi Kivity wrote:
On 09/14/2010 11:10 AM, Jan Kiszka wrote:
Am 20.08.2010 10:07, Zachary Amsden wrote
1 - 100 of 377 matches
Mail list logo
