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

[Blue Swirl]

On 5/9/10, Artyom Tarasenko <address@hidden> wrote:
> 2010/5/9 Blue Swirl <address@hidden>:
>
> > On 5/8/10, Artyom Tarasenko <address@hidden> 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_0000       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

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