From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60438) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wz7iD-0004AK-Pa for qemu-devel@nongnu.org; Mon, 23 Jun 2014 13:07:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wz7i6-0007fv-9u for qemu-devel@nongnu.org; Mon, 23 Jun 2014 13:07:21 -0400 Message-ID: <53A85EC0.7010703@suse.de> Date: Mon, 23 Jun 2014 19:07:12 +0200 From: Alexander Graf MIME-Version: 1.0 References: <5368D385.7050900@gmail.com> <536A51C9.6060308@gmail.com> <536A6683.2070500@suse.de> <539FFF6D.2070407@suse.de> <53A00C6E.9010106@suse.de> <53A02C6C.1010501@gmail.com> <53A188A2.4070509@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Qemu-ppc] Help needed testing on ppc List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: BALATON Zoltan , Tom Musta Cc: Programmingkid , qemu-ppc , qemu-devel@nongnu.org, =?ISO-8859-1?Q?Andreas_F=E4rber?= On 19.06.14 15:21, BALATON Zoltan wrote: > On Wed, 18 Jun 2014, Tom Musta wrote: >> 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). >>> >> >> There should be an icbi after the ori/stw sequence to ensure that the >> modified code gets into the instruction cache. > > I've corrected the test accordingly and rerun on iMac,1. It did not > change the stwx test results, the cr values are still the same. Great :). Now please check through all opcodes that get generated by the GEN_STUX, GEN_STX_E, GEN_LDUX and GEN_LDX_E helpers in translate.c and verify that the bit gets ignored on all of them. We can then easily just remove the reserved Rc bit on those instruction definitions generically and call it a day. Alex