[Qemu-devel] Re: [PATCH 1/2] Pad iommu with an empty slot (necessary for SunOS 4.1.4)
On Fri, May 28, 2010 at 9:53 PM, Artyom Tarasenko atar4q...@googlemail.com 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(0xfe00,0x1000,0xfa00,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 (44000e52) + (3fff00 4) = 14fff394. Which is outside of IOMMU. ok 14fff394 20 spacel@ . 3fe000 This seems to be an alias to ok 1404 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/
[Qemu-devel] Re: [PATCH 1/2] Pad iommu with an empty slot (necessary for SunOS 4.1.4)
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(0xfe00,0x1000,0xfa00,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 (44000e52) + (3fff00 4) = 14fff394. Which is outside of IOMMU. ok 14fff394 20 spacel@ . 3fe000 This seems to be an alias to ok 1404 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/
Re: [Qemu-devel] Re: [PATCH 1/2] Pad iommu with an empty slot (necessary for SunOS 4.1.4)
Artyom Tarasenko wrote: Was going to put some more empty slots into SS-10/20 (VSIMMs, SX) after we are done with SS-5 (due to technical limitations I can switch access from one real SS model to another one once a few days only). I have a partial implementation of the SS-20 VSIMM (cg14) that I've been working on. With the Sun firmware, I have working text console, color boot logo, and programmable video resolutions up to 1600x1280. Bob
[Qemu-devel] Re: [PATCH 1/2] Pad iommu with an empty slot (necessary for SunOS 4.1.4)
2010/5/25 Blue Swirl blauwir...@gmail.com: On Tue, May 25, 2010 at 5:00 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/5/21 Blue Swirl blauwir...@gmail.com: On Fri, May 21, 2010 at 5:23 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/5/10 Blue Swirl blauwir...@gmail.com: On 5/10/10, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/5/10 Blue Swirl blauwir...@gmail.com: On 5/10/10, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/5/9 Blue Swirl blauwir...@gmail.com: On 5/9/10, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/5/9 Blue Swirl blauwir...@gmail.com: On 5/8/10, Artyom Tarasenko atar4q...@googlemail.com wrote: On the real hardware (SS-5, LX) the MMU is not padded, but aliased. Software shouldn't use aliased addresses, neither should it crash when it uses (on the real hardware it wouldn't). Using empty_slot instead of aliasing can help with debugging such accesses. TurboSPARC Microprocessor User's Manual shows that there are additional pages after the main IOMMU for AFX registers. So this is not board specific, but depends on CPU/IOMMU versions. I checked it on the real hw: on LX and SS-5 these are aliased MMU addresses. SS-20 doesn't have any aliasing. But are your machines equipped with TurboSPARC or some other CPU? Good point, I must confess, I missed the word Turbo in your first answer. LX and SS-20 don't. But SS-5 must have a TurboSPARC CPU: ok cd /FMI,MB86904 ok .attributes context-table 00 00 00 00 03 ff f0 00 00 00 10 00 psr-implementation psr-version 0004 implementation version 0004 cache-line-size 0020 cache-nlines 0200 page-size 1000 dcache-line-size 0010 dcache-nlines 0200 dcache-associativity 0001 icache-line-size 0020 icache-nlines 0200 icache-associativity 0001 ncaches 0002 mmu-nctx 0100 sparc-version 0008 mask_rev 0026 device_type cpu name FMI,MB86904 and still it behaves the same as TI,TMS390S10 from the LX. This is done on SS-5: ok 1000 20 spacel@ . 409 ok 1400 20 spacel@ . 409 ok 1404 20 spacel@ . 23000 ok 1f04 20 spacel@ . 23000 ok 1008 20 spacel@ . 409 ok 1428 20 spacel@ . 409 ok 100c 20 spacel@ . 23000 ok 1010 20 spacel@ . 409 LX is the same except for the IOMMU-version: ok 1000 20 spacel@ . 405 ok 1400 20 spacel@ . 405 ok 1800 20 spacel@ . 405 ok 1f00 20 spacel@ . 405 ok 1ff0 20 spacel@ . 405 ok 1fff0004 20 spacel@ . 1fe000 ok 1004 20 spacel@ . 1fe000 ok 1108 20 spacel@ . 4105 ok 1040 20 spacel@ . 4105 ok 1fff0040 20 spacel@ . 4105 ok 1fff0044 20 spacel@ . 1fe000 ok 1fff0024 20 spacel@ . 1fe000 At what address the additional AFX registers are located? Here's complete TurboSPARC IOMMU address map: PA[30:0] Register Access 1000_ IOMMU Control R/W 1000_0004 IOMMU Base Address R/W 1000_0014 Flush All IOTLB Entries W 1000_0018 Address Flush W 1000_1000 Asynchronous Fault Status R/W 1000_1004 Asynchronous Fault Address R/W 1000_1010 SBus Slot Configuration 0 R/W 1000_1014 SBus Slot Configuration 1 R/W 1000_1018 SBus Slot Configuration 2 R/W 1000_101C SBus Slot Configuration 3 R/W 1000_1020 SBus Slot Configuration 4 R/W 1000_1050 Memory Fault Status R/W 1000_1054 Memory Fault Address R/W 1000_2000 Module Identification R/W 1000_3018 Mask Identification R 1000_4000 AFX Queue Level W 1000_6000 AFX Queue Level R 1000_7000 AFX Queue Status R But if I read it correctly 0x12fff294 (which makes SunOS crash with -m 32) is well above this limit. Oh, so I also misread something. You are not talking about the adjacent pages, but 16MB increments. Earlier I sent a patch for a generic address alias device, would it be useful for this? Should do as well. But I thought empty_slot is less overhead and easier to debug. Also the aliasing patch would require one more parameter: the size of area which has to be aliased. Except we implement stubs for all missing devices and and do aliasing of the connected port ranges. And
[Qemu-devel] Re: [PATCH 1/2] Pad iommu with an empty slot (necessary for SunOS 4.1.4)
2010/5/21 Blue Swirl blauwir...@gmail.com: On Fri, May 21, 2010 at 5:23 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/5/10 Blue Swirl blauwir...@gmail.com: On 5/10/10, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/5/10 Blue Swirl blauwir...@gmail.com: On 5/10/10, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/5/9 Blue Swirl blauwir...@gmail.com: On 5/9/10, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/5/9 Blue Swirl blauwir...@gmail.com: On 5/8/10, Artyom Tarasenko atar4q...@googlemail.com wrote: On the real hardware (SS-5, LX) the MMU is not padded, but aliased. Software shouldn't use aliased addresses, neither should it crash when it uses (on the real hardware it wouldn't). Using empty_slot instead of aliasing can help with debugging such accesses. TurboSPARC Microprocessor User's Manual shows that there are additional pages after the main IOMMU for AFX registers. So this is not board specific, but depends on CPU/IOMMU versions. I checked it on the real hw: on LX and SS-5 these are aliased MMU addresses. SS-20 doesn't have any aliasing. But are your machines equipped with TurboSPARC or some other CPU? Good point, I must confess, I missed the word Turbo in your first answer. LX and SS-20 don't. But SS-5 must have a TurboSPARC CPU: ok cd /FMI,MB86904 ok .attributes context-table 00 00 00 00 03 ff f0 00 00 00 10 00 psr-implementation psr-version 0004 implementation version 0004 cache-line-size 0020 cache-nlines 0200 page-size 1000 dcache-line-size 0010 dcache-nlines 0200 dcache-associativity 0001 icache-line-size 0020 icache-nlines 0200 icache-associativity 0001 ncaches 0002 mmu-nctx 0100 sparc-version 0008 mask_rev 0026 device_type cpu name FMI,MB86904 and still it behaves the same as TI,TMS390S10 from the LX. This is done on SS-5: ok 1000 20 spacel@ . 409 ok 1400 20 spacel@ . 409 ok 1404 20 spacel@ . 23000 ok 1f04 20 spacel@ . 23000 ok 1008 20 spacel@ . 409 ok 1428 20 spacel@ . 409 ok 100c 20 spacel@ . 23000 ok 1010 20 spacel@ . 409 LX is the same except for the IOMMU-version: ok 1000 20 spacel@ . 405 ok 1400 20 spacel@ . 405 ok 1800 20 spacel@ . 405 ok 1f00 20 spacel@ . 405 ok 1ff0 20 spacel@ . 405 ok 1fff0004 20 spacel@ . 1fe000 ok 1004 20 spacel@ . 1fe000 ok 1108 20 spacel@ . 4105 ok 1040 20 spacel@ . 4105 ok 1fff0040 20 spacel@ . 4105 ok 1fff0044 20 spacel@ . 1fe000 ok 1fff0024 20 spacel@ . 1fe000 At what address the additional AFX registers are located? Here's complete TurboSPARC IOMMU address map: PA[30:0] Register Access 1000_ IOMMU Control R/W 1000_0004 IOMMU Base Address R/W 1000_0014 Flush All IOTLB Entries W 1000_0018 Address Flush W 1000_1000 Asynchronous Fault Status R/W 1000_1004 Asynchronous Fault Address R/W 1000_1010 SBus Slot Configuration 0 R/W 1000_1014 SBus Slot Configuration 1 R/W 1000_1018 SBus Slot Configuration 2 R/W 1000_101C SBus Slot Configuration 3 R/W 1000_1020 SBus Slot Configuration 4 R/W 1000_1050 Memory Fault Status R/W 1000_1054 Memory Fault Address R/W 1000_2000 Module Identification R/W 1000_3018 Mask Identification R 1000_4000 AFX Queue Level W 1000_6000 AFX Queue Level R 1000_7000 AFX Queue Status R But if I read it correctly 0x12fff294 (which makes SunOS crash with -m 32) is well above this limit. Oh, so I also misread something. You are not talking about the adjacent pages, but 16MB increments. Earlier I sent a patch for a generic address alias device, would it be useful for this? Should do as well. But I thought empty_slot is less overhead and easier to debug. Also the aliasing patch would require one more parameter: the size of area which has to be aliased. Except we implement stubs for all missing devices and and do aliasing of the connected port ranges. And then again, SS-20 doesn't have aliasing in this area at all. What do you think about this (empty_slot) solution (except that I
[Qemu-devel] Re: [PATCH 1/2] Pad iommu with an empty slot (necessary for SunOS 4.1.4)
On Tue, May 25, 2010 at 5:00 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/5/21 Blue Swirl blauwir...@gmail.com: On Fri, May 21, 2010 at 5:23 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/5/10 Blue Swirl blauwir...@gmail.com: On 5/10/10, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/5/10 Blue Swirl blauwir...@gmail.com: On 5/10/10, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/5/9 Blue Swirl blauwir...@gmail.com: On 5/9/10, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/5/9 Blue Swirl blauwir...@gmail.com: On 5/8/10, Artyom Tarasenko atar4q...@googlemail.com wrote: On the real hardware (SS-5, LX) the MMU is not padded, but aliased. Software shouldn't use aliased addresses, neither should it crash when it uses (on the real hardware it wouldn't). Using empty_slot instead of aliasing can help with debugging such accesses. TurboSPARC Microprocessor User's Manual shows that there are additional pages after the main IOMMU for AFX registers. So this is not board specific, but depends on CPU/IOMMU versions. I checked it on the real hw: on LX and SS-5 these are aliased MMU addresses. SS-20 doesn't have any aliasing. But are your machines equipped with TurboSPARC or some other CPU? Good point, I must confess, I missed the word Turbo in your first answer. LX and SS-20 don't. But SS-5 must have a TurboSPARC CPU: ok cd /FMI,MB86904 ok .attributes context-table 00 00 00 00 03 ff f0 00 00 00 10 00 psr-implementation psr-version 0004 implementation version 0004 cache-line-size 0020 cache-nlines 0200 page-size 1000 dcache-line-size 0010 dcache-nlines 0200 dcache-associativity 0001 icache-line-size 0020 icache-nlines 0200 icache-associativity 0001 ncaches 0002 mmu-nctx 0100 sparc-version 0008 mask_rev 0026 device_type cpu name FMI,MB86904 and still it behaves the same as TI,TMS390S10 from the LX. This is done on SS-5: ok 1000 20 spacel@ . 409 ok 1400 20 spacel@ . 409 ok 1404 20 spacel@ . 23000 ok 1f04 20 spacel@ . 23000 ok 1008 20 spacel@ . 409 ok 1428 20 spacel@ . 409 ok 100c 20 spacel@ . 23000 ok 1010 20 spacel@ . 409 LX is the same except for the IOMMU-version: ok 1000 20 spacel@ . 405 ok 1400 20 spacel@ . 405 ok 1800 20 spacel@ . 405 ok 1f00 20 spacel@ . 405 ok 1ff0 20 spacel@ . 405 ok 1fff0004 20 spacel@ . 1fe000 ok 1004 20 spacel@ . 1fe000 ok 1108 20 spacel@ . 4105 ok 1040 20 spacel@ . 4105 ok 1fff0040 20 spacel@ . 4105 ok 1fff0044 20 spacel@ . 1fe000 ok 1fff0024 20 spacel@ . 1fe000 At what address the additional AFX registers are located? Here's complete TurboSPARC IOMMU address map: PA[30:0] Register Access 1000_ IOMMU Control R/W 1000_0004 IOMMU Base Address R/W 1000_0014 Flush All IOTLB Entries W 1000_0018 Address Flush W 1000_1000 Asynchronous Fault Status R/W 1000_1004 Asynchronous Fault Address R/W 1000_1010 SBus Slot Configuration 0 R/W 1000_1014 SBus Slot Configuration 1 R/W 1000_1018 SBus Slot Configuration 2 R/W 1000_101C SBus Slot Configuration 3 R/W 1000_1020 SBus Slot Configuration 4 R/W 1000_1050 Memory Fault Status R/W 1000_1054 Memory Fault Address R/W 1000_2000 Module Identification R/W 1000_3018 Mask Identification R 1000_4000 AFX Queue Level W 1000_6000 AFX Queue Level R 1000_7000 AFX Queue Status R But if I read it correctly 0x12fff294 (which makes SunOS crash with -m 32) is well above this limit. Oh, so I also misread something. You are not talking about the adjacent pages, but 16MB increments. Earlier I sent a patch for a generic address alias device, would it be useful for this? Should do as well. But I thought empty_slot is less overhead and easier to debug. Also the aliasing patch would require one more parameter: the size of area which has to be aliased. Except we implement stubs for all missing devices and and do aliasing of the connected port ranges. And then again, SS-20 doesn't have aliasing in this
[Qemu-devel] Re: [PATCH 1/2] Pad iommu with an empty slot (necessary for SunOS 4.1.4)
2010/5/10 Blue Swirl blauwir...@gmail.com: On 5/10/10, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/5/10 Blue Swirl blauwir...@gmail.com: On 5/10/10, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/5/9 Blue Swirl blauwir...@gmail.com: On 5/9/10, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/5/9 Blue Swirl blauwir...@gmail.com: On 5/8/10, Artyom Tarasenko atar4q...@googlemail.com wrote: On the real hardware (SS-5, LX) the MMU is not padded, but aliased. Software shouldn't use aliased addresses, neither should it crash when it uses (on the real hardware it wouldn't). Using empty_slot instead of aliasing can help with debugging such accesses. TurboSPARC Microprocessor User's Manual shows that there are additional pages after the main IOMMU for AFX registers. So this is not board specific, but depends on CPU/IOMMU versions. I checked it on the real hw: on LX and SS-5 these are aliased MMU addresses. SS-20 doesn't have any aliasing. But are your machines equipped with TurboSPARC or some other CPU? Good point, I must confess, I missed the word Turbo in your first answer. LX and SS-20 don't. But SS-5 must have a TurboSPARC CPU: ok cd /FMI,MB86904 ok .attributes context-table 00 00 00 00 03 ff f0 00 00 00 10 00 psr-implementation psr-version 0004 implementation version 0004 cache-line-size 0020 cache-nlines 0200 page-size 1000 dcache-line-size 0010 dcache-nlines 0200 dcache-associativity 0001 icache-line-size 0020 icache-nlines 0200 icache-associativity 0001 ncaches 0002 mmu-nctx 0100 sparc-version 0008 mask_rev 0026 device_type cpu name FMI,MB86904 and still it behaves the same as TI,TMS390S10 from the LX. This is done on SS-5: ok 1000 20 spacel@ . 409 ok 1400 20 spacel@ . 409 ok 1404 20 spacel@ . 23000 ok 1f04 20 spacel@ . 23000 ok 1008 20 spacel@ . 409 ok 1428 20 spacel@ . 409 ok 100c 20 spacel@ . 23000 ok 1010 20 spacel@ . 409 LX is the same except for the IOMMU-version: ok 1000 20 spacel@ . 405 ok 1400 20 spacel@ . 405 ok 1800 20 spacel@ . 405 ok 1f00 20 spacel@ . 405 ok 1ff0 20 spacel@ . 405 ok 1fff0004 20 spacel@ . 1fe000 ok 1004 20 spacel@ . 1fe000 ok 1108 20 spacel@ . 4105 ok 1040 20 spacel@ . 4105 ok 1fff0040 20 spacel@ . 4105 ok 1fff0044 20 spacel@ . 1fe000 ok 1fff0024 20 spacel@ . 1fe000 At what address the additional AFX registers are located? Here's complete TurboSPARC IOMMU address map: PA[30:0] Register Access 1000_ IOMMU Control R/W 1000_0004 IOMMU Base Address R/W 1000_0014 Flush All IOTLB Entries W 1000_0018 Address Flush W 1000_1000 Asynchronous Fault Status R/W 1000_1004 Asynchronous Fault Address R/W 1000_1010 SBus Slot Configuration 0 R/W 1000_1014 SBus Slot Configuration 1 R/W 1000_1018 SBus Slot Configuration 2 R/W 1000_101C SBus Slot Configuration 3 R/W 1000_1020 SBus Slot Configuration 4 R/W 1000_1050 Memory Fault Status R/W 1000_1054 Memory Fault Address R/W 1000_2000 Module Identification R/W 1000_3018 Mask Identification R 1000_4000 AFX Queue Level W 1000_6000 AFX Queue Level R 1000_7000 AFX Queue Status R But if I read it correctly 0x12fff294 (which makes SunOS crash with -m 32) is well above this limit. Oh, so I also misread something. You are not talking about the adjacent pages, but 16MB increments. Earlier I sent a patch for a generic address alias device, would it be useful for this? Should do as well. But I thought empty_slot is less overhead and easier to debug. Also the aliasing patch would require one more parameter: the size of area which has to be aliased. Except we implement stubs for all missing devices and and do aliasing of the connected port ranges. And then again, SS-20 doesn't have aliasing in this area at all. What do you think about this (empty_slot) solution (except that I missed the SoB line)? Meanwhile it's tested with SunOS 4.1.3U1 too. Maybe we have a general design problem, perhaps unassigned access
[Qemu-devel] Re: [PATCH 1/2] Pad iommu with an empty slot (necessary for SunOS 4.1.4)
On Fri, May 21, 2010 at 5:23 PM, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/5/10 Blue Swirl blauwir...@gmail.com: On 5/10/10, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/5/10 Blue Swirl blauwir...@gmail.com: On 5/10/10, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/5/9 Blue Swirl blauwir...@gmail.com: On 5/9/10, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/5/9 Blue Swirl blauwir...@gmail.com: On 5/8/10, Artyom Tarasenko atar4q...@googlemail.com wrote: On the real hardware (SS-5, LX) the MMU is not padded, but aliased. Software shouldn't use aliased addresses, neither should it crash when it uses (on the real hardware it wouldn't). Using empty_slot instead of aliasing can help with debugging such accesses. TurboSPARC Microprocessor User's Manual shows that there are additional pages after the main IOMMU for AFX registers. So this is not board specific, but depends on CPU/IOMMU versions. I checked it on the real hw: on LX and SS-5 these are aliased MMU addresses. SS-20 doesn't have any aliasing. But are your machines equipped with TurboSPARC or some other CPU? Good point, I must confess, I missed the word Turbo in your first answer. LX and SS-20 don't. But SS-5 must have a TurboSPARC CPU: ok cd /FMI,MB86904 ok .attributes context-table 00 00 00 00 03 ff f0 00 00 00 10 00 psr-implementation psr-version 0004 implementation version 0004 cache-line-size 0020 cache-nlines 0200 page-size 1000 dcache-line-size 0010 dcache-nlines 0200 dcache-associativity 0001 icache-line-size 0020 icache-nlines 0200 icache-associativity 0001 ncaches 0002 mmu-nctx 0100 sparc-version 0008 mask_rev 0026 device_type cpu name FMI,MB86904 and still it behaves the same as TI,TMS390S10 from the LX. This is done on SS-5: ok 1000 20 spacel@ . 409 ok 1400 20 spacel@ . 409 ok 1404 20 spacel@ . 23000 ok 1f04 20 spacel@ . 23000 ok 1008 20 spacel@ . 409 ok 1428 20 spacel@ . 409 ok 100c 20 spacel@ . 23000 ok 1010 20 spacel@ . 409 LX is the same except for the IOMMU-version: ok 1000 20 spacel@ . 405 ok 1400 20 spacel@ . 405 ok 1800 20 spacel@ . 405 ok 1f00 20 spacel@ . 405 ok 1ff0 20 spacel@ . 405 ok 1fff0004 20 spacel@ . 1fe000 ok 1004 20 spacel@ . 1fe000 ok 1108 20 spacel@ . 4105 ok 1040 20 spacel@ . 4105 ok 1fff0040 20 spacel@ . 4105 ok 1fff0044 20 spacel@ . 1fe000 ok 1fff0024 20 spacel@ . 1fe000 At what address the additional AFX registers are located? Here's complete TurboSPARC IOMMU address map: PA[30:0] Register Access 1000_ IOMMU Control R/W 1000_0004 IOMMU Base Address R/W 1000_0014 Flush All IOTLB Entries W 1000_0018 Address Flush W 1000_1000 Asynchronous Fault Status R/W 1000_1004 Asynchronous Fault Address R/W 1000_1010 SBus Slot Configuration 0 R/W 1000_1014 SBus Slot Configuration 1 R/W 1000_1018 SBus Slot Configuration 2 R/W 1000_101C SBus Slot Configuration 3 R/W 1000_1020 SBus Slot Configuration 4 R/W 1000_1050 Memory Fault Status R/W 1000_1054 Memory Fault Address R/W 1000_2000 Module Identification R/W 1000_3018 Mask Identification R 1000_4000 AFX Queue Level W 1000_6000 AFX Queue Level R 1000_7000 AFX Queue Status R But if I read it correctly 0x12fff294 (which makes SunOS crash with -m 32) is well above this limit. Oh, so I also misread something. You are not talking about the adjacent pages, but 16MB increments. Earlier I sent a patch for a generic address alias device, would it be useful for this? Should do as well. But I thought empty_slot is less overhead and easier to debug. Also the aliasing patch would require one more parameter: the size of area which has to be aliased. Except we implement stubs for all missing devices and and do aliasing of the connected port ranges. And then again, SS-20 doesn't have aliasing in this area at all. What do you think about this (empty_slot) solution (except that I missed the SoB line)? Meanwhile it's tested
[Qemu-devel] Re: [PATCH 1/2] Pad iommu with an empty slot (necessary for SunOS 4.1.4)
On 5/10/10, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/5/9 Blue Swirl blauwir...@gmail.com: On 5/9/10, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/5/9 Blue Swirl blauwir...@gmail.com: On 5/8/10, Artyom Tarasenko atar4q...@googlemail.com wrote: On the real hardware (SS-5, LX) the MMU is not padded, but aliased. Software shouldn't use aliased addresses, neither should it crash when it uses (on the real hardware it wouldn't). Using empty_slot instead of aliasing can help with debugging such accesses. TurboSPARC Microprocessor User's Manual shows that there are additional pages after the main IOMMU for AFX registers. So this is not board specific, but depends on CPU/IOMMU versions. I checked it on the real hw: on LX and SS-5 these are aliased MMU addresses. SS-20 doesn't have any aliasing. But are your machines equipped with TurboSPARC or some other CPU? Good point, I must confess, I missed the word Turbo in your first answer. LX and SS-20 don't. But SS-5 must have a TurboSPARC CPU: ok cd /FMI,MB86904 ok .attributes context-table00 00 00 00 03 ff f0 00 00 00 10 00 psr-implementation psr-version 0004 implementation version 0004 cache-line-size 0020 cache-nlines 0200 page-size1000 dcache-line-size 0010 dcache-nlines0200 dcache-associativity 0001 icache-line-size 0020 icache-nlines0200 icache-associativity 0001 ncaches 0002 mmu-nctx 0100 sparc-version0008 mask_rev 0026 device_type cpu name FMI,MB86904 and still it behaves the same as TI,TMS390S10 from the LX. This is done on SS-5: ok 1000 20 spacel@ . 409 ok 1400 20 spacel@ . 409 ok 1404 20 spacel@ . 23000 ok 1f04 20 spacel@ . 23000 ok 1008 20 spacel@ . 409 ok 1428 20 spacel@ . 409 ok 100c 20 spacel@ . 23000 ok 1010 20 spacel@ . 409 LX is the same except for the IOMMU-version: ok 1000 20 spacel@ . 405 ok 1400 20 spacel@ . 405 ok 1800 20 spacel@ . 405 ok 1f00 20 spacel@ . 405 ok 1ff0 20 spacel@ . 405 ok 1fff0004 20 spacel@ . 1fe000 ok 1004 20 spacel@ . 1fe000 ok 1108 20 spacel@ . 4105 ok 1040 20 spacel@ . 4105 ok 1fff0040 20 spacel@ . 4105 ok 1fff0044 20 spacel@ . 1fe000 ok 1fff0024 20 spacel@ . 1fe000 At what address the additional AFX registers are located? Here's complete TurboSPARC IOMMU address map: PA[30:0] Register Access 1000_ IOMMU Control R/W 1000_0004IOMMU Base Address R/W 1000_0014 Flush All IOTLB EntriesW 1000_0018Address Flush W 1000_1000 Asynchronous Fault Status R/W 1000_1004 Asynchronous Fault Address R/W 1000_1010 SBus Slot Configuration 0 R/W 1000_1014 SBus Slot Configuration 1 R/W 1000_1018 SBus Slot Configuration 2 R/W 1000_101C SBus Slot Configuration 3 R/W 1000_1020 SBus Slot Configuration 4 R/W 1000_1050 Memory Fault Status R/W 1000_1054Memory Fault Address R/W 1000_2000 Module IdentificationR/W 1000_3018 Mask Identification R 1000_4000 AFX Queue Level W 1000_6000 AFX Queue Level R 1000_7000 AFX Queue StatusR But if I read it correctly 0x12fff294 (which makes SunOS crash with -m 32) is well above this limit. Oh, so I also misread something. You are not talking about the adjacent pages, but 16MB increments. Earlier I sent a patch for a generic address alias device, would it be useful for this? Maybe we have a general design problem, perhaps unassigned access faults should only be triggered inside SBus slots and ignored elsewhere. If this is true, generic Sparc32 unassigned access handler should just ignore the access and special fault generating slots should be installed for empty SBus address ranges. One approach would be that IOMMU_NREGS would be increased to cover these registers (with the bump in savevm version field) and iommu_init1() should check the version field to see how much MMIO to provide. The problem I see here is that we already have too much registers: we emulate SS-20 IOMMU (I guess), while SS-5 and LX seem to have only 0x20 registers which are aliased all the way. But in order to avoid the savevm version change, iommu_init1() could just install dummy MMIO (in the TurboSPARC case), if OBP does not care if the read back data matches what has been written earlier. Because from
[Qemu-devel] Re: [PATCH 1/2] Pad iommu with an empty slot (necessary for SunOS 4.1.4)
2010/5/10 Blue Swirl blauwir...@gmail.com: On 5/10/10, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/5/9 Blue Swirl blauwir...@gmail.com: On 5/9/10, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/5/9 Blue Swirl blauwir...@gmail.com: On 5/8/10, Artyom Tarasenko atar4q...@googlemail.com wrote: On the real hardware (SS-5, LX) the MMU is not padded, but aliased. Software shouldn't use aliased addresses, neither should it crash when it uses (on the real hardware it wouldn't). Using empty_slot instead of aliasing can help with debugging such accesses. TurboSPARC Microprocessor User's Manual shows that there are additional pages after the main IOMMU for AFX registers. So this is not board specific, but depends on CPU/IOMMU versions. I checked it on the real hw: on LX and SS-5 these are aliased MMU addresses. SS-20 doesn't have any aliasing. But are your machines equipped with TurboSPARC or some other CPU? Good point, I must confess, I missed the word Turbo in your first answer. LX and SS-20 don't. But SS-5 must have a TurboSPARC CPU: ok cd /FMI,MB86904 ok .attributes context-table 00 00 00 00 03 ff f0 00 00 00 10 00 psr-implementation psr-version 0004 implementation version 0004 cache-line-size 0020 cache-nlines 0200 page-size 1000 dcache-line-size 0010 dcache-nlines 0200 dcache-associativity 0001 icache-line-size 0020 icache-nlines 0200 icache-associativity 0001 ncaches 0002 mmu-nctx 0100 sparc-version 0008 mask_rev 0026 device_type cpu name FMI,MB86904 and still it behaves the same as TI,TMS390S10 from the LX. This is done on SS-5: ok 1000 20 spacel@ . 409 ok 1400 20 spacel@ . 409 ok 1404 20 spacel@ . 23000 ok 1f04 20 spacel@ . 23000 ok 1008 20 spacel@ . 409 ok 1428 20 spacel@ . 409 ok 100c 20 spacel@ . 23000 ok 1010 20 spacel@ . 409 LX is the same except for the IOMMU-version: ok 1000 20 spacel@ . 405 ok 1400 20 spacel@ . 405 ok 1800 20 spacel@ . 405 ok 1f00 20 spacel@ . 405 ok 1ff0 20 spacel@ . 405 ok 1fff0004 20 spacel@ . 1fe000 ok 1004 20 spacel@ . 1fe000 ok 1108 20 spacel@ . 4105 ok 1040 20 spacel@ . 4105 ok 1fff0040 20 spacel@ . 4105 ok 1fff0044 20 spacel@ . 1fe000 ok 1fff0024 20 spacel@ . 1fe000 At what address the additional AFX registers are located? Here's complete TurboSPARC IOMMU address map: PA[30:0] Register Access 1000_ IOMMU Control R/W 1000_0004 IOMMU Base Address R/W 1000_0014 Flush All IOTLB Entries W 1000_0018 Address Flush W 1000_1000 Asynchronous Fault Status R/W 1000_1004 Asynchronous Fault Address R/W 1000_1010 SBus Slot Configuration 0 R/W 1000_1014 SBus Slot Configuration 1 R/W 1000_1018 SBus Slot Configuration 2 R/W 1000_101C SBus Slot Configuration 3 R/W 1000_1020 SBus Slot Configuration 4 R/W 1000_1050 Memory Fault Status R/W 1000_1054 Memory Fault Address R/W 1000_2000 Module Identification R/W 1000_3018 Mask Identification R 1000_4000 AFX Queue Level W 1000_6000 AFX Queue Level R 1000_7000 AFX Queue Status R But if I read it correctly 0x12fff294 (which makes SunOS crash with -m 32) is well above this limit. Oh, so I also misread something. You are not talking about the adjacent pages, but 16MB increments. Earlier I sent a patch for a generic address alias device, would it be useful for this? Should do as well. But I thought empty_slot is less overhead and easier to debug. Maybe we have a general design problem, perhaps unassigned access faults should only be triggered inside SBus slots and ignored elsewhere. If this is true, generic Sparc32 unassigned access handler should just ignore the access and special fault generating slots should be installed for empty SBus address ranges. My impression was that SS-5 and SS-20 do unassigned accesses a bit differently. The current IOMMU implementation fits SS-20, which has no aliasing. One approach would be that IOMMU_NREGS would be increased to cover these registers (with the bump in savevm version field) and iommu_init1() should check the version field to see how much MMIO to provide. The problem I see here is that we already have too much registers: we emulate SS-20 IOMMU (I guess), while SS-5 and LX seem to have only
[Qemu-devel] Re: [PATCH 1/2] Pad iommu with an empty slot (necessary for SunOS 4.1.4)
On 5/10/10, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/5/10 Blue Swirl blauwir...@gmail.com: On 5/10/10, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/5/9 Blue Swirl blauwir...@gmail.com: On 5/9/10, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/5/9 Blue Swirl blauwir...@gmail.com: On 5/8/10, Artyom Tarasenko atar4q...@googlemail.com wrote: On the real hardware (SS-5, LX) the MMU is not padded, but aliased. Software shouldn't use aliased addresses, neither should it crash when it uses (on the real hardware it wouldn't). Using empty_slot instead of aliasing can help with debugging such accesses. TurboSPARC Microprocessor User's Manual shows that there are additional pages after the main IOMMU for AFX registers. So this is not board specific, but depends on CPU/IOMMU versions. I checked it on the real hw: on LX and SS-5 these are aliased MMU addresses. SS-20 doesn't have any aliasing. But are your machines equipped with TurboSPARC or some other CPU? Good point, I must confess, I missed the word Turbo in your first answer. LX and SS-20 don't. But SS-5 must have a TurboSPARC CPU: ok cd /FMI,MB86904 ok .attributes context-table00 00 00 00 03 ff f0 00 00 00 10 00 psr-implementation psr-version 0004 implementation version 0004 cache-line-size 0020 cache-nlines 0200 page-size1000 dcache-line-size 0010 dcache-nlines0200 dcache-associativity 0001 icache-line-size 0020 icache-nlines0200 icache-associativity 0001 ncaches 0002 mmu-nctx 0100 sparc-version0008 mask_rev 0026 device_type cpu name FMI,MB86904 and still it behaves the same as TI,TMS390S10 from the LX. This is done on SS-5: ok 1000 20 spacel@ . 409 ok 1400 20 spacel@ . 409 ok 1404 20 spacel@ . 23000 ok 1f04 20 spacel@ . 23000 ok 1008 20 spacel@ . 409 ok 1428 20 spacel@ . 409 ok 100c 20 spacel@ . 23000 ok 1010 20 spacel@ . 409 LX is the same except for the IOMMU-version: ok 1000 20 spacel@ . 405 ok 1400 20 spacel@ . 405 ok 1800 20 spacel@ . 405 ok 1f00 20 spacel@ . 405 ok 1ff0 20 spacel@ . 405 ok 1fff0004 20 spacel@ . 1fe000 ok 1004 20 spacel@ . 1fe000 ok 1108 20 spacel@ . 4105 ok 1040 20 spacel@ . 4105 ok 1fff0040 20 spacel@ . 4105 ok 1fff0044 20 spacel@ . 1fe000 ok 1fff0024 20 spacel@ . 1fe000 At what address the additional AFX registers are located? Here's complete TurboSPARC IOMMU address map: PA[30:0] Register Access 1000_ IOMMU Control R/W 1000_0004IOMMU Base Address R/W 1000_0014 Flush All IOTLB EntriesW 1000_0018Address Flush W 1000_1000 Asynchronous Fault Status R/W 1000_1004 Asynchronous Fault Address R/W 1000_1010 SBus Slot Configuration 0 R/W 1000_1014 SBus Slot Configuration 1 R/W 1000_1018 SBus Slot Configuration 2 R/W 1000_101C SBus Slot Configuration 3 R/W 1000_1020 SBus Slot Configuration 4 R/W 1000_1050 Memory Fault Status R/W 1000_1054Memory Fault Address R/W 1000_2000 Module IdentificationR/W 1000_3018 Mask Identification R 1000_4000 AFX Queue Level W 1000_6000 AFX Queue Level R 1000_7000 AFX Queue StatusR But if I read it correctly 0x12fff294 (which makes SunOS crash with -m 32) is well above this limit. Oh, so I also misread something. You are not talking about the adjacent pages, but 16MB increments. Earlier I sent a patch for a generic address alias device, would it be useful for this? Should do as well. But I thought empty_slot is less overhead and easier to debug. Maybe we have a general design problem, perhaps unassigned access faults should only be triggered inside SBus slots and ignored elsewhere. If this is true, generic Sparc32 unassigned access handler should just ignore the access and special fault generating slots should be installed for empty SBus address ranges. My impression was that SS-5 and SS-20 do unassigned accesses a bit differently. The current IOMMU implementation fits SS-20, which has no aliasing. It's probably rather the board
[Qemu-devel] Re: [PATCH 1/2] Pad iommu with an empty slot (necessary for SunOS 4.1.4)
On 5/8/10, Artyom Tarasenko atar4q...@googlemail.com wrote: On the real hardware (SS-5, LX) the MMU is not padded, but aliased. Software shouldn't use aliased addresses, neither should it crash when it uses (on the real hardware it wouldn't). Using empty_slot instead of aliasing can help with debugging such accesses. TurboSPARC Microprocessor User's Manual shows that there are additional pages after the main IOMMU for AFX registers. So this is not board specific, but depends on CPU/IOMMU versions. One approach would be that IOMMU_NREGS would be increased to cover these registers (with the bump in savevm version field) and iommu_init1() should check the version field to see how much MMIO to provide. But in order to avoid the savevm version change, iommu_init1() could just install dummy MMIO (in the TurboSPARC case), if OBP does not care if the read back data matches what has been written earlier. Because from OBP point of view this is identical to what your patch results in, I'd suppose this approach would also work.
[Qemu-devel] Re: [PATCH 1/2] Pad iommu with an empty slot (necessary for SunOS 4.1.4)
2010/5/9 Blue Swirl blauwir...@gmail.com: On 5/8/10, Artyom Tarasenko atar4q...@googlemail.com wrote: On the real hardware (SS-5, LX) the MMU is not padded, but aliased. Software shouldn't use aliased addresses, neither should it crash when it uses (on the real hardware it wouldn't). Using empty_slot instead of aliasing can help with debugging such accesses. TurboSPARC Microprocessor User's Manual shows that there are additional pages after the main IOMMU for AFX registers. So this is not board specific, but depends on CPU/IOMMU versions. I checked it on the real hw: on LX and SS-5 these are aliased MMU addresses. SS-20 doesn't have any aliasing. At what address the additional AFX registers are located? One approach would be that IOMMU_NREGS would be increased to cover these registers (with the bump in savevm version field) and iommu_init1() should check the version field to see how much MMIO to provide. The problem I see here is that we already have too much registers: we emulate SS-20 IOMMU (I guess), while SS-5 and LX seem to have only 0x20 registers which are aliased all the way. But in order to avoid the savevm version change, iommu_init1() could just install dummy MMIO (in the TurboSPARC case), if OBP does not care if the read back data matches what has been written earlier. Because from OBP point of view this is identical to what your patch results in, I'd suppose this approach would also work. OBP doesn't seem to care about these addresses at all. It's only the MUNIX SunOS 4.1.4 kernel who does. The MUNIX kernel is the only kernel available during the installation, so it is currently not possible to install 4.1.4. Surprisingly GENERIC kernel which is on the disk after the installation doesn't try to access these address ranges either, so a disk image taken from a live system works. Actually access to the non-connected/aliased addresses may also be a consequence of phys_page_find bug I mentioned before. When I run install with -m 64 and -m 256 it tries to access different non-connected addresses. May also be a SunOS bug of course. 256m used to be a lot back then. -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/
[Qemu-devel] Re: [PATCH 1/2] Pad iommu with an empty slot (necessary for SunOS 4.1.4)
On 5/9/10, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/5/9 Blue Swirl blauwir...@gmail.com: On 5/8/10, Artyom Tarasenko atar4q...@googlemail.com wrote: On the real hardware (SS-5, LX) the MMU is not padded, but aliased. Software shouldn't use aliased addresses, neither should it crash when it uses (on the real hardware it wouldn't). Using empty_slot instead of aliasing can help with debugging such accesses. TurboSPARC Microprocessor User's Manual shows that there are additional pages after the main IOMMU for AFX registers. So this is not board specific, but depends on CPU/IOMMU versions. I checked it on the real hw: on LX and SS-5 these are aliased MMU addresses. SS-20 doesn't have any aliasing. But are your machines equipped with TurboSPARC or some other CPU? At what address the additional AFX registers are located? Here's complete TurboSPARC IOMMU address map: PA[30:0] Register Access 1000_ IOMMU Control R/W 1000_0004IOMMU Base Address R/W 1000_0014 Flush All IOTLB EntriesW 1000_0018Address Flush W 1000_1000 Asynchronous Fault Status R/W 1000_1004 Asynchronous Fault Address R/W 1000_1010 SBus Slot Configuration 0 R/W 1000_1014 SBus Slot Configuration 1 R/W 1000_1018 SBus Slot Configuration 2 R/W 1000_101C SBus Slot Configuration 3 R/W 1000_1020 SBus Slot Configuration 4 R/W 1000_1050 Memory Fault Status R/W 1000_1054Memory Fault Address R/W 1000_2000 Module IdentificationR/W 1000_3018 Mask Identification R 1000_4000 AFX Queue Level W 1000_6000 AFX Queue Level R 1000_7000 AFX Queue StatusR One approach would be that IOMMU_NREGS would be increased to cover these registers (with the bump in savevm version field) and iommu_init1() should check the version field to see how much MMIO to provide. The problem I see here is that we already have too much registers: we emulate SS-20 IOMMU (I guess), while SS-5 and LX seem to have only 0x20 registers which are aliased all the way. But in order to avoid the savevm version change, iommu_init1() could just install dummy MMIO (in the TurboSPARC case), if OBP does not care if the read back data matches what has been written earlier. Because from OBP point of view this is identical to what your patch results in, I'd suppose this approach would also work. OBP doesn't seem to care about these addresses at all. It's only the MUNIX SunOS 4.1.4 kernel who does. The MUNIX kernel is the only kernel available during the installation, so it is currently not possible to install 4.1.4. Surprisingly GENERIC kernel which is on the disk after the installation doesn't try to access these address ranges either, so a disk image taken from a live system works. Actually access to the non-connected/aliased addresses may also be a consequence of phys_page_find bug I mentioned before. When I run install with -m 64 and -m 256 it tries to access different non-connected addresses. May also be a SunOS bug of course. 256m used to be a lot back then. Perhaps with 256MB, memory probing advances blindly from memory to IOMMU registers. Proll (used before OpenBIOS) did that once, with bad results :-). If this is true, 64M, 128M and 192M should show identical results and only with close or equal to 256M the accesses happen.
[Qemu-devel] Re: [PATCH 1/2] Pad iommu with an empty slot (necessary for SunOS 4.1.4)
2010/5/9 Blue Swirl blauwir...@gmail.com: On 5/9/10, Artyom Tarasenko atar4q...@googlemail.com wrote: 2010/5/9 Blue Swirl blauwir...@gmail.com: On 5/8/10, Artyom Tarasenko atar4q...@googlemail.com wrote: On the real hardware (SS-5, LX) the MMU is not padded, but aliased. Software shouldn't use aliased addresses, neither should it crash when it uses (on the real hardware it wouldn't). Using empty_slot instead of aliasing can help with debugging such accesses. TurboSPARC Microprocessor User's Manual shows that there are additional pages after the main IOMMU for AFX registers. So this is not board specific, but depends on CPU/IOMMU versions. I checked it on the real hw: on LX and SS-5 these are aliased MMU addresses. SS-20 doesn't have any aliasing. But are your machines equipped with TurboSPARC or some other CPU? Good point, I must confess, I missed the word Turbo in your first answer. LX and SS-20 don't. But SS-5 must have a TurboSPARC CPU: ok cd /FMI,MB86904 ok .attributes context-table00 00 00 00 03 ff f0 00 00 00 10 00 psr-implementation psr-version 0004 implementation version 0004 cache-line-size 0020 cache-nlines 0200 page-size1000 dcache-line-size 0010 dcache-nlines0200 dcache-associativity 0001 icache-line-size 0020 icache-nlines0200 icache-associativity 0001 ncaches 0002 mmu-nctx 0100 sparc-version0008 mask_rev 0026 device_type cpu name FMI,MB86904 and still it behaves the same as TI,TMS390S10 from the LX. This is done on SS-5: ok 1000 20 spacel@ . 409 ok 1400 20 spacel@ . 409 ok 1404 20 spacel@ . 23000 ok 1f04 20 spacel@ . 23000 ok 1008 20 spacel@ . 409 ok 1428 20 spacel@ . 409 ok 100c 20 spacel@ . 23000 ok 1010 20 spacel@ . 409 LX is the same except for the IOMMU-version: ok 1000 20 spacel@ . 405 ok 1400 20 spacel@ . 405 ok 1800 20 spacel@ . 405 ok 1f00 20 spacel@ . 405 ok 1ff0 20 spacel@ . 405 ok 1fff0004 20 spacel@ . 1fe000 ok 1004 20 spacel@ . 1fe000 ok 1108 20 spacel@ . 4105 ok 1040 20 spacel@ . 4105 ok 1fff0040 20 spacel@ . 4105 ok 1fff0044 20 spacel@ . 1fe000 ok 1fff0024 20 spacel@ . 1fe000 At what address the additional AFX registers are located? Here's complete TurboSPARC IOMMU address map: PA[30:0] Register Access 1000_ IOMMU Control R/W 1000_0004 IOMMU Base Address R/W 1000_0014 Flush All IOTLB Entries W 1000_0018 Address Flush W 1000_1000 Asynchronous Fault Status R/W 1000_1004 Asynchronous Fault Address R/W 1000_1010 SBus Slot Configuration 0 R/W 1000_1014 SBus Slot Configuration 1 R/W 1000_1018 SBus Slot Configuration 2 R/W 1000_101C SBus Slot Configuration 3 R/W 1000_1020 SBus Slot Configuration 4 R/W 1000_1050 Memory Fault Status R/W 1000_1054 Memory Fault Address R/W 1000_2000 Module Identification R/W 1000_3018 Mask Identification R 1000_4000 AFX Queue Level W 1000_6000 AFX Queue Level R 1000_7000 AFX Queue Status R But if I read it correctly 0x12fff294 (which makes SunOS crash with -m 32) is well above this limit. One approach would be that IOMMU_NREGS would be increased to cover these registers (with the bump in savevm version field) and iommu_init1() should check the version field to see how much MMIO to provide. The problem I see here is that we already have too much registers: we emulate SS-20 IOMMU (I guess), while SS-5 and LX seem to have only 0x20 registers which are aliased all the way. But in order to avoid the savevm version change, iommu_init1() could just install dummy MMIO (in the TurboSPARC case), if OBP does not care if the read back data matches what has been written earlier. Because from OBP point of view this is identical to what your patch results in, I'd suppose this approach would also work. OBP doesn't seem to care about these addresses at all. It's only the MUNIX SunOS 4.1.4 kernel who does. The MUNIX kernel is the only kernel available during the installation, so it is currently not possible to install 4.1.4. Surprisingly GENERIC kernel which is on the disk after the installation doesn't try to access these address ranges either, so a disk image taken from a live system works. Actually access to the non-connected/aliased addresses may also be a consequence of phys_page_find bug I mentioned before. When I run install with -m 64 and -m 256 it tries to access different non-connected addresses. May also be a SunOS bug of course. 256m used to be a lot back
