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
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, p
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
-
SF.Net email is sponsored by:
Check
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
* 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
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
-
SF.Net emai
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 thi
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. T
* 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 s
13 matches
Mail list logo