[Qemu-devel] Memory mapping on MIPS

[Qemu-devel] Memory mapping on MIPS

[Igor R]

I have some issues when accessing guest Linux kernel memory above
0xC0000000 by means of cpu_memory_rw_debug (x86_64 host, MIPS guest),
and I'm trying to debug it.

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

Thanks!

#define KSEG0_BASE 0x80000000UL
#define KSEG1_BASE 0xA0000000UL
#define KSEG2_BASE 0xC0000000UL
#define KSEG3_BASE 0xE0000000UL
//..............
if (address < (int32_t)KSEG1_BASE) {
  /* kseg0 */
  if (kernel_mode) {
    *physical = address - (int32_t)KSEG0_BASE;
    *prot = PAGE_READ | PAGE_WRITE;
  } else {
    ret = TLBRET_BADADDR;
  }
} else if (address < (int32_t)KSEG2_BASE) {
  /* kseg1 */
  if (kernel_mode) {
    *physical = address - (int32_t)KSEG1_BASE;
    *prot = PAGE_READ | PAGE_WRITE;
  } else {
    ret = TLBRET_BADADDR;
  }
} else if (address < (int32_t)KSEG3_BASE) {
    /* sseg (kseg2) */
    if (supervisor_mode || kernel_mode) {
      ret = env->tlb->map_address(env, physical, prot, real_address,
rw, access_type);
    } else {
      ret = TLBRET_BADADDR;
  }

Re: [Qemu-devel] Memory mapping on MIPS

[Leon Alrae]

On 22/02/16 06:56, Igor R wrote:
> 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...

Regards,
Leon

Re: [Qemu-devel] Memory mapping on MIPS

[Igor R]

[-- Attachment #1: Type: text/plain, Size: 1142 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1371 bytes --]

Re: [Qemu-devel] Memory mapping on MIPS

[Igor R]

[-- Attachment #1: Type: text/plain, Size: 1142 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1371 bytes --]

Re: [Qemu-devel] Memory mapping on MIPS

[Maciej W. Rozycki]

On Mon, 22 Feb 2016, Igor R wrote:

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

 The 32-bit MIPS port of Linux uses KSEG2 for kernel virtual mappings, 
that is memory allocated via `vmalloc' and loadable modules.  Your luck is 
the former is seldom used and you may not have loadable modules in your 
configuration either.

  Maciej