On Thu, Mar 26, 2015 at 04:28:37PM -0700, Andy Lutomirski wrote:
> On Thu, Mar 26, 2015 at 4:22 PM, Marcelo Tosatti 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
> >> wrote:
> >> > On Thu, Mar 26, 2015 at 01:58:2
On Thu, Mar 26, 2015 at 4:22 PM, Marcelo Tosatti 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 wrote:
>> > On Thu, Mar 26, 2015 at 01:58:25PM -0700, Andy Lutomirski wrote:
>> >> On Thu, Mar 26, 2015 at 1:31 PM, Radim
On Thu, Mar 26, 2015 at 04:09:53PM -0700, Andy Lutomirski wrote:
> On Thu, Mar 26, 2015 at 3:56 PM, Marcelo Tosatti 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 wrote:
> >> > 2015-03-26 11:51-0700, Andy Lutomirski:
On Thu, Mar 26, 2015 at 3:56 PM, Marcelo Tosatti 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 wrote:
>> > 2015-03-26 11:51-0700, Andy Lutomirski:
>> >> On Thu, Mar 26, 2015 at 4:29 AM, Marcelo Tosatti
>> >> 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 wrote:
> > 2015-03-26 11:51-0700, Andy Lutomirski:
> >> On Thu, Mar 26, 2015 at 4:29 AM, Marcelo Tosatti
> >> wrote:
> >> > On Wed, Mar 25, 2015 at 04:22:03PM -0700, Andy Lutomirski w
On Thu, Mar 26, 2015 at 03:24:10PM -0700, Andy Lutomirski wrote:
> On Thu, Mar 26, 2015 at 3:22 PM, Marcelo Tosatti 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 3:22 PM, Marcelo Tosatti 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 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 cond
[much snippage]
On Thu, Mar 26, 2015 at 1:58 PM, Andy Lutomirski 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 != ver1) r
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.
>
On Thu, Mar 26, 2015 at 1:31 PM, Radim Krcmar wrote:
> 2015-03-26 11:51-0700, Andy Lutomirski:
>> On Thu, Mar 26, 2015 at 4:29 AM, Marcelo Tosatti 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 perf
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ář 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
>>> +* versio
2015-03-26 11:51-0700, Andy Lutomirski:
> On Thu, Mar 26, 2015 at 4:29 AM, Marcelo Tosatti 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 its frequenc
2015-03-26 11:47-0700, Andy Lutomirski:
> On Wed, Mar 25, 2015 at 4:08 AM, Radim Krčmář 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 and even af
On Thu, Mar 26, 2015 at 4:29 AM, Marcelo Tosatti 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 wrote:
>> > On Wed, Mar 25, 2015 at 03:48:02PM -0700, Andy Lutomirski wrote:
>> >> On Wed, Mar 25, 2015 at 3:41 PM, Marcel
On Wed, Mar 25, 2015 at 4:08 AM, Radim Krčmář wrote:
> 2015-03-24 15:33-0700, Andy Lutomirski:
>> On Tue, Mar 24, 2015 at 8:34 AM, Radim Krčmář 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 i
On Wed, Mar 25, 2015 at 04:22:03PM -0700, Andy Lutomirski wrote:
> On Wed, Mar 25, 2015 at 4:13 PM, Marcelo Tosatti 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
> >> wrote:
> >> > On Wed, Mar 25, 2015 at 03:33:1
On Wed, Mar 25, 2015 at 4:13 PM, Marcelo Tosatti 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 wrote:
>> > On Wed, Mar 25, 2015 at 03:33:10PM -0700, Andy Lutomirski wrote:
>> >> On Mar 25, 2015 2:29 PM, "Marcelo Tosat
On Wed, Mar 25, 2015 at 03:48:02PM -0700, Andy Lutomirski wrote:
> On Wed, Mar 25, 2015 at 3:41 PM, Marcelo Tosatti wrote:
> > On Wed, Mar 25, 2015 at 03:33:10PM -0700, Andy Lutomirski wrote:
> >> On Mar 25, 2015 2:29 PM, "Marcelo Tosatti" wrote:
> >> >
> >> > On Wed, Mar 25, 2015 at 01:52:15PM +
On Wed, Mar 25, 2015 at 3:41 PM, Marcelo Tosatti wrote:
> On Wed, Mar 25, 2015 at 03:33:10PM -0700, Andy Lutomirski wrote:
>> On Mar 25, 2015 2:29 PM, "Marcelo Tosatti" wrote:
>> >
>> > On Wed, Mar 25, 2015 at 01:52:15PM +0100, Radim Krčmář wrote:
>> > > 2015-03-25 12:08+0100, Radim Krčmář:
>> >
On Wed, Mar 25, 2015 at 03:33:10PM -0700, Andy Lutomirski wrote:
> On Mar 25, 2015 2:29 PM, "Marcelo Tosatti" 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 do
On Mar 25, 2015 2:29 PM, "Marcelo Tosatti" 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 read a c
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 o
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.
>
> P
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 f
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 tru
2015-03-24 15:33-0700, Andy Lutomirski:
> On Tue, Mar 24, 2015 at 8:34 AM, Radim Krčmář 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 buggy and doesn
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 condition
On Tue, Mar 24, 2015 at 8:34 AM, 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 cpu
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.: "
On Mon, Mar 23, 2015 at 4:21 PM, Marcelo Tosatti 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 notificat
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 To
32 matches
Mail list logo
