2,939
edits
Changes
Jump to navigation
Jump to search
Line 5:
Line 5: − + Line 39:
Line 39: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Line 157:
Line 209: − Line 198:
Line 249: − Line 213:
Line 263: − +
no edit summary
! Word || Bits || Description
! Word || Bits || Description
|-
|-
| 0 || 15-0 || Type. 0=LegacyRequest?, 1=LegacyControl?, 2=Close, 3=? 4=Request, 5=Control, 6=[5.0.0+] NewRequest, 7=[5.0.0+] NewControl
| 0 || 15-0 || [[#Type|Type]].
|-
|-
| 0 || 19-16 || Number of buf X descriptors (each: 2 words).
| 0 || 19-16 || Number of buf X descriptors (each: 2 words).
First two header u32's and handle descriptor (if enabled) are copied as-is from one process to the other.
First two header u32's and handle descriptor (if enabled) are copied as-is from one process to the other.
=== Type ===
IPC commands can have different types which influence how the IPC server processes requests in "nn::sf::hipc::server::HipcServerSessionManagerBase::ProcessRequest".
{| class="wikitable" border="1"
|-
! Value || Name
|-
| 0 || Invalid
|-
| 1 || [[#LegacyRequest, LegacyControl|LegacyRequest]]
|-
| 2 || [[#Close|Close]]
|-
| 3 || [[#LegacyRequest, LegacyControl|LegacyControl]]
|-
| 4 || [[#Request, Control|Request]]
|-
| 5 || [[#Request, Control|Control]]
|-
| 6 || [5.0.0+] [[#RequestWithContext, ControlWithContext|RequestWithContext]]
|-
| 7 || [5.0.0+] [[#RequestWithContext, ControlWithContext|ControlWithContext]]
|}
==== Close ====
When processing a request of this type, the IPC server calls:
* "nn::sf::hipc::server::HipcServerSessionManager::DestroyServerSession"
* "nn::sf::hipc::CloseServerSessionHandle"
This ensures that the server session is destroyed internally and properly closed.
==== LegacyRequest, LegacyControl ====
These types are handled by calling:
* "nn::sf::hipc::detail::HipcMessageBufferAccessor::ParseHeader"
* "nn::sf::hipc::server::HipcServerSessionManager::ProcessMessage"
* "nn::sf::hipc::Reply"
* "nn::sf::hipc::server::HipcServerSessionManager::RegisterServerSessionToWaitBase"
It is speculated that these are part of an older message processing system where headers were further partitioned.
==== Request, Control ====
These types are handled by calling:
* "nn::sf::hipc::server::HipcServerSessionManager::ProcessMessage2"
* "nn::sf::hipc::server::HipcServerSessionManager::RegisterServerSessionToWaitBase"
This represents a more modern message handling system where contents follow the general marshalling structure.
==== RequestWithContext, ControlWithContext ====
These are identical to normal Request and Control types, but with the additional requirement of suppling a token in their [[#Data payload|data payload]].
This token is used by "nn::sf::cmif::SetInlineContext" which has the sole purpose of saving it into the TLS in order for it to be distributed to any IPC commands that are made while processing the current command. It's unknown if this token serves any purpose or if it's just a debug-tool to figure out what IPC command caused a particular chain of commands.
=== Handle descriptor ===
=== Handle descriptor ===
== Raw data section ==
== Raw data section ==
[[File:Ipc msg buffer type a example.png|thumb|An example of an IPC message with a type 0xA buffer in it. Red is headers/descriptors, yellow is padding, and blue is data/buffer lengths. Note that the size of the u16 array for type A lengths is padded to fill up a whole word.]]
[[File:Ipc msg buffer type a example.png|thumb|An example of an IPC message with a type 0xA buffer in it. Red is headers/descriptors, yellow is padding, and blue is data/buffer lengths. Note that the size of the u16 array for type A lengths is padded to fill up a whole word.]]
=== Data payload ===
=== Data payload ===
This is an array of u32's, but individual parameters are generally stored as u64's.
This is an array of u32's, but individual parameters are generally stored as u64's.
|}
|}
[5.0.0+] A token value was introduced into raw_data+12 (regardless of domain or not, in either case it overlaps with padding). When a service processes an incoming IPC cmd, the token value gets saved into TLS and is distributed to any IPC cmds that are made during processing of the IPC cmd. It's unknown if this token serves any purpose or if it's just a debug-tool to figure out what IPC cmd caused a particular chain of IPC cmds.
[5.0.0+] A token value was introduced into raw_data+12 (regardless of domain or not, in either case it overlaps with padding).
== Official marshalling code ==
== Official marshalling code ==