[Qemu-devel] Re: sparc32 do_unassigned_access overhaul

[Artyom Tarasenko]

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.

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.

> 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

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/