Merge pull request #108 from TheNullicorn/xvio-revision

Replace "context" with "service" in XVIO pages

docs/development/xvio/ring-buffers/xvio-create-ring-buffer.md

@@ -4,7 +4,7 @@ Creates a ring buffer for passing large amounts of data between partitions. Inte
 ## Syntax
 ```cpp title='C++'
 NTSTATUS XvioCreateRingBuffer(
-    uint32_t ContextId,
+    uint32_t ServiceId,
     uint64_t TargetPartition,
     uint16_t Unk1,
     uint32_t ReceivePageCount,
@@ -14,8 +14,8 @@ NTSTATUS XvioCreateRingBuffer(
 ```
 
 ## Parameters
-`uint32_t ContextId`  
-The *[Context ID](../xvio-overview.md/#context-identifiers)* to communicate to on the remote partition.
+`uint32_t ServiceId`  
+The *[Service ID](../xvio-overview.md/#service-identifiers)* to communicate to on the remote partition.
 
 `uint64_t TargetPartition`  
 Target partition for the ring buffer to be shared with. *See [partition identifiers](../xvio-overview.md/#partition-identifiers) for a list of partitions and their corresponding IDs.*  

docs/development/xvio/ring-buffers/xvio-get-ring-buffer-context-safe.md

@@ -1,20 +1,20 @@
 # XvioGetRingBufferContextSafe
-Safe version of *[XvioGetRingBufferContext](./xvio-get-ring-buffer-context.md).* Essentially just checks if the XVIO context is initialized and the *ContextId* parameter matches the ring buffer's context ID.
+Safe version of *[XvioGetRingBufferContext](./xvio-get-ring-buffer-context.md).* Essentially just checks if the XVIO service is initialized and the *ServiceId* parameter matches the ring buffer's service ID.
 
 ## Syntax
 ```cpp title='C++'
 PXVIO_RING_BUFFER XvioGetRingBufferContext(
     uint32_t TargetPartition,
-    uint32_t ContextId
+    uint32_t ServiceId
 );
 ```
 
 ## Parameters
 `uint32_t TargetPartition`  
 The *[Partition ID](../xvio-overview.md/#partition-identifiers)* of the partition the ring buffer targets.
 
-`uint32_t ContextId`  
-The *[Context ID](../xvio-overview.md/#context-identifiers)* of the XVIO context the ring buffer targets.
+`uint32_t ServiceId`  
+The *[Service ID](../xvio-overview.md/#service-identifiers)* of the XVIO service the ring buffer targets.
 
 ## Return value
 Returns a pointer to a **XVIO_RING_BUFFER** structure.

docs/development/xvio/xvio-cleanup.md

@@ -1,16 +1,16 @@
 # XvioCleanup function
-Cleans up and frees an XVIO Context ID. Also destroys the allocated ring buffer, if one has been allocated.
+Cleans up and frees an XVIO Service ID. Also destroys the allocated ring buffer, if one has been allocated.
 
 ## Syntax
 ```cpp title='C++'
 NTSTATUS XvioCleanup(
-    uint32_t XvioContextId
+    uint32_t XvioServiceId
 );
 ```
 
 ## Parameters
-`uint32_t XvioContextId`  
-The ID of the context to be cleaned up, same as the one created with *XvioInitialize.*
+`uint32_t XvioServiceId`  
+The ID of the service to be cleaned up, same as the one created with *XvioInitialize.*
 
 ## Return value
 Returns a generic **NTSTATUS** value.

docs/development/xvio/xvio-initialize.md

@@ -1,15 +1,15 @@
 # XvioInitialize function
-Initializes an XVIO Context with the requested ID.
+Initializes an XVIO Service with the requested ID.
 
 ## Syntax
 ```cpp title='C++'
 NTSTATUS XvioInitialize(
-    uint32_t XvioContextId,
+    uint32_t XvioServiceId,
     uint64_t TargetPartition,
     uint64_t Unk1,
     uint64_t Unk2,
     void (*ReceiveMessageCallback)(
-        uint64_t XvioContextId,
+        uint64_t XvioServiceId,
         uint64_t RemotePartition,
         uint16_t MessageCode,
         uint32_t DataSize,
@@ -20,8 +20,8 @@ NTSTATUS XvioInitialize(
 ```
 
 ## Parameters
-`uint32_t XvioContextId`  
-The unique Context ID for the XVIO instances, acting as a unique identifier for the driver or a link to a remote driver. Do note that only one Context IDs are **unique** meaning two drivers (in the same partition) cannot allocate the same Context ID. It is also worth mentioning that the amount of available XVIO Contexts in a partition is **finite**, totalling **32** IDs. *For more detail, see [context identifiers](./xvio-overview.md/#context-identifiers).*
+`uint32_t XvioServiceId`  
+The unique Service ID for the XVIO instances, acting as a unique identifier for the driver or a link to a remote driver. Do note that only one Service IDs are **unique** meaning two drivers (in the same partition) cannot allocate the same Service ID. It is also worth mentioning that the amount of available XVIO Services in a partition is **finite**, totalling **32** IDs. *For more detail, see [service identifiers](./xvio-overview.md/#service-identifiers).*
 
 `uint64_t TargetPartition`  
 The target partition (*see [Partition IDs](./xvio-overview.md/#partition-identifiers)*) - *can be **0**, permitting communication with all remote partitions.*
@@ -42,5 +42,5 @@ Similar to `ReceiveMessageCallback` but doesn't seem to be specific to messages.
 Returns your standard **NTSTATUS** with some extra XVIO statuses added on top (will document these soon)
 
 ## Important notes
-When called, *XvioInitialize* checks if the *XvioContextId* has already been initialized. In **most** cases, all context ID's are typically already in use within a partition, meaning a developer would likely have to hijack an XVIO context.  
-*Research into this is planned but is* **currently** *impossible, as fully hijacking XVIO contexts would likely require kernel function hooks for callback functions (in all applicable partitions)*
+When called, *XvioInitialize* checks if the *XvioServiceId* has already been initialized. In **most** cases, all service ID's are typically already in use within a partition, meaning a developer would likely have to hijack an XVIO service.  
+*Research into this is planned but is* **currently** *impossible, as fully hijacking XVIO services would likely require kernel function hooks for callback functions (in all applicable partitions)*

docs/development/xvio/xvio-overview.md

@@ -3,10 +3,10 @@ The *XVIO driver* (`xvio.sys`) facilitates all communication between the virtual
 
 Whilst each partition has it's own version of `xvio.sys`, the differences appear to be minor, as each driver is simply being built using different preprocessor definitions to target different partitions.  
 
-## Context identifiers  
-The context identifier is an ID that is unique to an instance of XVIO that is initialized using *[XvioInitialize](./xvio-initialize.md).* In total there are 32 unique identifiers available to a partition. This number is finite as all the contexts are stored within an array in `xvio.sys`'s data section, where contexts are allocated to drivers where needed.  
+## Service identifiers  
+The service identifier is an ID that is unique to an instance of XVIO that is initialized using *[XvioInitialize](./xvio-initialize.md).* In total there are 32 unique identifiers available to a partition. This number is finite as all the services are stored within an array in `xvio.sys`'s data section, where services are allocated to drivers where needed.  
 
-You may find it helpful to think of a context ID as a driver ID. This is because when communicating between partitions, it is the context ID that specifies what driver (on the remote partition) to communicate with. For example, `xvmm.sys` *- the virtual machine manager on HostOS -* uses the context identifier `0xf`. Thus, to communicate with this driver, `xvmctrl.sys` *- the virtual machine control driver on SystemOS -* uses that same ID to send requests to the VM manager. Furthermore, for the sake of continuity, it is common for drivers with similar functionality to use the same context ID on different partitions, despite it not being strictly necessary from a functional stand-point. With this in mind, we can be certain that all drivers related to virtual machine management and control allocate the context ID `0xf` on their respective operating systems.
+You may find it helpful to think of a service ID as a driver ID. This is because when communicating between partitions, it is the service ID that specifies what driver (on the remote partition) to communicate with. For example, `xvmm.sys` *- the virtual machine manager on HostOS -* uses the service identifier `0xf`. Thus, to communicate with this driver, `xvmctrl.sys` *- the virtual machine control driver on SystemOS -* uses that same ID to send requests to the VM manager. Furthermore, for the sake of continuity, it is common for drivers with similar functionality to use the same service ID on different partitions, despite it not being strictly necessary from a functional stand-point. With this in mind, we can be certain that all drivers related to virtual machine management and control allocate the service ID `0xf` on their respective operating systems.
 
 ## Partition identifiers
 A lot of the XVIO functions take a partition ID as an argument, allowing for IO with a specified partition. An enumeration outlining these IDs can be found below:  

docs/development/xvio/xvio-post-message.md

@@ -1,10 +1,10 @@
 # XvioPostMessage function
-Sends a message (asynchronously) to the target partition. The message is then handled by an *XVIO context* within one of the remote partition's drivers. 
+Sends a message (asynchronously) to the target partition. The message is then handled by an *XVIO service* within one of the remote partition's drivers. 
 
 ## Syntax
 ```cpp title='C++'
 NTSTATUS XvioPostMessage(
-    uint32_t TargetContextId,
+    uint32_t TargetServiceId,
     uint64_t TargetPartition,
     uint64_t MessageCode,
     uint16_t DataSize,
@@ -13,8 +13,8 @@ NTSTATUS XvioPostMessage(
 ```
 
 ## Parameters
-`uint32_t TargetContextId`  
-The context ID of the target XVIO instance *(pretty much the target driver)* on the target partition.
+`uint32_t TargetServiceId`  
+The service ID of the target XVIO instance *(pretty much the target driver)* on the target partition.
 
 `uint64_t TargetPartition`  
 Pretty self-explanatory, the partition the message is targeted to, be it HostOS, SystemOS or GameOS. *See [Partition IDs](./xvio-overview.md#partition-identifiers) for more details.*