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

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


  • To: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
  • From: "Jean Guyader" <jean.guyader@xxxxxxxxx>
  • Date: Sat, 22 Nov 2008 14:44:53 +0000
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Sat, 22 Nov 2008 06:45:15 -0800
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=FbkDQKUspyrERnjwx88anJdDS0zsXhEVyZ4wAt7ASPE2wTtJxOi/QfXo2o+401ZtwY OPel/nFJMd+DMrH0poUs35u96HdUlfldDN0wNp5fFi4brOhmrBYLSsuU0ZElv6ACIUTp 7l4wiwsRwp3qP02iyzh44qazNXHvncRlfCb8g=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

James,

That should be fixed be the changeset 18512.
Does your libxc is up to date ?

2008/11/22 James Harper <james.harper@xxxxxxxxxxxxxxxx>:
> 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
>



-- 
Jean Guyader

_______________________________________________
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®.