Service_PagesUnsafe (changes)
Showing changes from revision #4 to #5:
Added | Removed | Changed
Programmer's Reference Manuals
» Service Calls
» Service_PagesUnsafe
Service_PagesUnsafe
(Service &8E)
| Entry | |
|---|---|
| R1 | 142 (&8E) |
| R2 | |
| R3 | Number of entries in page block array |
| Exit | |
|---|---|
| All registers preserved |
Use
This service is issued to inform recipients that the pages specified are about to be swapped with different pages, e.g. as a result of a Dynamic Area PreGrow handler requesting pages which are currently in use by another area. DMA operations involving these pages should be suspended until Service_PagesSafe is received.
For example:
- Physical page 1 is currently mapped to logical address &8000
- A Dynamic Area PreGrow handler requests that physical page 1 be added to its DA
- The kernel detects that page 1 is already in use, so it takes a page from the free pool (e.g. page 200), and copies the contents of page 1 into it.
- The address translation for the pages is updated so that page 200 is now located at &8000. Page 1 gets added to the dynamic area.
By copying the contents of page 1 into page 200 and placing it at &8000, the kernel ensures that software which accesses memory by logical address (i.e. most software) will be completely unaffected by the fact that page 1 is now owned by the dynamic area.
However hardware devices and hardware drivers typically interact with memory using physical addresses. E.g. if a file is being loaded into memory at &8000, the device driver would initiate a DMA transfer to physical page 1. Under normal circumstances this would result in the requested data appearing at &8000 once the DMA transfer completes. But if page 1 gets reassigned during the transfer, and the device driver isn’t notified of this, the data will appear in the DA’s memory instead of appearing at &8000. This is why Service_PagesUnsafe exists – to provide DMA drivers the opportunity to pause their operation until the page has been swapped by the CPU (and then resume the operation using the new mapping, provided by Service_PagesSafe).
Note that the page copy & remap operation is performed with IRQs disabled and with the FIQ vector temporarily claimed by the kernel. This ensures that any interrupt handlers which are using the pages (by logical address) do not need to be aware of the copy operation.
Notes
This service call must not be claimed.
Because of the page block format used, this call will only report changes to pages which have 32 bit addresses. On versions of RISC OS which support larger addresses, the OS will issue Service_PagesUnsafe64 before this call, describing all the pages. Specifically, service calls will be issued in the following sequence:
- Service_PagesUnsafe64, describing all pages
- Service_PagesUnsafe, describing only the pages which have 32 bit addresses (and which be given replacements with 32 bit physical addresses)
- Service_PagesSafe, describing only the pages which have 32 bit addresses (and which have been given replacements with 32 bit physical addresses)
- Service_PagesSafe64, describing all pages
Because the 64 bit versions always surround calls of the 32 bit versions, any software which sees a 64 bit call can ignore the following 32 bit calls.
See also
Social
and
ROOL Store
Buy RISC OS Open merchandise here, including SD cards for Raspberry Pi and more.