> > Here is an excerpt from r4k_map_address(), related to addresses >= 0x80000000. > > Actually, it maps 0x80000010 and 0xA0000010 to the same physical > > address. What's the idea behind that? > > 0x80000010 is kseg0 whereas 0xA0000010 is kseg1, both segments are > unmapped thus both refer to the same 0x10 physical address. The > difference between them is that the latter is uncached, i.e. all > accesses to this segment bypass the caches, but in QEMU we don't model > caches so they do the same thing. > > > What should happen if I map KSEG2 directly as a continuation of KSEG1, > > i.e. substitute TLB lookup with "address - (int32_t)KSEG1_BASE"? Guest > > Linux seems to work correctly (but maybe it's just a matter of luck?). > > With such a change it's very likely that guest through kseg2 will be > accessing different physical addresses than it expects...
I see, thanks. As far as I can see now, my problem is that cpu_memory_rw_debug doesn't handle tlb misses at all - that's why it fails for many addresses in kseg2. Is it the desired behavior or a bug? Is there any other simple way to read from the guest virt.addrs? Thanks!
