On Wed, Aug 25, 2010 at 07:01:34PM -0300, Marcelo Tosatti wrote:
On Wed, Aug 25, 2010 at 10:48:20AM -1000, Zachary Amsden wrote:
On 08/25/2010 07:27 AM, Marcelo Tosatti wrote:
On Thu, Aug 19, 2010 at 10:07:39PM -1000, Zachary Amsden wrote:
Make the clock update handler handle generic clock
On Thu, Aug 19, 2010 at 10:07:15PM -1000, Zachary Amsden wrote:
This is used only by the VMX code, and is not done properly;
if the TSC is indeed backwards, it is out of sync, and will
need proper handling in the logic at each and every CPU change.
For now, drop this test during init as
On Thu, Aug 19, 2010 at 10:07:17PM -1000, Zachary Amsden wrote:
Also, ensure that the storing of the offset and the reading of the TSC
are never preempted by taking a spinlock. While the lock is overkill
now, it is useful later in this patch series.
+ spinlock_t tsc_write_lock;
Forgive
On Thu, Aug 19, 2010 at 10:07:19PM -1000, Zachary Amsden wrote:
The VMCB is reset whenever we receive a startup IPI, so Linux is setting
TSC back to zero happens very late in the boot process and destabilizing
the TSC. Instead, just set TSC to zero once at VCPU creation time.
Why the
On Thu, Aug 19, 2010 at 10:07:22PM -1000, Zachary Amsden wrote:
If creating an SMP guest with unstable host TSC, issue a warning
Signed-off-by: Zachary Amsden zams...@redhat.com
Ok, I am not sure I agree 100 % this is needed.
I believe we should try to communicate this kind of thing to the
On Thu, Aug 19, 2010 at 10:07:24PM -1000, Zachary Amsden wrote:
When CPUs with unstable TSCs enter deep C-state, TSC may stop
running. This causes us to require resynchronization. Since
we can't tell when this may potentially happen, we assume the
worst by forcing re-compensation for it at
On Thu, Aug 19, 2010 at 10:07:25PM -1000, Zachary Amsden wrote:
Add a helper function to compute the kernel time and convert nanoseconds
back to CPU specific cycles. Note that these must not be called in
preemptible
context, as that would mean the kernel could enter software suspend state,
On Thu, Aug 19, 2010 at 10:07:26PM -1000, Zachary Amsden wrote:
Make the match of TSC find TSC writes that are close to each other
instead of perfectly identical; this allows the compensator to also
work in migration / suspend scenarios.
Signed-off-by: Zachary Amsden zams...@redhat.com
---
On Thu, Aug 19, 2010 at 10:07:47PM -1000, Zachary Amsden wrote:
When no platform bugs have been detected, no TSC warps have been
detected, and the hardware guarantees to us TSC does not change
rate or stop with P-state or C-state changes, we can consider it reliable.
Signed-off-by: Zachary
On Thu, Aug 19, 2010 at 10:07:33PM -1000, Zachary Amsden wrote:
Basic informational document about x86 timekeeping and how KVM
is affected.
Signed-off-by: Zachary Amsden zams...@redhat.com
This can probably be merged right now.
--
To unsubscribe from this list: send the line unsubscribe kvm
On Thu, Aug 19, 2010 at 10:07:44PM -1000, Zachary Amsden wrote:
Add an IOCTL for setting the TSC rate for a VM, intended to
be used to migrate non-kvmclock based VMs which rely on TSC
rate staying stable across host migration.
Signed-off-by: Zachary Amsden zams...@redhat.com
---
On Sat, Jul 31, 2010 at 01:55:10PM -1000, Zachary Amsden wrote:
On 07/31/2010 06:36 AM, Arjan Koers wrote:
On 2010-07-31 13:53, Arjan Koers wrote:
The kernel boots successfully when CONFIG_PRINTK_TIME is not set.
The problem occurs when this message is printed:
[0.016000] kvm-clock:
On Mon, Aug 02, 2010 at 06:16:16PM +0200, Arjan Koers wrote:
On 2010-08-02 16:43, Glauber Costa wrote:
On Sat, Jul 31, 2010 at 01:55:10PM -1000, Zachary Amsden wrote:
On 07/31/2010 06:36 AM, Arjan Koers wrote:
On 2010-07-31 13:53, Arjan Koers wrote:
The kernel boots successfully when
On Mon, Aug 02, 2010 at 10:26:30AM -1000, Zachary Amsden wrote:
On 08/02/2010 04:43 AM, Glauber Costa wrote:
On Sat, Jul 31, 2010 at 01:55:10PM -1000, Zachary Amsden wrote:
On 07/31/2010 06:36 AM, Arjan Koers wrote:
On 2010-07-31 13:53, Arjan Koers wrote:
The kernel boots successfully when
On Mon, Jun 14, 2010 at 09:34:03PM -1000, Zachary Amsden wrote:
Move duplicated timer related code into arch_vcpu_load rather
than vendor callouts. Should be an isomorphic transformation.
Signed-off-by: Zachary Amsden zams...@redhat.com
Acked-by: Glauber Costa glom...@redhat.com
On Wed, Jun 16, 2010 at 04:10:10PM +0800, Jason Wang wrote:
Zachary Amsden wrote:
void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
{
+ kvm_x86_ops-vcpu_load(vcpu, cpu);
if (unlikely(vcpu-cpu != cpu)) {
+ /* Make sure TSC doesn't go backwards */
+
On Mon, Jun 14, 2010 at 09:34:06PM -1000, Zachary Amsden wrote:
When CPUs with unstable TSCs enter deep C-state, TSC may stop
running. This causes us to require resynchronization. Since
we can't tell when this may potentially happen, we assume the
worst by forcing re-compensation for it at
On Mon, Jun 14, 2010 at 09:34:07PM -1000, Zachary Amsden wrote:
SMP VMs on machines with unstable TSC have their TSC offset adjusted by the
local offset delta from last measurement. This does not take into account how
long it has been since the measurement, leading to drift. Minimize the
On Mon, Jun 14, 2010 at 09:34:18PM -1000, Zachary Amsden wrote:
Attempt to synchronize TSCs which are reset to the same value. In the
case of a reliable hardware TSC, we can just re-use the same offset, but
on non-reliable hardware, we can get closer by adjusting the offset to
match the
On Wed, Jun 16, 2010 at 04:11:26PM +0800, Jason Wang wrote:
Zachary Amsden wrote:
Kernel time, which advances in discrete steps may progress much slower
than TSC. As a result, when kvmclock is adjusted to a new base, the
apparent time to the guest, which runs at a much higher, nsec scaled
On Wed, Jun 16, 2010 at 04:12:46PM +0800, Jason Wang wrote:
Zachary Amsden wrote:
On 06/14/2010 10:41 PM, Avi Kivity wrote:
On 06/15/2010 10:34 AM, Zachary Amsden wrote:
Add a helper function for the multiple places this is used. Note
that it
must not be called in
On Wed, Jun 16, 2010 at 05:13:02PM +0300, Avi Kivity wrote:
On 06/16/2010 04:58 PM, Glauber Costa wrote:
On Wed, Jun 16, 2010 at 04:11:26PM +0800, Jason Wang wrote:
Zachary Amsden wrote:
Kernel time, which advances in discrete steps may progress much slower
than TSC. As a result, when
This patch adds initial support for the -machine option, that allows
command line specification of machine attributes.
Besides its value per-se, it is the saner way we found to
allow for enabling/disabling of kvm's in-kernel irqchip.
machine-related options like kernel, initrd, etc, are now
This patch adds a file that documents the usage of KVM-specific
MSRs.
[ v2: added comments from Randy ]
[ v3: added comments from Avi ]
[ v4: added information about wallclock alignment ]
Signed-off-by: Glauber Costa glom...@redhat.com
Reviewed-by: Randy Dunlap randy.dun...@oracle.com
On Tue, Jun 01, 2010 at 03:33:43PM +0300, Avi Kivity wrote:
Accept a CPUState parameter instead of a kvm_context_t.
Signed-off-by: Avi Kivity a...@redhat.com
Acked-by: Glauber Costa glom...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message
On Tue, Jun 01, 2010 at 03:33:44PM +0300, Avi Kivity wrote:
Signed-off-by: Avi Kivity a...@redhat.com
Acked-by: Glauber Costa glom...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
On Tue, Jun 01, 2010 at 03:33:45PM +0300, Avi Kivity wrote:
Be more similar to upstream.
Signed-off-by: Avi Kivity a...@redhat.com
Acked-by: Glauber Costa glom...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
On Tue, Jun 01, 2010 at 03:33:46PM +0300, Avi Kivity wrote:
Currently all content from qemu-kvm's kvm_arch_init_vcpu().
Signed-off-by: Avi Kivity a...@redhat.com
Acked-by: Glauber Costa glom...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message
On Tue, Jun 01, 2010 at 03:33:47PM +0300, Avi Kivity wrote:
Signed-off-by: Avi Kivity a...@redhat.com
Acked-by: Glauber Costa glom...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
On Sun, May 30, 2010 at 12:14:21PM +0300, Avi Kivity wrote:
On 05/27/2010 07:02 PM, Glauber Costa wrote:
+
+Custom MSR list
+
+
+The current supported Custom MSR list is:
+
+MSR_KVM_WALL_CLOCK: 0x11
+
+ data: physical address of a memory area.
Which must be in guest RAM (i.e
On Thu, May 27, 2010 at 11:15:43AM +0300, Avi Kivity wrote:
On 05/26/2010 09:04 PM, Glauber Costa wrote:
This patch adds a file that documents the usage of KVM-specific
MSRs.
Looks good. A few comments:
+
+Custom MSR list
+
+
+The current supported Custom MSR list
This patch adds a file that documents the usage of KVM-specific
MSRs.
[ v2: added comments from Randy ]
[ v2: added comments from Avi ]
Signed-off-by: Glauber Costa glom...@redhat.com
---
Documentation/kvm/msr.txt | 152 +
1 files changed, 152
On Thu, May 27, 2010 at 10:13:12AM -1000, Zachary Amsden wrote:
On 05/27/2010 06:02 AM, Glauber Costa wrote:
On Thu, May 27, 2010 at 11:15:43AM +0300, Avi Kivity wrote:
On 05/26/2010 09:04 PM, Glauber Costa wrote:
This patch adds a file that documents the usage of KVM-specific
MSRs.
Looks
On Thu, May 27, 2010 at 11:02:35AM -1000, Zachary Amsden wrote:
On 05/27/2010 10:36 AM, Glauber Costa wrote:
On Thu, May 27, 2010 at 10:13:12AM -1000, Zachary Amsden wrote:
On 05/27/2010 06:02 AM, Glauber Costa wrote:
On Thu, May 27, 2010 at 11:15:43AM +0300, Avi Kivity wrote:
On 05/26/2010
This patch adds a file that documents the usage of KVM-specific
MSRs.
Signed-off-by: Glauber Costa glom...@redhat.com
---
Documentation/kvm/msr.txt | 115 +
1 files changed, 115 insertions(+), 0 deletions(-)
create mode 100644 Documentation/kvm
On Wed, May 26, 2010 at 11:35:03AM -0700, Randy Dunlap wrote:
On Wed, 26 May 2010 14:04:48 -0400 Glauber Costa wrote:
Thanks Randy.
Update version will follow.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo
This patch adds a file that documents the usage of KVM-specific
MSRs.
[ v2: added comments from Randy ]
Signed-off-by: Glauber Costa glom...@redhat.com
---
Documentation/kvm/msr.txt | 117 +
1 files changed, 117 insertions(+), 0 deletions(-)
create
On Mon, May 17, 2010 at 09:38:30AM -1000, Zachary Amsden wrote:
On 05/17/2010 05:36 AM, Glauber Costa wrote:
On Fri, May 14, 2010 at 04:07:43PM -1000, Zachary Amsden wrote:
I believe this fixes the root cause of the kvmclock warp. It's
quite a plausible phenomenon, and explains why it was so
On Fri, May 14, 2010 at 04:07:43PM -1000, Zachary Amsden wrote:
I believe this fixes the root cause of the kvmclock warp. It's
quite a plausible phenomenon, and explains why it was so easy to
produce.
You mean this is the case for both SMP and UP, or just UP as we talked
before?
I don't get
On Wed, May 12, 2010 at 07:47:39AM +0200, Alexander Graf wrote:
On 12.05.2010, at 05:33, Zachary Amsden wrote:
On 05/11/2010 06:17 AM, Glauber Costa wrote:
This is the fourth version ov kvmclock fixes.
Just two minor changes in patch 5, per avi request, and
the addition
This is the fourth version ov kvmclock fixes.
Just two minor changes in patch 5, per avi request, and
the addition of cpuid.txt file, documenting all cpuid flags
we use.
As a side effect, this patch removes the time-travel feature
in kvm guests.
Glauber Costa (9):
Enable pvclock flags
should be taken into consideration. Which flags are valid
are usually devised via HV negotiation.
Signed-off-by: Glauber Costa glom...@redhat.com
CC: Jeremy Fitzhardinge jer...@goop.org
---
arch/x86/include/asm/pvclock-abi.h |3 ++-
arch/x86/include/asm/pvclock.h |1 +
arch/x86/kernel
in KVM_GET_SUPPORTED_CPUID.
This makes userspace automatically aware of what we provide. And if we
ever add a new cpuid bit in the future, we have to do that again,
which create some complexity and delay in feature adoption.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/kvm/x86.c | 34
-existant MSR, we raise a lethal #GP, since our
idt handlers are not in place yet.
So this patch tests for a cpuid feature exported by the host to
decide which set of msrs are supported.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/kernel/kvmclock.c | 53
This file documents cpuid bits used by KVM.
Signed-off-by: Glauber Costa glom...@redhat.com
---
Documentation/kvm/cpuid.txt | 44 +++
1 files changed, 44 insertions(+), 0 deletions(-)
create mode 100644 Documentation/kvm/cpuid.txt
diff --git
This patch puts up the flag that tells the guest that we'll warn it
about the tsc being trustworthy or not. By now, we also say
it is not.
---
arch/x86/kvm/x86.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index
If the HV told us we can fully trust the TSC, skip any
correction
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/include/asm/kvm_para.h|5 +
arch/x86/include/asm/pvclock-abi.h |1 +
arch/x86/kernel/kvmclock.c |3 +++
arch/x86/kernel/pvclock.c
This cpuid, KVM_CPUID_CLOCKSOURCE2, will indicate to the guest
that kvmclock is available through a new set of MSRs. The old ones
are deprecated.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/include/asm/kvm_para.h |4
1 files changed, 4 insertions(+), 0 deletions
Avi pointed out a while ago that those MSRs falls into the pentium
PMU range. So the idea here is to add new ones, and after a while,
deprecate the old ones.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/include/asm/kvm_para.h |4
arch/x86/kvm/x86.c |7
source guaranteed to be stable wrt time warps.
After this patch is applied, I don't see a single warp in time during 5 days
of execution, in any of the machines I saw them before.
Signed-off-by: Glauber Costa glom...@redhat.com
CC: Jeremy Fitzhardinge jer...@goop.org
CC: Avi Kivity
On Wed, May 05, 2010 at 10:26:43AM +0300, Avi Kivity wrote:
+msr_data.info.nmsrs = n;
+
+return kvm_vcpu_ioctl(env, KVM_SET_MSRS,msr_data);
+}
+
+
How about a different approach? Query the supported MSRs
(KVM_GET_MSR_LIST or thereabout) and reset them (with special cases
for
On Wed, May 05, 2010 at 06:34:22PM +0300, Avi Kivity wrote:
On 05/05/2010 06:24 PM, Glauber Costa wrote:
On Wed, May 05, 2010 at 10:26:43AM +0300, Avi Kivity wrote:
+msr_data.info.nmsrs = n;
+
+return kvm_vcpu_ioctl(env, KVM_SET_MSRS,msr_data);
+}
+
+
How about a different
Hi,
Avi, in this patch, I am resetting all msrs upon CPU reset.
Hope it is better. Patch 1 is yet another cleanup.
Glauber Costa (2):
change header for kvm_get_msr_list
turn off kvmclock when resetting cpu
qemu-kvm-x86.c | 27 +--
qemu-kvm.h |1 -
2 files
MSR list.
This patch fixes the issue for me.
Signed-off-by: Glauber Costa glom...@redhat.com
---
qemu-kvm-x86.c | 23 +++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/qemu-kvm-x86.c b/qemu-kvm-x86.c
index 5a2b552..bd74316 100644
--- a/qemu-kvm-x86.c
+++ b
On Wed, May 05, 2010 at 10:33:52AM -1000, Zachary Amsden wrote:
On 05/05/2010 09:19 AM, Glauber Costa wrote:
Currently, in the linux kernel, we reset kvmclock if we are rebooting
into a crash kernel through kexec. The rationale, is that a new kernel
won't follow the same memory addresses
Hello,
Avi, this version fixes the issues you raised in the last
review. Hopte it is better now.
A cpuid.txt wil follow as soon as we're set on everything, so
I am not including it yet.
Glauber Costa (8):
Enable pvclock flags in vcpu_time_info structure
Add a global synchronization point
source guaranteed to be stable wrt time warps.
After this patch is applied, I don't see a single warp in time during 5 days
of execution, in any of the machines I saw them before.
Signed-off-by: Glauber Costa glom...@redhat.com
CC: Jeremy Fitzhardinge jer...@goop.org
CC: Avi Kivity
Avi pointed out a while ago that those MSRs falls into the pentium
PMU range. So the idea here is to add new ones, and after a while,
deprecate the old ones.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/include/asm/kvm_para.h |4
arch/x86/kvm/x86.c |7
should be taken into consideration. Which flags are valid
are usually devised via HV negotiation.
Signed-off-by: Glauber Costa glom...@redhat.com
CC: Jeremy Fitzhardinge jer...@goop.org
---
arch/x86/include/asm/pvclock-abi.h |3 ++-
arch/x86/include/asm/pvclock.h |1 +
arch/x86/kernel
This patch puts up the flag that tells the guest that we'll warn it
about the tsc being trustworthy or not. By now, we also say
it is not.
---
arch/x86/kvm/x86.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index
If the HV told us we can fully trust the TSC, skip any
correction
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/include/asm/kvm_para.h|5 +
arch/x86/include/asm/pvclock-abi.h |1 +
arch/x86/kernel/kvmclock.c |3 +++
arch/x86/kernel/pvclock.c
-existant MSR, we raise a lethal #GP, since our
idt handlers are not in place yet.
So this patch tests for a cpuid feature exported by the host to
decide which set of msrs are supported.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/kernel/kvmclock.c | 53
This cpuid, KVM_CPUID_CLOCKSOURCE2, will indicate to the guest
that kvmclock is available through a new set of MSRs. The old ones
are deprecated.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/include/asm/kvm_para.h |4
1 files changed, 4 insertions(+), 0 deletions
On Tue, May 04, 2010 at 03:02:24PM +0300, Avi Kivity wrote:
Wallclock writing uses an unprotected global variable to hold the version;
this can cause one guest to interfere with another if both write their
wallclock at the same time.
makes sense to me.
ACK.
--
To unsubscribe from this
This patch series fixes I bug I just found with kvmclock,
when I booted into a kernel without kvmclock enabled.
Since I am setting msrs, I took the oportunity to
use yet another function from upstream qemu (patch 1).
Enjoy
Glauber Costa (2):
replace set_msr_entry with kvm_msr_entry
turn off
this is yet another function that upstream qemu implements,
so we can just use its implementation.
Signed-off-by: Glauber Costa glom...@redhat.com
---
qemu-kvm-x86.c| 39 ---
target-i386/kvm.c |3 +++
2 files changed, 19 insertions(+), 23 deletions
belongs in qemu, since it is the entity
more prepared to detect all kinds of reboots (by means of a cpu_reset),
not to mention the presence of misbehaving guests, that can forget
to turn kvmclock off.
This patch fixes the issue for me.
Signed-off-by: Glauber Costa glom...@redhat.com
---
qemu-kvm-x86.c
), and starting
to use the flag that indicates possible tsc stability (patch 7/7), although
it is still off by default.
Glauber Costa (7):
Enable pvclock flags in vcpu_time_info structure
Add a global synchronization point for pvclock
change msr numbers for kvmclock
export paravirtual cpuid flags
in KVM_GET_SUPPORTED_CPUID.
This makes userspace automatically aware of what we provide. And if we
ever add a new cpuid bit in the future, we have to do that again,
which create some complexity and delay in feature adoption.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/include/asm/kvm_para.h
This patch puts up the flag that tells the guest that we'll warn it
about the tsc being trustworthy or not. By now, we also say
it is not.
---
arch/x86/kvm/x86.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index
If the HV told us we can fully trust the TSC, skip any
correction
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/include/asm/kvm_para.h|5 +
arch/x86/include/asm/pvclock-abi.h |1 +
arch/x86/kernel/kvmclock.c |3 +++
arch/x86/kernel/pvclock.c
-existant MSR, we raise a lethal #GP, since our
idt handlers are not in place yet.
So this patch tests for a cpuid feature exported by the host to
decide which set of msrs are supported.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/kernel/kvmclock.c | 53
Avi pointed out a while ago that those MSRs falls into the pentium
PMU range. So the idea here is to add new ones, and after a while,
deprecate the old ones.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/include/asm/kvm_para.h |4
arch/x86/kvm/x86.c |7
source guaranteed to be stable wrt time warps.
After this patch is applied, I don't see a single warp in time during 5 days
of execution, in any of the machines I saw them before.
Signed-off-by: Glauber Costa glom...@redhat.com
CC: Jeremy Fitzhardinge jer...@goop.org
CC: Avi Kivity
should be taken into consideration. Which flags are valid
are usually devised via HV negotiation.
Signed-off-by: Glauber Costa glom...@redhat.com
CC: Jeremy Fitzhardinge jer...@goop.org
---
arch/x86/include/asm/pvclock-abi.h |3 ++-
arch/x86/include/asm/pvclock.h |1 +
arch/x86/kernel
On Tue, Apr 27, 2010 at 10:30:48AM -0300, Marcelo Tosatti wrote:
On Mon, Apr 26, 2010 at 01:46:26PM -0400, Glauber Costa wrote:
Since we're changing the msrs kvmclock uses, we have to communicate
that to the guest, through cpuid. We can add a new KVM_CAP to the
hypervisor, and then patch
On Tue, Apr 27, 2010 at 10:40:13AM -0300, Marcelo Tosatti wrote:
On Mon, Apr 26, 2010 at 01:46:28PM -0400, Glauber Costa wrote:
If the HV told us we can fully trust the TSC, skip any
correction
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/include/asm/kvm_para.h
On Tue, Apr 27, 2010 at 10:30:48AM -0300, Marcelo Tosatti wrote:
On Mon, Apr 26, 2010 at 01:46:26PM -0400, Glauber Costa wrote:
Since we're changing the msrs kvmclock uses, we have to communicate
that to the guest, through cpuid. We can add a new KVM_CAP to the
hypervisor, and then patch
On Tue, Apr 27, 2010 at 09:03:55PM +0300, Avi Kivity wrote:
On 04/27/2010 04:40 PM, Marcelo Tosatti wrote:
On Mon, Apr 26, 2010 at 01:46:28PM -0400, Glauber Costa wrote:
If the HV told us we can fully trust the TSC, skip any
correction
Please drop this. Its not certain what is the best
On Tue, Apr 27, 2010 at 09:12:47PM +0300, Avi Kivity wrote:
On 04/26/2010 08:46 PM, Glauber Costa wrote:
Since we're changing the msrs kvmclock uses, we have to communicate
that to the guest, through cpuid. We can add a new KVM_CAP to the
hypervisor, and then patch userspace to recognize
On Tue, Apr 27, 2010 at 09:07:18PM +0300, Avi Kivity wrote:
On 04/26/2010 08:46 PM, Glauber Costa wrote:
This patch removes one padding byte and transform it into a flags
field. New versions of guests using pvclock will query these flags
upon each read.
Flags, however, will only
updates
avi asked for. I haven't yet done any HV work on this
(specially because I am not convinced exactly where it is safe to
do).
Let me know what you think.
Thanks
Glauber Costa (6):
Enable pvclock flags in vcpu_time_info structure
Add a global synchronization point for pvclock
change msr
source guaranteed to be stable wrt time warps.
After this patch is applied, I don't see a single warp in time during 5 days
of execution, in any of the machines I saw them before.
Signed-off-by: Glauber Costa glom...@redhat.com
CC: Jeremy Fitzhardinge jer...@goop.org
CC: Avi Kivity
should be taken into consideration. Which flags are valid
are usually devised via HV negotiation.
Signed-off-by: Glauber Costa glom...@redhat.com
CC: Jeremy Fitzhardinge jer...@goop.org
---
arch/x86/include/asm/pvclock-abi.h |3 ++-
arch/x86/include/asm/pvclock.h |1 +
arch/x86/kernel
If the HV told us we can fully trust the TSC, skip any
correction
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/include/asm/kvm_para.h|5 +
arch/x86/include/asm/pvclock-abi.h |1 +
arch/x86/kernel/kvmclock.c |3 +++
arch/x86/kernel/pvclock.c
-existant MSR, we raise a lethal #GP, since our
idt handlers are not in place yet.
So this patch tests for a cpuid feature exported by the host to
decide which set of msrs are supported.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/kernel/kvmclock.c | 56
userspace untouched.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/include/asm/kvm_para.h |4
arch/x86/kvm/x86.c |6 ++
include/linux/kvm.h |1 +
3 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/x86/include/asm
Avi pointed out a while ago that those MSRs falls into the pentium
PMU range. So the idea here is to add new ones, and after a while,
deprecate the old ones.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/include/asm/kvm_para.h |4
arch/x86/kvm/x86.c |7
On Mon, Apr 26, 2010 at 11:11:57AM -0700, Jeremy Fitzhardinge wrote:
On 04/26/2010 10:46 AM, Glauber Costa wrote:
This patch removes one padding byte and transform it into a flags
field. New versions of guests using pvclock will query these flags
upon each read.
Is this necessary
On Tue, Apr 20, 2010 at 12:42:17PM -0700, Jeremy Fitzhardinge wrote:
On 04/20/2010 11:54 AM, Avi Kivity wrote:
On 04/20/2010 09:23 PM, Jeremy Fitzhardinge wrote:
On 04/20/2010 02:31 AM, Avi Kivity wrote:
btw, do you want this code in pvclock.c, or shall we keep it kvmclock
specific?
should be taken into consideration. Which flags are valid
are usually devised via HV negotiation.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/include/asm/pvclock-abi.h |3 ++-
arch/x86/include/asm/pvclock.h |1 +
arch/x86/kernel/pvclock.c |9 +
3
On Tue, Apr 20, 2010 at 12:35:19PM +0300, Avi Kivity wrote:
On 04/20/2010 04:57 AM, Marcelo Tosatti wrote:
Marcelo can probably confirm it, but he has a nehalem with an appearently
very good tsc source. Even this machine warps.
It stops warping if we only write pvclock data structure once
On Mon, Apr 19, 2010 at 02:10:54PM +0300, Avi Kivity wrote:
On 04/19/2010 02:05 PM, Peter Zijlstra wrote:
ACCESS_ONCE() is your friend.
I think it's implied with atomic64_read().
Yes it would be. I was merely trying to point out that
last = ACCESS_ONCE(last_value);
Is a narrower
On Fri, Apr 16, 2010 at 01:36:34PM -0700, Jeremy Fitzhardinge wrote:
On 04/15/2010 11:37 AM, Glauber Costa wrote:
In recent stress tests, it was found that pvclock-based systems
could seriously warp in smp systems. Using ingo's time-warp-test.c,
I could trigger a scenario as bad as 1.5mi
On Mon, Apr 19, 2010 at 01:19:43PM +0200, Peter Zijlstra wrote:
On Mon, 2010-04-19 at 14:13 +0300, Avi Kivity wrote:
On 04/19/2010 01:56 PM, Peter Zijlstra wrote:
Right, do bear in mind that the x86 implementation of atomic64_read() is
terrifyingly expensive, it is better to not
On Mon, Apr 19, 2010 at 09:19:38AM -0700, Jeremy Fitzhardinge wrote:
On 04/19/2010 07:26 AM, Glauber Costa wrote:
Is the problem that the tscs are starting out of sync, or that they're
drifting relative to each other over time? Do the problems become worse
the longer the uptime? How large
userspace untouched.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/kvm/x86.c |6 ++
include/linux/kvm.h |1 +
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 714aae2..74f0dc3 100644
--- a/arch/x86/kvm/x86.c
+++ b
adds documentation about kvmclock, which to date, we lacked.
Glauber Costa (5):
Add a global synchronization point for pvclock
change msr numbers for kvmclock
Try using new kvm clock msrs
export new cpuid KVM_CAP
add documentation about kvmclock
Documentation/kvm/kvmclock.txt | 138
Avi pointed out a while ago that those MSRs falls into the pentium
PMU range. So the idea here is to add new ones, and after a while,
deprecate the old ones.
Signed-off-by: Glauber Costa glom...@redhat.com
---
arch/x86/include/asm/kvm_para.h |8 ++--
arch/x86/kvm/x86.c
source guaranteed to be stable wrt time warps.
After this patch is applied, I don't see a single warp in time during 5 days
of execution, in any of the machines I saw them before.
Signed-off-by: Glauber Costa glom...@redhat.com
CC: Jeremy Fitzhardinge jer...@goop.org
CC: Avi Kivity
301 - 400 of 951 matches
Mail list logo
