Kernel asynchronous file reads
The kernel AIO API accepts a batch of reads and returns an identifier. PS5PCEM performs the batch at submission, which the interface allows, and the title collects a finished result.
Repository notes through October 10, 2026
The interface
Engines that stream assets submit a list of reads and later ask whether the batch is done. A title built that way cannot load a file without the API. PS5PCEM accepts the batch, runs the reads when it is submitted, and stores the results under the identifier. A later poll observes a batch that has already completed.
Completing immediately is a legal outcome of the interface. Callers are required to handle a request that finished before the poll. The emulator does not sleep to imitate device latency, and it does not report the batch as failed in order to look more asynchronous.
How this differs from APR
Kernel AIO is the POSIX-style batch on file descriptors the title already opened. APR is the accelerator path: paths become identifiers, and the commands live in an AMPR command buffer with counters and completion events. A title can use either, or both.
Both paths read the title install as data the emulator did not produce. Bounds are checked. A short buffer or a bad descriptor is an error return, not a partial write presented as success.
What is implemented
- Batch submission, an identifier, and a completion the title can collect.
- Reads performed against the files the title opened.
- Immediate completion, which the guest API permits.
What is still missing
- There is no separate I/O thread imitating disk latency.
- The console's priority and bandwidth scheduler is not modeled.
- APR command buffers are a different API and are not rewritten into kernel AIO.
Related mechanisms
What these pages are