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
> tha
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 upd
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, presumabl
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 P
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 unsubscribe
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?
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 01:27:34
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 cod
14 matches
Mail list logo
