Returning PMP pages to original locations

I’ve successfully moved pages within a PMP DA with OS_DynamicArea
22, using a block, for example, like this:

typedef struct pmp_log_page_entry
{
  int da_page_number;
  int pmp_page_index;
  unsigned flags;
} pmp_log_page_entry;

pmp_log_page_entry entry;

entry.da_page_number = 1;
entry.pmp_page_index = 2;
entry.flags = 0;

Where page 1 is claimed, but not mapped and page 2 is claimed, mapped and contains data.
This would move page 2 to page 1’s location.

What’s the correct way to move page 2 back to its original location?

Is it:

entry.da_page_number = 2;
entry.pmp_page_index = 1;
entry.flags = 0;

Move the page at page location 1 back to page 2’s location, or:

entry.da_page_number = 1;
entry.pmp_page_index = -1;
entry.flags = 0;

Unmap the page at page location 1; will the page automatically be returned to its original page 2 location? Or:

entry.da_page_number = 2;
entry.pmp_page_index = 2;
entry.flags = 0;

Move page 2 to page 2’s location?

Or something else?

Thanks,
Lee.

I think you’re a bit confused over the different indexing schemes. Perhaps this hastily drawn diagram will help? (it’s a bit big, but it turns out I don’t have any vector graphics software on my work computer, so just deal with it)

In total there are three different types of index (or I guess five if you include logical & physical addresses).

• DA page numbers index the logical address space occupied by your dynamic area. logical_address = da_base + da_page_number*4096. With regular DAs there’ll always be a physical page associated with the DA page number. With sparse or PMP DAs you can have gaps which map to no physical page.
• Physical page numbers are what RISC OS uses to track RAM. They can be mapped to and from physical addresses, but only by means of the table of physical RAM chunks (“PhysRamTable”) that the kernel stores internally, so kernel SWIs must be used to convert physical page numbers to and from physical addresses. Only RAM which can be manipulated using memory map SWIs like OS_SetMemMapEntries will be assigned a physical page number (e.g. the RAM which ROM images are loaded into isn’t included in PhysRamTable)
• PMP page numbers identify the different “slots” which physical pages can be allocated to. There’s no direct relation between the PMP page number and the between logical or physical address; if I wanted I could have just had all the PMP pages floating around in a big circle to highlight this, but drawing them in a vertical list was easier.
• There’s a 1-1 relationship between a PMP-based DA and the PMP itself.
• Physical pages can either be allocated directly to a DA, allocated to a PMP, or allocated to nowhere. The same physical page can’t be allocated to multiple places (except for doubly-mapped DAs, which allow the page to be mapped to two logical addresses at once)
• For a PMP-based DA, you can only map a PMP page into the logical address space if it has a physical page allocated to it. And as with regular DAs, a PMP page can’t be mapped to two logical locations at once.
• DA and PMP page numbers are private to each DA/PMP (i.e. each DA/PMP has its pages numbered starting from zero). Physical page numbering is global.

So looking at your first call:

entry.da_page_number = 1;
entry.pmp_page_index = 2;
entry.flags = 0;

The OS will actually perform the following process:

1. Check to see if this mapping already exists. If so, do nothing. Otherwise:
2. Check to see if any PMP page is currently mapped to DA page 1. If so, unmap it.
3. Check to see if PMP page 2 is currently mapped anywhere. If so, unmap it.
4. Map PMP page 2 to DA page 1

So to answer the question “What’s the correct way to move page 2 back to its original location?”, the correct way would be to first work out what the original location was (maybe your code already knows it, or maybe it should use OS_DynamicArea 25 to look it up), and then issue a call like the following:

entry.da_page_number = original_location;
entry.pmp_page_index = 2;
entry.flags = 0;

How does task switching fit into this? I’m trying to work out how the AMB stuff works and what the Wimp does with it, but it’s not simple!

How does task switching fit into this? I’m trying to work out how the AMB stuff works and what the Wimp does with it, but it’s not simple!

Original AMB implementation: Each AMB stored a list of physical pages, and the code manipulated the memory map manually. This allowed the memory to be mapped in/out similar to how PMPs support it, but the code wasn’t very well integrated with the kernel’s core memory management, so some operations suffered from inefficiencies.

