WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] SOLVED - Infinte loop in RtlPrefetchMemoryNonTemporal underW

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] SOLVED - Infinte loop in RtlPrefetchMemoryNonTemporal underWindows
From: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
Date: Sat, 22 Nov 2008 23:25:30 +1100
Delivery-date: Sat, 22 Nov 2008 04:26:01 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <AEC6C66638C05B468B556EA548C1A77D0154FC9D@trantor>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <AEC6C66638C05B468B556EA548C1A77D0154FC9C@trantor> <AEC6C66638C05B468B556EA548C1A77D0154FC9D@trantor>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AclMlLvoHhLvgAcuR0mEAReL/OsfCgABMfnAAADDKPA=
Thread-topic: SOLVED - Infinte loop in RtlPrefetchMemoryNonTemporal underWindows
I fixed this with the following entry in my config:

cpuid =
['0x80000005:ecx=xxxxxxxxxxxxxxxxxxxxxxxxkkkkkkkk,edx=xxxxxxxxxxxxxxxxxx
xxxxxxkkkkkkkk']

This passes through the physical host value of the relevant cache
information cpuid function to the DomU.

Is there any reason why we wouldn't want to do this? I think I'm working
around what is actually a bug. Intel CPU's seem to keep cache
information in another cpuid function so maybe it is only (some?) AMD
cpu's affected?

As per the email below, under some circumstances (eg when I give Windows
a pre-checksum-verified packet) it makes a call to a function called
RtlPrefetchMemoryNonTemporal which uses the cache line size as a
decrement in a loop. Xen is setting the cache line size to zero (at
least for AMD processors) causing that loop to never terminate.

James

> -----Original Message-----
> From: James Harper
> Sent: Saturday, 22 November 2008 23:00
> To: James Harper; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-devel] Infinte loop in RtlPrefetchMemoryNonTemporal
> underWindows
> 
> > I have been trying to track down a problem that occurs when my GPLPV
> > drivers give Windows a packet with the
NdisPacketTcpChecksumSucceeded
> > flag set. The problem is that the machine locks hard.
> >
> > After some tedious work with the debugger, I have found that Windows
> > makes a call to a routine called RtlPrefetchMemoryNonTemporal, which
> > looks like this:
> >
> > 8088e579 mov     eax,dword ptr [nt!KePrefetchNTAGranularity 8088e57e
> > 0f184100 prefetchnta [ecx]
> > 8088e582 add     ecx,eax
> > 8088e584 sub     edx,eax
> > 8088e586 ja      nt!RtlPrefetchMemoryNonTemporal+0x6 (8088e57e)
> > 8088e588 ret
> >
> > Unfortunately it appears that the value at
nt!KePrefetchNTAGranularity
> > is 0, hence the infinite loop.
> >
> 
> A bit more debugging shows that RtlPrefectMemoryNonTemporal starts out
> life like this:
> 
> nt!RtlPrefetchMemoryNonTemporal:
> 8088e578 ret
> 8088e579 mov     eax,dword ptr [nt!KePrefetchNTAGranularity 8088e57e
> 0f184100 prefetchnta [ecx]
> 8088e582 add     ecx,eax
> 8088e584 sub     edx,eax
> 8088e586 ja      nt!RtlPrefetchMemoryNonTemporal+0x6 (8088e57e)
> 8088e588 ret
> 
> But then for some reason becomes:
> 
> nt!RtlPrefetchMemoryNonTemporal:
> 8088e578 nop
> 8088e579 mov     eax,dword ptr [nt!KePrefetchNTAGranularity 8088e57e
> 0f184100 prefetchnta [ecx]
> 8088e582 add     ecx,eax
> 8088e584 sub     edx,eax
> 8088e586 ja      nt!RtlPrefetchMemoryNonTemporal+0x6 (8088e57e)
> 8088e588 ret
> 
> The difference being that the initial ret becomes a nop...
> 
> This is getting stranger and stranger.
> 
> James

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel