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: Blue Swirl
Subject: [Qemu-devel] Re: [PATCH 1/2] Pad iommu with an empty slot (necessary for SunOS 4.1.4)
Date: Sat, 29 May 2010 08:23:08 +0000

On Fri, May 28, 2010 at 9:53 PM, Artyom Tarasenko
<address@hidden> wrote:
>> 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?

Thanks, applied.

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