qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [PATCH 1/2] Pad iommu with an empty slot (necessary for


From: Artyom Tarasenko
Subject: [Qemu-devel] Re: [PATCH 1/2] Pad iommu with an empty slot (necessary for SunOS 4.1.4)
Date: Fri, 28 May 2010 23:53:25 +0200

> 32m: 0x12fff394
> 64m: 0x14fff394
> 192m:0x1cfff394
> 256m:0x20fff394
>
> Memory probing? It would be strange that OS would do it itself. The OS
> could just
> ask OBP how much does it have. Here is the listing where it happens:
>
> _swift_vac_rgnflush:            rd      %psr, %g2
> _swift_vac_rgnflush+4:          andn    %g2, 0x20, %g5
> _swift_vac_rgnflush+8:          mov     %g5, %psr
> _swift_vac_rgnflush+0xc:        nop
> _swift_vac_rgnflush+0x10:       nop
> _swift_vac_rgnflush+0x14:       mov     0x100, %g5
> _swift_vac_rgnflush+0x18:       lda     [%g5] 0x4, %g5
> _swift_vac_rgnflush+0x1c:       sll     %o2, 0x2, %g1
> _swift_vac_rgnflush+0x20:       sll     %g5, 0x4, %g5
> _swift_vac_rgnflush+0x24:       add     %g5, %g1, %g5
> _swift_vac_rgnflush+0x28:       lda     [%g5] 0x20, %g5
>
> _swift_vac_rgnflush+0x28: is the fatal one.
>
> kadb> $c
> _swift_vac_rgnflush(?)
> _vac_rgnflush() + 4
> _hat_setup_kas(0xc00,0xf0447000,0x43a000,0x400,0xf043a000,0x3c0) + 70
> _startup(0xfe000000,0x10000000,0xfa000000,0xf00e2bfc,0x10,0xdbc00) + 1414
> _main(0xf00e0fb4,0xf0007810,0x293ff49f,0xa805209c,0x200,0xf00d1d18) + 14
>
> Unfortunately (but not surprisingly) kadb doesn't allow debugging
> cache-flush code, so I can't check what is in
> [%g5] (aka sfar) on the real machine when this happens.

I was telling fairy tales here and no one stopped me. [%g5] is not
sfar, it's the context pointer,
so the code makes much more sense!

And I guess, SunOS 4.1.4 is buggy. I've managed to reproduce the
complete case on the real machine. The trick is to set the breakpoint
before the interrupts are switched off:

kadb> _swift_vac_rgnflush:b
kadb> :c
breakpoint      _swift_vac_rgnflush:            rd      %psr, %g2
kadb> <o2=X
                44000e5
kadb> $q
Type  'go' to resume
Type  help  for more information
ok 100 4 spacel@ .
3fff00

So at _swift_vac_rgnflush+0x28 it would access (44000e5<<2) + (3fff00
<< 4) = 14fff394. Which is outside of IOMMU.

ok 14fff394 20 spacel@ .
3fe000

This seems to be an alias to

ok 14000004 20 spacel@ .
3fe000

So, it seems to be safe to pad iommu with an empty slot. I guess we
are not missing anything more serious. Alternatively we can use your
aliasing patch.

What do you say?

P.S. What is also interesting about SunOS 4.1.4 is that only the
single-cpu kernel (which is used during the installation) calls
_swift_vac_rgnflush on initialization. The smp kernel just doesn't
have this call in _hat_setup_kas. Maybe they have noticed the bug and
corrected it?

-- 
Regards,
Artyom Tarasenko

solaris/sparc under qemu blog: http://tyom.blogspot.com/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]