From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: non-emulated rdtsc: a smoking gun! Date: Thu, 22 Oct 2009 14:24:50 -0700 Message-ID: <4AE0CDA2.5060106@goop.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Dan Magenheimer Cc: Xen-devel , kurt.hackel@oracle.com, Jeremy Fitzhardinge , Keir Fraser , chris.mason@oracle.com, Avi Kivity List-Id: xen-devel@lists.xenproject.org On 10/22/09 13:53, Dan Magenheimer wrote: > I just found a Linux kernel use of rdtsc that > MAY cause a significant failure if rdtsc is > unemulated and a poorly timed migration (or > save/restore) occurs under Xen or KVM. > > The problem is that a call to __udelay() -- > or any member of the delay() family -- may > return prematurely**. Since these functions > "must guarantee that we wait at least the > amount of time" specified, there are likely > unknown kernel circumstances where a > premature return will cause problems. > (Disclaimer: I haven't gone through every use > of every call site of every member of the delay > function family to prove this.) > It won't matter, as they're only used to control timing to external IO devices. If a domain has a passthrough device, it can't be migrated or save/restored. Nobody should be using them for software timing. J