[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • 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
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • 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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.