Igor Kovalenko wrote:
This ofmem_update_translations call is supposed to keep available physical memory ranges up-to-date. There are no other places where we do update available phys ranges. Virtual ranges and MMU translations we update at the same time; since virtual allocations and MMU translations are not affected at this call site the resulting lists of virtual ranges and MMU translations are not changed.
The only thing which may change here is actual placement of "translations" property value, so if you keep pointer to previous location it may be stale after update call.
What is the issue you are solving here?
I've just done some more experimentation with r738 by replacing the call to ofmem_update_translations() with its constituent functions.
If I replace it with the following:
ofmem_update_memory_available(s_phandle_memory, ofmem->phys_range, get_ram_size());
- Everything works okay.
If I replace it with:
ofmem_update_memory_available(s_phandle_memory, ofmem->phys_range, get_ram_size());
ofmem_update_memory_available(s_phandle_mmu, ofmem->virt_range, -1ULL);
- Everything still works okay.
If I replace it with:
ofmem_update_memory_available(s_phandle_memory, ofmem->phys_range, get_ram_size());
ofmem_update_memory_available(s_phandle_mmu, ofmem->virt_range, -1ULL);
ofmem_update_mmu_translations();
- Forth starts misbehaving and the translate call crashes.
This points the finger at ofmem_update_mmu_translations(). Given that this is a physical memory allocation, is there any reason why I shouldn't change r739 to instead of removing ofmem_update_translations() to just replace it with:
ofmem_update_memory_available(s_phandle_memory, ofmem->phys_range, get_ram_size());
This is because for a physical allocation there is no need to update the virt_range nor the MMU translations. And it seems to work so far in testing.
ATB,
Mark.