All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@qumranet.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: kvm-devel <kvm-devel@lists.sourceforge.net>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [kvm-devel] Guest kernel hangs in smp kvm for older kernels prior to tsc sync cleanup
Date: Wed, 19 Dec 2007 13:19:03 +0200	[thread overview]
Message-ID: <4768FE27.7020305@qumranet.com> (raw)
In-Reply-To: <4768BB43.1000609@qumranet.com>

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?
>>>     
>>>       
>> hm. Those time warps were really small, due to the small imperfections 
>> in the "sync up all CPUs to the same moment and do a WRMSR to clear all 
>> their TSCs" mechanism. I.e. at most a few usec time warps. I really dont 
>> know how that should result in udevd hanging. Can you debug udevd in any 
>> way?
>>
>>   
>>     
>
> Adding debug didn't help.  I'll try some sysrq keys to see what the 
> guest thinks is happening.
>
>   

many udev children are exiting; udevd itself is sleeping:

> udevd         S D5DCDF24  2924   573    372   594     629   535 (NOTLB)
>        d5dcdf38 00000086 00000002 d5dcdf24 d5dcdf20 00000000 d5dcdefc 
> d6169f68
>        d7db7f68 d5dcdf68 00000001 d5dd7560 c13b8a90 749ae8d2 00000002 
> 000326a1
>        d5dd7684 c131c700 00000003 d74f8900 892d6946 00000402 ffffffff 
> 00000000
> Call Trace:
>  [<c060d2c9>] do_nanosleep+0x3b/0x66
>  [<c0439b20>] hrtimer_nanosleep+0x50/0x106
>  [<c04397ee>] hrtimer_wakeup+0x0/0x18
>  [<c0439c1f>] sys_nanosleep+0x49/0x59
>  [<c0404e4c>] syscall_call+0x7/0xb
>  [<c0600000>] xfrm_state_find+0x49f/0x51e

So likely sleeping is screwed up somehow (though only on smp).


>> so the only thing that KVM might be doing incorrectly here is the 
>> emulation of the WRMSR that clears the TSC of each vcpu?
>>   
>>     
>
> By inspection, it is correct.  Of course I may be missing something, so 
> I'll write a unit test for it.  It should also be much slower than the 
> native wrmsr.
>
>   

Testing shows wrmsr and rdtsc function normally.

I'll try pinning the vcpus to cpus and see if that helps.

-- 
error compiling committee.c: too many arguments to function


WARNING: multiple messages have this Message-ID (diff)
From: Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
To: Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>
Cc: kvm-devel
	<kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>,
	linux-kernel
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: Guest kernel hangs in smp kvm for older kernels prior to tsc sync cleanup
Date: Wed, 19 Dec 2007 13:19:03 +0200	[thread overview]
Message-ID: <4768FE27.7020305@qumranet.com> (raw)
In-Reply-To: <4768BB43.1000609-atKUWr5tajBWk0Htik3J/w@public.gmane.org>

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?
>>>     
>>>       
>> hm. Those time warps were really small, due to the small imperfections 
>> in the "sync up all CPUs to the same moment and do a WRMSR to clear all 
>> their TSCs" mechanism. I.e. at most a few usec time warps. I really dont 
>> know how that should result in udevd hanging. Can you debug udevd in any 
>> way?
>>
>>   
>>     
>
> Adding debug didn't help.  I'll try some sysrq keys to see what the 
> guest thinks is happening.
>
>   

many udev children are exiting; udevd itself is sleeping:

> udevd         S D5DCDF24  2924   573    372   594     629   535 (NOTLB)
>        d5dcdf38 00000086 00000002 d5dcdf24 d5dcdf20 00000000 d5dcdefc 
> d6169f68
>        d7db7f68 d5dcdf68 00000001 d5dd7560 c13b8a90 749ae8d2 00000002 
> 000326a1
>        d5dd7684 c131c700 00000003 d74f8900 892d6946 00000402 ffffffff 
> 00000000
> Call Trace:
>  [<c060d2c9>] do_nanosleep+0x3b/0x66
>  [<c0439b20>] hrtimer_nanosleep+0x50/0x106
>  [<c04397ee>] hrtimer_wakeup+0x0/0x18
>  [<c0439c1f>] sys_nanosleep+0x49/0x59
>  [<c0404e4c>] syscall_call+0x7/0xb
>  [<c0600000>] xfrm_state_find+0x49f/0x51e

So likely sleeping is screwed up somehow (though only on smp).


>> so the only thing that KVM might be doing incorrectly here is the 
>> emulation of the WRMSR that clears the TSC of each vcpu?
>>   
>>     
>
> By inspection, it is correct.  Of course I may be missing something, so 
> I'll write a unit test for it.  It should also be much slower than the 
> native wrmsr.
>
>   

Testing shows wrmsr and rdtsc function normally.

I'll try pinning the vcpus to cpus and see if that helps.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

  reply	other threads:[~2007-12-19 11:19 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-18 17:20 Guest kernel hangs in smp kvm for older kernels prior to tsc sync cleanup Avi Kivity
2007-12-18 17:20 ` Avi Kivity
2007-12-18 22:19 ` Ingo Molnar
2007-12-18 22:19   ` Ingo Molnar
2007-12-19  6:33   ` Avi Kivity
2007-12-19  6:33     ` Avi Kivity
2007-12-19 11:19     ` Avi Kivity [this message]
2007-12-19 11:19       ` Avi Kivity
2007-12-19 11:39       ` [kvm-devel] " Avi Kivity
2007-12-19 14:06         ` Ingo Molnar
2007-12-19 14:06           ` Ingo Molnar
2007-12-19 14:27           ` [kvm-devel] " Avi Kivity
2007-12-19 15:32             ` Glauber de Oliveira Costa
2007-12-19 15:32               ` Glauber de Oliveira Costa
2007-12-19 15:41               ` [kvm-devel] " Avi Kivity
2007-12-20 10:34                 ` Glauber de Oliveira Costa
2007-12-20 10:34                   ` Glauber de Oliveira Costa
2007-12-19 16:55               ` [kvm-devel] " Amit Shah
2007-12-19 16:55                 ` Amit Shah
2007-12-19 17:04                 ` [kvm-devel] Guest kernel hangs in smp kvm for older kernelsprior " Dor Laor
2007-12-19 17:04                   ` Dor Laor
2007-12-19 17:09                   ` [kvm-devel] " Avi Kivity
2007-12-19 17:09                     ` Avi Kivity
2007-12-19 14:53           ` [kvm-devel] Guest kernel hangs in smp kvm for older kernels prior " Avi Kivity
2007-12-19 14:53             ` Avi Kivity
2007-12-19 15:09             ` [kvm-devel] " Ingo Molnar
2007-12-19 15:21               ` Avi Kivity
2007-12-19 15:21                 ` Avi Kivity

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4768FE27.7020305@qumranet.com \
    --to=avi@qumranet.com \
    --cc=kvm-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.