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

[Artyom Tarasenko]

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.

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/