On Dec 19, 2007 1:41 PM, Avi Kivity <[EMAIL PROTECTED]> wrote:
> Glauber de Oliveira Costa wrote:
> > Changes in rate does not sound good. It's possibly what's screwing up
> > my paravirt clock implementation in smp.
> >
>
> You should renew the timebase on vcpu migration, and hook cpufreq so
>
On Dec 19, 2007 1:41 PM, Avi Kivity [EMAIL PROTECTED] wrote:
Glauber de Oliveira Costa wrote:
Changes in rate does not sound good. It's possibly what's screwing up
my paravirt clock implementation in smp.
You should renew the timebase on vcpu migration, and hook cpufreq so
that changes
On Wednesday 19 December 2007 21:02:06 Glauber de Oliveira Costa wrote:
> On Dec 19, 2007 12:27 PM, Avi Kivity <[EMAIL PROTECTED]> wrote:
> > Ingo Molnar wrote:
> > > * Avi Kivity <[EMAIL PROTECTED]> wrote:
> > >> Avi Kivity wrote:
> > >>> Testing shows wrmsr and rdtsc function normally.
> > >>>
Glauber de Oliveira Costa wrote:
Changes in rate does not sound good. It's possibly what's screwing up
my paravirt clock implementation in smp.
You should renew the timebase on vcpu migration, and hook cpufreq so
that changes in frequency are reflected in the timebase.
Since the host
On Dec 19, 2007 12:27 PM, Avi Kivity <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
> > * Avi Kivity <[EMAIL PROTECTED]> wrote:
> >
> >
> >> Avi Kivity wrote:
> >>
> >>> Testing shows wrmsr and rdtsc function normally.
> >>>
> >>> I'll try pinning the vcpus to cpus and see if that helps.
> >>>
>
Ingo Molnar wrote:
try this test perhaps in an SMP guest:
http://people.redhat.com/mingo/time-warp-test/time-warp-test.c
you can ignore TSC warps - but no GTOD or CLOCK warps should occur.
On a broken guest kernel, I see gtod and clock warps. On a good guest
kernel, I do not,
try this test perhaps in an SMP guest:
http://people.redhat.com/mingo/time-warp-test/time-warp-test.c
you can ignore TSC warps - but no GTOD or CLOCK warps should occur.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Ingo Molnar wrote:
* Avi Kivity <[EMAIL PROTECTED]> wrote:
Avi Kivity wrote:
Testing shows wrmsr and rdtsc function normally.
I'll try pinning the vcpus to cpus and see if that helps.
It does.
do we let the guest read the physical CPU's TSC? That would be trouble.
Ingo Molnar wrote:
* Avi Kivity <[EMAIL PROTECTED]> wrote:
Avi Kivity wrote:
Testing shows wrmsr and rdtsc function normally.
I'll try pinning the vcpus to cpus and see if that helps.
It does.
do we let the guest read the physical CPU's TSC? That would be trouble.
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> Avi Kivity wrote:
>> Testing shows wrmsr and rdtsc function normally.
>>
>> I'll try pinning the vcpus to cpus and see if that helps.
>>
>
> It does.
do we let the guest read the physical CPU's TSC? That would be trouble.
Ingo
--
To
Avi Kivity wrote:
Testing shows wrmsr and rdtsc function normally.
I'll try pinning the vcpus to cpus and see if that helps.
It does.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Avi Kivity wrote:
Ingo Molnar wrote:
While the change mentions that it fixes a time warp bug, it also says
it should be rare. So clearly kvm smp tsc handing is buggy.
Ingo/Thomas, (or anybody else), do you have any insight as to what kvm
can be doing wrong to trigger this behavior?
Avi Kivity wrote:
Ingo Molnar wrote:
While the change mentions that it fixes a time warp bug, it also says
it should be rare. So clearly kvm smp tsc handing is buggy.
Ingo/Thomas, (or anybody else), do you have any insight as to what kvm
can be doing wrong to trigger this behavior?
Avi Kivity wrote:
Testing shows wrmsr and rdtsc function normally.
I'll try pinning the vcpus to cpus and see if that helps.
It does.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
* Avi Kivity [EMAIL PROTECTED] wrote:
Avi Kivity wrote:
Testing shows wrmsr and rdtsc function normally.
I'll try pinning the vcpus to cpus and see if that helps.
It does.
do we let the guest read the physical CPU's TSC? That would be trouble.
Ingo
--
To unsubscribe from this
Ingo Molnar wrote:
* Avi Kivity [EMAIL PROTECTED] wrote:
Avi Kivity wrote:
Testing shows wrmsr and rdtsc function normally.
I'll try pinning the vcpus to cpus and see if that helps.
It does.
do we let the guest read the physical CPU's TSC? That would be trouble.
Ingo Molnar wrote:
* Avi Kivity [EMAIL PROTECTED] wrote:
Avi Kivity wrote:
Testing shows wrmsr and rdtsc function normally.
I'll try pinning the vcpus to cpus and see if that helps.
It does.
do we let the guest read the physical CPU's TSC? That would be trouble.
try this test perhaps in an SMP guest:
http://people.redhat.com/mingo/time-warp-test/time-warp-test.c
you can ignore TSC warps - but no GTOD or CLOCK warps should occur.
Ingo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
Ingo Molnar wrote:
try this test perhaps in an SMP guest:
http://people.redhat.com/mingo/time-warp-test/time-warp-test.c
you can ignore TSC warps - but no GTOD or CLOCK warps should occur.
On a broken guest kernel, I see gtod and clock warps. On a good guest
kernel, I do not,
Glauber de Oliveira Costa wrote:
Changes in rate does not sound good. It's possibly what's screwing up
my paravirt clock implementation in smp.
You should renew the timebase on vcpu migration, and hook cpufreq so
that changes in frequency are reflected in the timebase.
Since the host
On Dec 19, 2007 12:27 PM, Avi Kivity [EMAIL PROTECTED] wrote:
Ingo Molnar wrote:
* Avi Kivity [EMAIL PROTECTED] wrote:
Avi Kivity wrote:
Testing shows wrmsr and rdtsc function normally.
I'll try pinning the vcpus to cpus and see if that helps.
It does.
do we let the
On Wednesday 19 December 2007 21:02:06 Glauber de Oliveira Costa wrote:
On Dec 19, 2007 12:27 PM, Avi Kivity [EMAIL PROTECTED] wrote:
Ingo Molnar wrote:
* Avi Kivity [EMAIL PROTECTED] wrote:
Avi Kivity wrote:
Testing shows wrmsr and rdtsc function normally.
I'll try pinning the
Ingo Molnar wrote:
While the change mentions that it fixes a time warp bug, it also says
it should be rare. So clearly kvm smp tsc handing is buggy.
Ingo/Thomas, (or anybody else), do you have any insight as to what kvm
can be doing wrong to trigger this behavior?
hm. Those time warps
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> Booting RHEL 5 i386 in kvm with -no-kvm-irqchip -smp 4 will hang in udev.
> I bisected this to a change in the _guest_ kernel:
>
>> commit 95492e4646e5de8b43d9a7908d6177fb737b61f0
>> Author: Ingo Molnar <[EMAIL PROTECTED]>
>> Date: Fri Feb 16
Booting RHEL 5 i386 in kvm with -no-kvm-irqchip -smp 4 will hang in
udev. I bisected this to a change in the _guest_ kernel:
commit 95492e4646e5de8b43d9a7908d6177fb737b61f0
Author: Ingo Molnar <[EMAIL PROTECTED]>
Date: Fri Feb 16 01:27:34 2007 -0800
[PATCH] x86: rewrite SMP TSC sync
Booting RHEL 5 i386 in kvm with -no-kvm-irqchip -smp 4 will hang in
udev. I bisected this to a change in the _guest_ kernel:
commit 95492e4646e5de8b43d9a7908d6177fb737b61f0
Author: Ingo Molnar [EMAIL PROTECTED]
Date: Fri Feb 16 01:27:34 2007 -0800
[PATCH] x86: rewrite SMP TSC sync code
* Avi Kivity [EMAIL PROTECTED] wrote:
Booting RHEL 5 i386 in kvm with -no-kvm-irqchip -smp 4 will hang in udev.
I bisected this to a change in the _guest_ kernel:
commit 95492e4646e5de8b43d9a7908d6177fb737b61f0
Author: Ingo Molnar [EMAIL PROTECTED]
Date: Fri Feb 16 01:27:34 2007 -0800
Ingo Molnar wrote:
While the change mentions that it fixes a time warp bug, it also says
it should be rare. So clearly kvm smp tsc handing is buggy.
Ingo/Thomas, (or anybody else), do you have any insight as to what kvm
can be doing wrong to trigger this behavior?
hm. Those time warps
28 matches
Mail list logo
