On Wed, Mar 25, 2015 at 04:22:03PM -0700, Andy Lutomirski wrote:
On Wed, Mar 25, 2015 at 4:13 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Wed, Mar 25, 2015 at 03:48:02PM -0700, Andy Lutomirski wrote:
On Wed, Mar 25, 2015 at 3:41 PM, Marcelo Tosatti mtosa...@redhat.com
wrote:
On
2015-03-26 11:51-0700, Andy Lutomirski:
On Thu, Mar 26, 2015 at 4:29 AM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Wed, Mar 25, 2015 at 04:22:03PM -0700, Andy Lutomirski wrote:
Suppose we start out with all vcpus agreeing on their pvti and perfect
invariant TSCs. Now the host updates
On Thu, Mar 26, 2015 at 4:29 AM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Wed, Mar 25, 2015 at 04:22:03PM -0700, Andy Lutomirski wrote:
On Wed, Mar 25, 2015 at 4:13 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Wed, Mar 25, 2015 at 03:48:02PM -0700, Andy Lutomirski wrote:
On Wed,
2015-03-26 11:47-0700, Andy Lutomirski:
On Wed, Mar 25, 2015 at 4:08 AM, Radim Krčmář rkrc...@redhat.com wrote:
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
+ /* A guest can read other VCPU's kvmclock; specification says that
+* version is odd if data is being modified
On Thu, Mar 26, 2015 at 1:31 PM, Radim Krcmar rkrc...@redhat.com wrote:
2015-03-26 11:51-0700, Andy Lutomirski:
On Thu, Mar 26, 2015 at 4:29 AM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Wed, Mar 25, 2015 at 04:22:03PM -0700, Andy Lutomirski wrote:
Suppose we start out with all vcpus
On 26/03/2015 21:10, Radim Krčmář wrote:
2015-03-26 11:47-0700, Andy Lutomirski:
On Wed, Mar 25, 2015 at 4:08 AM, Radim Krčmář rkrc...@redhat.com wrote:
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
+ /* A guest can read other VCPU's kvmclock; specification says that
+*
2015-03-23 20:21-0300, Marcelo Tosatti:
The following point:
2. per-CPU pvclock time info is updated if the
underlying CPU changes.
Is not true anymore since KVM: x86: update pvclock area conditionally,
on cpu migration.
Add task migration notification back.
Problem
On Wed, Mar 25, 2015 at 4:08 AM, Radim Krčmář rkrc...@redhat.com wrote:
2015-03-24 15:33-0700, Andy Lutomirski:
On Tue, Mar 24, 2015 at 8:34 AM, Radim Krčmář rkrc...@redhat.com wrote:
What is the problem?
The kvmclock spec says that the host will increment a version field to
an odd number,
On Thu, Mar 26, 2015 at 4:22 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Thu, Mar 26, 2015 at 04:09:53PM -0700, Andy Lutomirski wrote:
On Thu, Mar 26, 2015 at 3:56 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Thu, Mar 26, 2015 at 01:58:25PM -0700, Andy Lutomirski wrote:
On Thu,
On Thu, Mar 26, 2015 at 04:28:37PM -0700, Andy Lutomirski wrote:
On Thu, Mar 26, 2015 at 4:22 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Thu, Mar 26, 2015 at 04:09:53PM -0700, Andy Lutomirski wrote:
On Thu, Mar 26, 2015 at 3:56 PM, Marcelo Tosatti mtosa...@redhat.com
wrote:
On
On Thu, Mar 26, 2015 at 3:56 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Thu, Mar 26, 2015 at 01:58:25PM -0700, Andy Lutomirski wrote:
On Thu, Mar 26, 2015 at 1:31 PM, Radim Krcmar rkrc...@redhat.com wrote:
2015-03-26 11:51-0700, Andy Lutomirski:
On Thu, Mar 26, 2015 at 4:29 AM,
[much snippage]
On Thu, Mar 26, 2015 at 1:58 PM, Andy Lutomirski l...@amacapital.net wrote:
If the versioning were fixed, I think we could almost get away with:
pvti = pvti for vcpu 0;
ver1 = pvti-version;
check stable bit;
rdtsc_barrier, rdtsc, read scale, shift, etc.
if (pvti-version
On Thu, Mar 26, 2015 at 09:59:24PM +0100, Radim Krčmář wrote:
2015-03-23 20:21-0300, Marcelo Tosatti:
The following point:
2. per-CPU pvclock time info is updated if the
underlying CPU changes.
Is not true anymore since KVM: x86: update pvclock area conditionally,
on
On Thu, Mar 26, 2015 at 3:22 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Thu, Mar 26, 2015 at 09:59:24PM +0100, Radim Krčmář wrote:
2015-03-23 20:21-0300, Marcelo Tosatti:
The following point:
2. per-CPU pvclock time info is updated if the
underlying CPU changes.
On Thu, Mar 26, 2015 at 03:24:10PM -0700, Andy Lutomirski wrote:
On Thu, Mar 26, 2015 at 3:22 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Thu, Mar 26, 2015 at 09:59:24PM +0100, Radim Krčmář wrote:
2015-03-23 20:21-0300, Marcelo Tosatti:
The following point:
2. per-CPU
On Thu, Mar 26, 2015 at 01:58:25PM -0700, Andy Lutomirski wrote:
On Thu, Mar 26, 2015 at 1:31 PM, Radim Krcmar rkrc...@redhat.com wrote:
2015-03-26 11:51-0700, Andy Lutomirski:
On Thu, Mar 26, 2015 at 4:29 AM, Marcelo Tosatti mtosa...@redhat.com
wrote:
On Wed, Mar 25, 2015 at 04:22:03PM
On Thu, Mar 26, 2015 at 04:09:53PM -0700, Andy Lutomirski wrote:
On Thu, Mar 26, 2015 at 3:56 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Thu, Mar 26, 2015 at 01:58:25PM -0700, Andy Lutomirski wrote:
On Thu, Mar 26, 2015 at 1:31 PM, Radim Krcmar rkrc...@redhat.com wrote:
2015-03-26
2015-03-25 12:08+0100, Radim Krčmář:
Reverting the patch protects us from any migration, but I don't think we
need to care about changing VCPUs as long as we read a consistent data
from kvmclock. (VCPU can change outside of this loop too, so it doesn't
matter if we return a value not fit for
2015-03-23 20:21-0300, Marcelo Tosatti:
The following point:
2. per-CPU pvclock time info is updated if the
underlying CPU changes.
Is not true anymore since KVM: x86: update pvclock area conditionally,
on cpu migration.
Add task migration notification back.
Problem
On Wed, Mar 25, 2015 at 01:52:15PM +0100, Radim Krčmář wrote:
2015-03-25 12:08+0100, Radim Krčmář:
Reverting the patch protects us from any migration, but I don't think we
need to care about changing VCPUs as long as we read a consistent data
from kvmclock. (VCPU can change outside of this
On Wed, Mar 25, 2015 at 3:41 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Wed, Mar 25, 2015 at 03:33:10PM -0700, Andy Lutomirski wrote:
On Mar 25, 2015 2:29 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Wed, Mar 25, 2015 at 01:52:15PM +0100, Radim Krčmář wrote:
2015-03-25
On Wed, Mar 25, 2015 at 4:13 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Wed, Mar 25, 2015 at 03:48:02PM -0700, Andy Lutomirski wrote:
On Wed, Mar 25, 2015 at 3:41 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Wed, Mar 25, 2015 at 03:33:10PM -0700, Andy Lutomirski wrote:
On Mar 25,
On Wed, Mar 25, 2015 at 03:33:10PM -0700, Andy Lutomirski wrote:
On Mar 25, 2015 2:29 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Wed, Mar 25, 2015 at 01:52:15PM +0100, Radim Krčmář wrote:
2015-03-25 12:08+0100, Radim Krčmář:
Reverting the patch protects us from any migration,
On Wed, Mar 25, 2015 at 03:48:02PM -0700, Andy Lutomirski wrote:
On Wed, Mar 25, 2015 at 3:41 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Wed, Mar 25, 2015 at 03:33:10PM -0700, Andy Lutomirski wrote:
On Mar 25, 2015 2:29 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Wed, Mar
On Mar 25, 2015 2:29 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Wed, Mar 25, 2015 at 01:52:15PM +0100, Radim Krčmář wrote:
2015-03-25 12:08+0100, Radim Krčmář:
Reverting the patch protects us from any migration, but I don't think we
need to care about changing VCPUs as long as we
2015-03-24 15:33-0700, Andy Lutomirski:
On Tue, Mar 24, 2015 at 8:34 AM, Radim Krčmář rkrc...@redhat.com wrote:
What is the problem?
The kvmclock spec says that the host will increment a version field to
an odd number, then update stuff, then increment it to an even number.
The host is
2015-03-24 19:59-0300, Marcelo Tosatti:
On Tue, Mar 24, 2015 at 04:34:12PM +0100, Radim Krčmář wrote:
2015-03-23 20:21-0300, Marcelo Tosatti:
The following point:
2. per-CPU pvclock time info is updated if the
underlying CPU changes.
Is not true anymore since KVM:
On Tue, Mar 24, 2015 at 04:34:12PM +0100, Radim Krčmář wrote:
2015-03-23 20:21-0300, Marcelo Tosatti:
The following point:
2. per-CPU pvclock time info is updated if the
underlying CPU changes.
Is not true anymore since KVM: x86: update pvclock area conditionally,
on
On Tue, Mar 24, 2015 at 8:34 AM, Radim Krčmář rkrc...@redhat.com wrote:
2015-03-23 20:21-0300, Marcelo Tosatti:
The following point:
2. per-CPU pvclock time info is updated if the
underlying CPU changes.
Is not true anymore since KVM: x86: update pvclock area conditionally,
on
2015-03-23 20:21-0300, Marcelo Tosatti:
The following point:
2. per-CPU pvclock time info is updated if the
underlying CPU changes.
Is not true anymore since KVM: x86: update pvclock area conditionally,
on cpu migration.
I think that the revert doesn't fix point 2.: KVM: x86:
The following point:
2. per-CPU pvclock time info is updated if the
underlying CPU changes.
Is not true anymore since KVM: x86: update pvclock area conditionally,
on cpu migration.
Add task migration notification back.
Problem noticed by Andy Lutomirski.
Signed-off-by: Marcelo
On Mon, Mar 23, 2015 at 4:21 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
The following point:
2. per-CPU pvclock time info is updated if the
underlying CPU changes.
Is not true anymore since KVM: x86: update pvclock area conditionally,
on cpu migration.
Add task migration
32 matches
Mail list logo
