From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:46602)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <tommusta@gmail.com>) id 1WxFA6-0002q7-SB
	for qemu-devel@nongnu.org; Wed, 18 Jun 2014 08:40:31 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <tommusta@gmail.com>) id 1WxF9x-0003nP-Om
	for qemu-devel@nongnu.org; Wed, 18 Jun 2014 08:40:22 -0400
Message-ID: <53A188A2.4070509@gmail.com>
Date: Wed, 18 Jun 2014 07:40:02 -0500
From: Tom Musta <tommusta@gmail.com>
MIME-Version: 1.0
References: <alpine.LMD.2.02.1405061154290.22695@jedlik.phy.bme.hu>
	<5368D385.7050900@gmail.com>
	<alpine.LMD.2.02.1405070022550.23536@jedlik.phy.bme.hu>
	<536A51C9.6060308@gmail.com> <536A6683.2070500@suse.de>
	<alpine.LMD.2.02.1406120217170.6886@jedlik.phy.bme.hu>
	<alpine.LMD.2.02.1406170137470.32601@jedlik.phy.bme.hu>
	<539FFF6D.2070407@suse.de>
	<alpine.LMD.2.02.1406171133060.2477@jedlik.phy.bme.hu>
	<53A00C6E.9010106@suse.de>
	<alpine.LMD.2.02.1406171258390.2477@jedlik.phy.bme.hu>
	<53A02C6C.1010501@gmail.com>
	<alpine.LMD.2.02.1406171711400.3304@jedlik.phy.bme.hu>
In-Reply-To: <alpine.LMD.2.02.1406171711400.3304@jedlik.phy.bme.hu>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [Qemu-ppc]  Help needed testing on ppc
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: BALATON Zoltan <balaton@eik.bme.hu>
Cc: Programmingkid <programmingkidx@gmail.com>, qemu-ppc <qemu-ppc@nongnu.org>, Alexander Graf <agraf@suse.de>, =?ISO-8859-1?Q?Andreas_F=E4rber?= <afaerber@suse.de>, qemu-devel@nongnu.org

On 6/17/2014 10:17 AM, BALATON Zoltan wrote:
> On Tue, 17 Jun 2014, Tom Musta wrote:
>> I am looking at the test case source code and do not see how you are setting the reserved bit.  Maybe I am missing some cleverness in how the test is built?
> 
> Probably I should have written it more straight-forward but I wanted it to be possible to change it for other tests easily so it's a bit tricky. Basically I get the code location by a bl then fetching the link register:
> 
>>  asm volatile("mfcr %0               \n\t"
>>               "bl 1f                 \n\t"
>>               "mfcr %1               \n\t"
>>               "mflr 10               \n\t"
> 
> and then set the bit with the next three lines after testing the normal case:
> 
>>               "lwz %0, 36(10)        \n\t"
>>               "ori %0, %0, 1         \n\t"
>>               "stw %0, 36(10)        \n\t"
> 
> Then test again with the bit set:
> 
>>               "mfcr %0               \n\t"
>>               "bl 1f                 \n\t"
>>               "mfcr %2               \n\t"
> 
> and exit:
> 
>>               "b 2f                  \n\t"
>>               "1: stwx %0, %4, %6    \n\t"          <<<<<<<<<<<<< just a normal stwx, right?
>>               "blr                   \n\t"
>>               "2:                    \n\t"
>>                : "=&r"(cr), "=&r"(cr1), "=&r"(cr2), "=m"(val)
>>                : "r"(&val), "m"(val), "r"(8)
>>                : "r8", "r9", "r10", "cc", "memory");
>>
>>  prom_printf("old cr  (mem):\t%#x\n", val);
>>  prom_printf("old cr  (reg):\t%#x\n", cr);
>>  prom_printf("new cr1 (reg):\t%#x\n", cr1);
>>  prom_printf("new cr2 (reg):\t%#x\n", cr2);
>> }
>>
>>
>> But the objdump of your test binary does not show that it is set either:
> 
> It should show in a debugger the second time the stwx is called (it did for me).
> 
> Regards,
> BALATON Zoltan

There should be an icbi after the ori/stw sequence to ensure that the modified code gets into the instruction cache.