VMM alloc fails about lk HOT 10 CLOSED

I tried my fork on another qcom device and it works. I'm not sure if it's a arch problem or not.
Noticeable differences:

• the broken device uses a full, non-temporary identity map:
  https://github.com/grub4android/lk/blob/travis-vm/platform/qcom/start.S#L113
  but they get ignored by the VM:
  grub4android/lk@5038e62

from lk.

If I enable the full identity map on the working device, vmm alloc breaks there too.
Is there anything I'm missing?

from lk.

fixed by excluding the VM's aspace from the identity map.

from lk.

Here is my guess.. (However, I work on the x86 PC platforms; not completely familiar with ARM)

Looks like you are mapping a physical address which is not section aligned (1MB alignment) ? Whereas, your virtual address is "MB" aligned (SECTION aligned).

And, then the flag is set as “MMU_MEMORY_L1_DESCRIPTOR_SECTION” hinting that you or looking at L1 table rather than going with a L2 page table by creating one?
So, should you be having "MMU_MEMORY_L1_DESCRIPTOR_INVALID" flag instead of the "MMU_MEMORY_L1_DESCRIPTOR_SECTION" at this point?

from lk.

The main problem is the kernel is not running out of the 'memory' identity map. There's probably a hidden kernel mapping at 0x40000000 where the kernel is based to run at, which immediately gets trashed as soon as you create a VMM region.

Generally speaking you should identity map memory at the base of the kernel, so that the kernel can run out of it. There should be no mappings anywhere that aren't covered by a VMM region, or the vmm allocator will step on it and get upset like it did.

If you need to move the base of the kernel, you can move it in your platform's rules file like
https://github.com/travisg/lk/blob/master/platform/zynq/rules.mk#L51

The default is 0x40000000 on arm, so that the eventual user space page directory would only need to be a page in size, but it's pretty flexible, and kernel space can be set anywhere on a 1MB section boundary.

from lk.

@travisg The problem is, that qcom's msm8960 has a weird MMU setup. Without a identity map registers are completely inaccessible.
That means I need a identity map on the whole RAM which is persistent - as soon as it get's unmapped the system crashes.

I guess since everything above 0x40000000 gets handled and mapped by LK's VMM anyway it's ok to use a identity map that covers the first 0x40000000 bytes only - at least the system boots and works this way.

offtopic: It just took me 1h to fix the PMM mapping on msm8610, because the usable RAM starts at 0x0 there and the heap treats the return value from pmm_alloc(=0x0) as a error then :P (I ignore the first page as a workaround)

from lk.

The general idea for registers is to map them into kernel space at a different offset, and access them through the offset. For example, you may map registers up at 0xf0000000 regardless of where they are in physical space.

from lk.

@travisg that registers are the problem was just a theory because it usually fails when initializing timer or gic.(I can't debug these things that early).

I guess another problem are applications like TZ(TrustedZone) which are running in the background and have no idea how virtual memory works.

from lk.

@travisg you're right about the phys-virt mapping(that I should access registers via a virtual address).
The problem is that I need the fixed (qcom generic) reg map from the linux kernel to not break TZ.
This by itself is not a big deal - what's bad is that these are 4K aligned.

So could you change LK's MMU alignment to 4k - or even better: make it dynamic ?

from lk.

I researched on that topic and it seems we need level2 translation table support in LK for that.

from lk.