From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NXfJM-0005lp-Nq for qemu-devel@nongnu.org; Wed, 20 Jan 2010 13:29:48 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NXfJI-0005gM-G5 for qemu-devel@nongnu.org; Wed, 20 Jan 2010 13:29:48 -0500 Received: from [199.232.76.173] (port=41677 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NXfJI-0005g4-9q for qemu-devel@nongnu.org; Wed, 20 Jan 2010 13:29:44 -0500 Received: from mail-pz0-f186.google.com ([209.85.222.186]:37557) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NXfJH-0007hY-KV for qemu-devel@nongnu.org; Wed, 20 Jan 2010 13:29:44 -0500 Received: by pzk16 with SMTP id 16so3848335pzk.18 for ; Wed, 20 Jan 2010 10:29:42 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <1263581172-16129-1-git-send-email-atar4qemu@google.com> From: Blue Swirl Date: Wed, 20 Jan 2010 18:29:22 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] Re: sparc32 do_unassigned_access overhaul List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Artyom Tarasenko Cc: qemu-devel@nongnu.org On Tue, Jan 19, 2010 at 9:44 PM, Artyom Tarasenko wrote: > 2010/1/19 Blue Swirl : >> On Tue, Jan 19, 2010 at 5:30 PM, Artyom Tarasenko >> wrote: >>> 2010/1/15 Artyom Tarasenko : >>>> 2010/1/15 Blue Swirl : >>>>> On Fri, Jan 15, 2010 at 9:11 PM, Artyom Tarasenko >>>>> wrote: >>>>>> 2010/1/15 Blue Swirl : >>>>>>> On Fri, Jan 15, 2010 at 6:46 PM, Artyom Tarasenko >>>>>>> wrote: >>>>>>>> According to pages 9-31 - 9-34 of "SuperSPARC & MultiCache Control= ler >>>>>>>> User's Manual": >>>>>>>> >>>>>>>> 1. "A lower priority fault may not overwrite the >>>>>>>> =C2=A0 =C2=A0MFSR status of a higher priority fault." >>>>>>>> 2. The MFAR is overwritten according to the policy defined for the= MFSR >>>>>>>> 3. The overwrite bit is asserted if the fault status register (MFS= R) >>>>>>>> =C2=A0 has been written more than once by faults of the same class >>>>>>>> 4. SuperSPARC will never place instruction fault addresses in the = MFAR. >>>>>>>> >>>>>>>> Implementation of points 1-3 allows booting Solaris 2.6 and 2.5.1. >>>>>>> >>>>>>> Nice work! This also passes my tests. >>>>>> >>>>>> I'm afraid we still are not there yet though: Solaris 7 fails potent= ially due to >>>>>> another bug in the MMU emulation, and the initial [missing-] RAM >>>>>> detection in OBP fails >>>>>> very probably due to a bug in in the MMU emulation. >>>>> >>>>> Some guesses: >>>>> =C2=A0- Access to unassigned RAM area may be handled by the memory >>>>> controller differently (no faults, different faults etc.) than >>>>> unassigned access to SBus or other area. >>> >>> You are right! It seems to be true for the area larger than max RAM tho= ugh. >>> On a real SS-5 with 32M in the first bank, no fault is produced at >>> least for the areas >>> 0-0x2fffffff, 0x70000000-0xafffffff (ha, this would solve problems >>> with SS-20 OBP >>> too) and 0xf0000000-0xf6ffffff. >> >> The fault may still be recorded somewhere else (MXCC, RAM/ECC >> controller or IOMMU). > > sfar and sfsr were empty, so it's definitely not MXCC. Don't know > where to look for the other two. For SS-5 there is MFAR and MFSR in IOMMU (0x10001050, 0x10001054), see chapters 6.3.7 and 6.3.8 in "TurboSPARC Microprocessor User's Guide", Fujitsu, October 1996, version 1.0. SS-20 has M-S AFAR/AFSR (5.2.1 in Sun4m System Architecture Manual) and ECC EFSR and EFAR (5.5.2/5.5.3). With Viking there is also B.III.5.4.6. MXCC Error Register. > But how the fault would be generated? Don't know about Sun simms, but > PC ones don't have any handshake. IMHO the ECC can be the only > possibility. > >> OBP may have disabled the fault, or it has not >> enabled fault generation. > > NF bit is not set. Also, you can see the other faults. I meant memory parity etc. On TurboSparc, parity is enabled in MMU config register. The fault is registerd in MFSR/MFAR. >> On SS-5, the physical address space should be only 31 bits, so you >> should see RAM aliased at 0x80000000. > > No. The RAM can be aliased only within one bank or completely outside > the RAM area. Otherwise different banks would have interfered. > >>> Would you like to implement it? >> >> For RAM, there could be a new device which implements generic address >> space wrapping (base, length, AND mask, OR mask), it should be useful >> for embedded boards. Shouldn't be too difficult, want to try? :-) > > Minutes for you, days for me. :) > >> Dummy MMIO could be registered for the other areas in sun4m.c. I'm not >> sure this is the correct approach, if the fault is still handled >> somewhere else. >> >>> That's how I tested it: >>> >>> ok 8000000 map? >>> Virtual =C2=A0: 0800.0000 >>> Context =C2=A0: @ 0.01ff.f000 =C2=A0001f.eec1 # 0 >>> Region =C2=A0 : @ 0.01fe.ec20 =C2=A00000.0000 Invalid >>> ok 8000000 obmem 8000000 map-page >>> ok 8000000 map? >>> Virtual =C2=A0: 0800.0000 >>> Context =C2=A0: @ 0.01ff.f000 =C2=A0001f.eec1 # 0 >>> Region =C2=A0 : @ 0.01fe.ec20 =C2=A0001f.b231 >>> Segment =C2=A0: @ 0.01fb.2300 =C2=A0001f.b221 >>> Page =C2=A0 =C2=A0 : @ 0.01fb.2200 =C2=A00080.001e Access : rwx--- >>> Physical : 0.0800.0000 >>> ok 8000000 20 dump >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\/ =C2=A01 =C2=A02 =C2=A03 =C2=A04 = =C2=A05 =C2=A06 =C2=A07 =C2=A0 8 =C2=A09 =C2=A0a =C2=A0b =C2=A0c =C2=A0d = =C2=A0e =C2=A0f =C2=A0v123456789abcdef >>> =C2=A08000000 =C2=A000 d1 e1 44 ff d1 e2 18 =C2=A008 d1 e1 4e ff d1 e2 = 18 =C2=A0.QaV.Qb..QaV.Qb. >>> =C2=A08000010 =C2=A000 d1 e1 44 ff d1 e2 18 =C2=A008 d1 e1 4e ff d1 e2 = 18 =C2=A0.QaV.Qb..QaV.Qb. >> >> RAM? > > Looks like a white noise to me. The first byte is frequently > different. Also the mapped RAM is filled with 0's. The pattern can not > be found anywhere in the mapped RAM (0x1000-0x9fffff): > > ok create pattern =C2=A0hex =C2=A000 c, d1 c, e1 c, 44 c, ff c, d1 c, e2 = c, 18 c, > ok pattern 8 1000 9effff sindex . > ffffffff > ok > > Hold on... I tested only the reading. Should have tested writing too: > > ok aa55aa55 8000000 l! > ok sfar@ . sfsr@ . > 0 0 > > no fault, no interrupt, but > > ok 8000000 10 dump > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\/ =C2=A01 =C2=A02 =C2=A03 =C2=A04 =C2= =A05 =C2=A06 =C2=A07 =C2=A0 8 =C2=A09 =C2=A0a =C2=A0b =C2=A0c =C2=A0d =C2= =A0e =C2=A0f =C2=A0v123456789abcdef > =C2=A08000000 =C2=A000 d1 e1 44 ff d1 e2 18 =C2=A008 d1 e1 4e ff d1 e2 18= =C2=A0.QaV.Qb..QaV.Qb. > ok > > no change either. And if I read it differently I get other contents: > ok 8000000 l@ . > f811bdd > > So it's either a noise or a random cache contents. > >>> ok >>> ok 10000000 map? >>> Virtual =C2=A0: 1000.0000 >>> Context =C2=A0: @ 0.01ff.f000 =C2=A0001f.eec1 # 0 >>> Region =C2=A0 : @ 0.01fe.ec40 =C2=A00000.0000 Invalid >>> ok 10000000 obmem 10000000 map-page >>> ok 10000000 20 dump >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\/ =C2=A01 =C2=A02 =C2=A03 =C2=A04 = =C2=A05 =C2=A06 =C2=A07 =C2=A0 8 =C2=A09 =C2=A0a =C2=A0b =C2=A0c =C2=A0d = =C2=A0e =C2=A0f =C2=A0v123456789abcdef >>> 10000000 =C2=A004 00 00 05 00 1f e0 00 =C2=A004 00 00 05 00 1f e0 00 = =C2=A0......`.......`. >>> 10000010 =C2=A004 00 00 05 04 00 00 05 =C2=A004 00 00 05 04 00 00 05 = =C2=A0................ >> >> IOMMU registers here... >> >>> ok 30000000 map? >>> Virtual =C2=A0: 3000.0000 >>> Context =C2=A0: @ 0.01ff.f000 =C2=A0001f.eec1 # 0 >>> Region =C2=A0 : @ 0.01fe.ecc0 =C2=A00000.0000 Invalid >>> ok 30000000 obmem 30000000 map-page >>> ok 30000000 20 dump >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\/ =C2=A01 =C2=A02 =C2=A03 =C2=A04 = =C2=A05 =C2=A06 =C2=A07 =C2=A0 8 =C2=A09 =C2=A0a =C2=A0b =C2=A0c =C2=A0d = =C2=A0e =C2=A0f =C2=A0v123456789abcdef >>> 30000000 =C2=A0Data Access Error >>> ok 2fff0000 obmem 2fff0000 map-page >>> ok 2fff0000 20 dump >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\/ =C2=A01 =C2=A02 =C2=A03 =C2=A04 = =C2=A05 =C2=A06 =C2=A07 =C2=A0 8 =C2=A09 =C2=A0a =C2=A0b =C2=A0c =C2=A0d = =C2=A0e =C2=A0f =C2=A0v123456789abcdef >>> 2fff0000 =C2=A002 ff e1 44 ff d1 e2 18 =C2=A02f d1 e1 4e ff d1 e2 18 = =C2=A0.QaV.Qb..QaV.Qb. >>> 2fff0010 =C2=A000 d1 e1 44 ff d1 e2 18 =C2=A02f d1 e1 4e ff d1 e2 18 = =C2=A0.QaV.Qb..QaV.Qb. >> >> RAM again? > > In theory it could be a RAM alias, as it is outside RAM area, but RAM > wouldn't be immutable. > And... should have tested this one for writing too: > > ok aa55aa55 2fff0000 l! > Level 15 Interrupt > ok sfar@ . sfsr@ . > 0 0 > ok > > No fault, but a NMI! Might be an ECC error as written on page 58 of > Sun4m architecture manual. But this particular SS-5 doesn't seem to > know anything about ECC. It's not in the device tree and reading the > fault address register via asi doesn't work either: > > ok 10 2f spacel! . > Data Access Error > ok No, SS-5 is very different from SS-10/20/600MP so there is no ECC. > > Viking CPU also produces NMI after the mmu trap (page 89), but this is > a SS-5, so no Vikings. Could be an asynchronous fault, but afar > doesn't match: > > ok afsr@ . afar@ . > 3820000 71100006 > > So, no idea who pulls the NMI. > >> >>> ok >>> ok f0000000 map? >>> Virtual =C2=A0: f000.0000 >>> Context =C2=A0: @ 0.01ff.f000 =C2=A0001f.eec1 # 0 >>> Region =C2=A0 : @ 0.01fe.efc0 =C2=A00000.0000 Invalid >>> ok f0000000 obmem f0000000 map-page >>> ok f0000000 20 dump >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\/ =C2=A01 =C2=A02 =C2=A03 =C2=A04 = =C2=A05 =C2=A06 =C2=A07 =C2=A0 8 =C2=A09 =C2=A0a =C2=A0b =C2=A0c =C2=A0d = =C2=A0e =C2=A0f =C2=A0v123456789abcdef >>> f0000000 =C2=A010 80 2f 66 a1 48 00 00 =C2=A001 00 00 00 01 00 00 00 = =C2=A0../f!H.......... >>> f0000010 =C2=A029 1c 00 04 a8 15 20 d0 =C2=A081 c5 00 00 a1 48 00 00 = =C2=A0)...(. P.E..!H.. >> >> This could be boot ROM aliased all over 0xf0000000 to 0xffffffff. > > Yes, probably a ROM alias, but not to 0xffffffff, only to 0xf6ffffff, > see the fault below. > >>> ok f7ff0000 map? >>> Virtual =C2=A0: f7ff.0000 >>> Context =C2=A0: @ 0.01ff.f000 =C2=A0001f.eec1 # 0 >>> Region =C2=A0 : @ 0.01fe.efdc =C2=A00000.0000 Invalid >>> ok f7ff0000 obmem f7ff0000 map-page >>> ok f7ff0000 20 dump >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\/ =C2=A01 =C2=A02 =C2=A03 =C2=A04 = =C2=A05 =C2=A06 =C2=A07 =C2=A0 8 =C2=A09 =C2=A0a =C2=A0b =C2=A0c =C2=A0d = =C2=A0e =C2=A0f =C2=A0v123456789abcdef >>> f7ff0000 =C2=A0Data Access Error >>> ok f6ff0000 map? >>> Virtual =C2=A0: f6ff.0000 >>> Context =C2=A0: @ 0.01ff.f000 =C2=A0001f.eec1 # 0 >>> Region =C2=A0 : @ 0.01fe.efd8 =C2=A00000.0000 Invalid >>> ok f6ff0000 obmem f6ff0000 map-page >>> ok f6ff0000 20 dump >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\/ =C2=A01 =C2=A02 =C2=A03 =C2=A04 = =C2=A05 =C2=A06 =C2=A07 =C2=A0 8 =C2=A09 =C2=A0a =C2=A0b =C2=A0c =C2=A0d = =C2=A0e =C2=A0f =C2=A0v123456789abcdef >>> f6ff0000 =C2=A0ff ff ff ff ff ff ff ff =C2=A0ff ff ff ff ff ff ff ff = =C2=A0................ >>> f6ff0010 =C2=A0ff ff ff ff ff ff ff ff =C2=A0ff ff ff ff ff ff ff ff = =C2=A0................ > > -- > Regards, > Artyom Tarasenko > > solaris/sparc under qemu blog: http://tyom.blogspot.com/ >