New AMB implementation: Each AMB has a PMP dynamic area associated with it. This allows the standard DA/PMP memory mapping functions to be used (although for performance a number of the original AMB functions are still used – they were well optimised for their respective tasks and it’s hard for the generic DA/PMP functions to compete). But there’s still one horrible hack, which is that the DAs all overlap (they have a base address of &8000), so the system still has to be careful not to allow multiple AMBs to be mapped in ontop of each other (since the standard DA/PMP code isn’t designed to cope with that). Also to avoid confusing other software the dynamic areas aren’t included in the main dynamic area list (so OS_DynamicArea 3 will never return the DA), which also means that the AMB code has to use special backdoors into OS_DynamicArea which allow it to provide a direct pointer to the area instead of using DA numbers.

I think you’re a bit confused over the different indexing schemes.

More than likely :-)

Perhaps this hastily drawn diagram will help?

Yes, thanks.

Just to be clear, when I talk about returning pages to their original location, I mean their original logical position from when I first claimed and mapped the pages.

There’s no direct relation between the PMP page number and the logical or physical address

Maybe this is where I’m going wrong. I’m using this code to generate the mapping arrays where client_library→map and client_library→unmap are arrays of pmp_log_page_entry.
I’m assuming that I can just reverse the page numbers in the arrays to undo the page move, but maybe I’m over simplifying it.

_kernel_oserror *
som_map_find_mappings (som_client_object *client_library)
{
  page_allocator *allocator = &global.paged_memory;
  _kernel_oserror *err;
  int num_pages = bytes_to_pages(client_library->library->object.data_size);

  if ((err = som_alloc (sizeof(pmp_log_page_entry) * num_pages * 2,
			(void **)&client_library->map)) != NULL)
    return err;

  client_library->unmap = client_library->map + num_pages;
  client_library->num_pages = num_pages;

  void *addr_src = client_library->data_segment;
  void *addr_dst = client_library->library->object.text_segment +
			page_align_size(client_library->library->object.text_size);

  int i, pmp_index, da_page_num;
  for (i = 0,
         pmp_index = (addr_src - allocator->da.base_addr) >> PAGE_SIZE_SHIFT,
         da_page_num = (addr_dst - allocator->da.base_addr) >> PAGE_SIZE_SHIFT;
       i < num_pages;
       i++, pmp_index++, da_page_num++)
    {
      client_library->map[i].da_page_number = da_page_num;
      client_library->map[i].pmp_page_index = pmp_index;
      client_library->map[i].flags = PMP_MEM_ACCESS_RWE_RWE;

      /* The unmap array reverses the above page mappings so that the pages
         are returned to their original positions.  */
      client_library->unmap[i].da_page_number = pmp_index;
      client_library->unmap[i].pmp_page_index = da_page_num;
      client_library->unmap[i].flags = PMP_MEM_ACCESS_RWE_RWE;
    }

  return NULL;
}

So looking at your first call:

entry.da_page_number = 1;
entry.pmp_page_index = 2;
entry.flags = 0;

So to answer the question “What’s the correct way to move page 2 back to its original location?”, the correct way would be to first work out what the original location was (maybe your code already knows it, or maybe it should use OS_DynamicArea 25 to look it up), and then issue a call like the following:

entry.da_page_number = original_location;
entry.pmp_page_index = 2;
entry.flags = 0;

So if I have mapped that page to DA page 1 as in the first call, will setting original_location to 2 cause it to be mapped back to DA page 2? Or is the page numbering not that simple?

Sorry if I’m not getting it, hopefully it’ll click in the near future :-)

Just to be clear, when I talk about returning pages to their original location, I mean their original logical position from when I first claimed and mapped the pages.

When you claim a page using OS_DynamicArea 21, it won’t be mapped to any logical address (I’ll add that note to the wiki!)

You can unmap pages by specifying a PMP page index of -1 to OS_DynamicArea 22; i.e. your loop probably wants to do the following:

client_library->unmap[i].da_page_number = da_page_num;
client_library->unmap[i].pmp_page_index = -1;

(Note that the flags are ignored when mapping out)