[Qemu-devel] Re: sparc32 do_unassigned_access overhaul

[Blue Swirl]

On Tue, Jan 19, 2010 at 9:44 PM, Artyom Tarasenko
<address@hidden> wrote:
> 2010/1/19 Blue Swirl <address@hidden>:
>> On Tue, Jan 19, 2010 at 5:30 PM, Artyom Tarasenko
>> <address@hidden> wrote:
>>> 2010/1/15 Artyom Tarasenko <address@hidden>:
>>>> 2010/1/15 Blue Swirl <address@hidden>:
>>>>> On Fri, Jan 15, 2010 at 9:11 PM, Artyom Tarasenko
>>>>> <address@hidden> wrote:
>>>>>> 2010/1/15 Blue Swirl <address@hidden>:
>>>>>>> On Fri, Jan 15, 2010 at 6:46 PM, Artyom Tarasenko
>>>>>>> <address@hidden> wrote:
>>>>>>>> According to pages 9-31 - 9-34 of "SuperSPARC & MultiCache Controller
>>>>>>>> User's Manual":
>>>>>>>>
>>>>>>>> 1. "A lower priority fault may not overwrite the
>>>>>>>>    MFSR 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 (MFSR)
>>>>>>>>   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 
>>>>>> potentially 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:
>>>>>  - 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 though.
>>> 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  : 0800.0000
>>> Context  : @ 0.01ff.f000  001f.eec1 # 0
>>> Region   : @ 0.01fe.ec20  0000.0000 Invalid
>>> ok 8000000 obmem 8000000 map-page
>>> ok 8000000 map?
>>> Virtual  : 0800.0000
>>> Context  : @ 0.01ff.f000  001f.eec1 # 0
>>> Region   : @ 0.01fe.ec20  001f.b231
>>> Segment  : @ 0.01fb.2300  001f.b221
>>> Page     : @ 0.01fb.2200  0080.001e Access : rwx---
>>> Physical : 0.0800.0000
>>> ok 8000000 20 dump
>>>          \/  1  2  3  4  5  6  7   8  9  a  b  c  d  e  f  v123456789abcdef
>>>  8000000  00 d1 e1 44 ff d1 e2 18  08 d1 e1 4e ff d1 e2 18  .QaV.Qb..QaV.Qb.
>>>  8000010  00 d1 e1 44 ff d1 e2 18  08 d1 e1 4e ff d1 e2 18  .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  hex  00 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
>          \/  1  2  3  4  5  6  7   8  9  a  b  c  d  e  f  v123456789abcdef
>  8000000  00 d1 e1 44 ff d1 e2 18  08 d1 e1 4e ff d1 e2 18  .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  : 1000.0000
>>> Context  : @ 0.01ff.f000  001f.eec1 # 0
>>> Region   : @ 0.01fe.ec40  0000.0000 Invalid
>>> ok 10000000 obmem 10000000 map-page
>>> ok 10000000 20 dump
>>>          \/  1  2  3  4  5  6  7   8  9  a  b  c  d  e  f  v123456789abcdef
>>> 10000000  04 00 00 05 00 1f e0 00  04 00 00 05 00 1f e0 00  ......`.......`.
>>> 10000010  04 00 00 05 04 00 00 05  04 00 00 05 04 00 00 05  ................
>>
>> IOMMU registers here...
>>
>>> ok 30000000 map?
>>> Virtual  : 3000.0000
>>> Context  : @ 0.01ff.f000  001f.eec1 # 0
>>> Region   : @ 0.01fe.ecc0  0000.0000 Invalid
>>> ok 30000000 obmem 30000000 map-page
>>> ok 30000000 20 dump
>>>          \/  1  2  3  4  5  6  7   8  9  a  b  c  d  e  f  v123456789abcdef
>>> 30000000  Data Access Error
>>> ok 2fff0000 obmem 2fff0000 map-page
>>> ok 2fff0000 20 dump
>>>          \/  1  2  3  4  5  6  7   8  9  a  b  c  d  e  f  v123456789abcdef
>>> 2fff0000  02 ff e1 44 ff d1 e2 18  2f d1 e1 4e ff d1 e2 18  .QaV.Qb..QaV.Qb.
>>> 2fff0010  00 d1 e1 44 ff d1 e2 18  2f d1 e1 4e ff d1 e2 18  .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  : f000.0000
>>> Context  : @ 0.01ff.f000  001f.eec1 # 0
>>> Region   : @ 0.01fe.efc0  0000.0000 Invalid
>>> ok f0000000 obmem f0000000 map-page
>>> ok f0000000 20 dump
>>>          \/  1  2  3  4  5  6  7   8  9  a  b  c  d  e  f  v123456789abcdef
>>> f0000000  10 80 2f 66 a1 48 00 00  01 00 00 00 01 00 00 00  ../f!H..........
>>> f0000010  29 1c 00 04 a8 15 20 d0  81 c5 00 00 a1 48 00 00  )...(. 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  : f7ff.0000
>>> Context  : @ 0.01ff.f000  001f.eec1 # 0
>>> Region   : @ 0.01fe.efdc  0000.0000 Invalid
>>> ok f7ff0000 obmem f7ff0000 map-page
>>> ok f7ff0000 20 dump
>>>          \/  1  2  3  4  5  6  7   8  9  a  b  c  d  e  f  v123456789abcdef
>>> f7ff0000  Data Access Error
>>> ok f6ff0000 map?
>>> Virtual  : f6ff.0000
>>> Context  : @ 0.01ff.f000  001f.eec1 # 0
>>> Region   : @ 0.01fe.efd8  0000.0000 Invalid
>>> ok f6ff0000 obmem f6ff0000 map-page
>>> ok f6ff0000 20 dump
>>>          \/  1  2  3  4  5  6  7   8  9  a  b  c  d  e  f  v123456789abcdef
>>> f6ff0000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  ................
>>> f6ff0010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  ................
>
> --
> Regards,
> Artyom Tarasenko
>
> solaris/sparc under qemu blog: http://tyom.blogspot.com/
>