[Qemu-devel] Re: sparc32 do_unassigned_access overhaul

[Blue Swirl <blauwirbel@gmail.com>]

On Tue, Jan 19, 2010 at 5:30 PM, Artyom Tarasenko
<atar4qemu@googlemail.com> wrote:
> 2010/1/15 Artyom Tarasenko <atar4qemu@googlemail.com>:
>> 2010/1/15 Blue Swirl <blauwirbel@gmail.com>:
>>> On Fri, Jan 15, 2010 at 9:11 PM, Artyom Tarasenko
>>> <atar4qemu@googlemail.com> wrote:
>>>> 2010/1/15 Blue Swirl <blauwirbel@gmail.com>:
>>>>> On Fri, Jan 15, 2010 at 6:46 PM, Artyom Tarasenko
>>>>> <atar4qemu@googlemail.com> 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). OBP may have disabled the fault, or it has not
enabled fault generation.

On SS-5, the physical address space should be only 31 bits, so you
should see RAM aliased at 0x80000000.

> 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? :-)

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?

> 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?

> 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.

> 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/
>