From: Artyom Tarasenko <atar4qemu@googlemail.com>
To: Blue Swirl <blauwirbel@gmail.com>
Cc: qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: sparc32 do_unassigned_access overhaul
Date: Tue, 19 Jan 2010 18:30:22 +0100 [thread overview]
Message-ID: <fb8d4f71001190930r44fae62h3c56128cd240c1de@mail.gmail.com> (raw)
In-Reply-To: <fb8d4f71001151348o7a5ed727j104752081ee3ce71@mail.gmail.com>
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.
Would you like to implement it?
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.
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 ................
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.
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..
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/
next prev parent reply other threads:[~2010-01-19 17:30 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-15 18:46 [Qemu-devel] sparc32 do_unassigned_access overhaul Artyom Tarasenko
2010-01-15 19:45 ` [Qemu-devel] " Blue Swirl
2010-01-15 21:11 ` Artyom Tarasenko
2010-01-15 21:26 ` Blue Swirl
2010-01-15 21:48 ` Artyom Tarasenko
2010-01-19 17:30 ` Artyom Tarasenko [this message]
2010-01-19 19:32 ` Blue Swirl
2010-01-19 21:44 ` Artyom Tarasenko
2010-01-20 18:29 ` Blue Swirl
2010-01-22 18:00 ` Blue Swirl
2010-01-22 20:51 ` Artyom Tarasenko
2010-01-23 7:55 ` Blue Swirl
2010-01-23 16:46 ` Artyom Tarasenko
2010-01-23 18:39 ` Blue Swirl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fb8d4f71001190930r44fae62h3c56128cd240c1de@mail.gmail.com \
--to=atar4qemu@googlemail.com \
--cc=blauwirbel@gmail.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).