Support KeCreateUserMode/KeEnterUserMode for XeFu backward compatibility

This is a follow-up to #1352 (emoose's XeFu boot attempt, 2019). That issue identified that XeFu (xefu.xex, the Xbox 360's OG Xbox backward compatibility emulator) fails to boot in Xenia because two kernel exports are unimplemented.

What XeFu needs XeFu imports two key kernel functions by ordinal from xboxkrnl.exe:

Ordinal 94 (KeCreateUserMode) — Creates an isolated user-mode execution context Ordinal 101 (KeEnterUserMode) — Enters that context, transitioning to user-mode privilege These are documented in XbSymbolDatabase and partially in Free60. Later kernel versions (17559) also export v2 variants at ordinals 858/859 and thread variants at 816/817.

Functional contract (clean-room behavioral description) KeCreateUserMode(object, count):

Allocates count memory descriptor entries (each ~20 bytes, tagged 'AcsF') Initializes a linked list structure on the object for managing these entries Maps/commits each entry's described memory region Returns STATUS_SUCCESS or STATUS_INSUFFICIENT_RESOURCES Does NOT directly invoke the hypervisor — purely kernel-side data structure setup KeEnterUserMode(context_id, sub_id):

Acquires a kernel lock Retrieves the current thread's context from KPCR Walks a linked list of user-mode context entries Matches entries by context_id (and optionally sub_id) On match: atomically exchanges a callback function pointer from the entry (compare-and-swap pattern) If the callback was non-null: invokes it with (context_data, entry) as arguments The callback ultimately triggers a syscall that transitions the CPU to user-mode privilege (Problem State) with address translation enabled Returns 1 if a matching context was found and entered, 0 otherwise The privilege transition model The Xbox 360 kernel uses the hypervisor's syscall mechanism to transition between kernel and user mode. The relevant syscall:

Sets the CPU to Problem State (user mode) Enables instruction and data address translation Reconfigures the Segment Lookaside Buffer (SLB) for address space isolation Redirects execution to a kernel-resident user-mode entry point User-mode code can call back to the kernel via sc instructions, which the hypervisor dispatches based on whether the caller was in user mode or kernel mode.

What Xenia needs to implement Since Xenia doesn't emulate the hypervisor (it intercepts at the API boundary), the shim is:

Ordinal 94 stub: Allocate and track memory descriptors. Map the described regions in Xenia's guest memory manager. Ordinal 101 stub: Walk the context list, execute the callback mechanism (the atomic exchange + indirect call is critical — it's not just "set a flag and return"), and redirect guest execution to the user-mode entry point. User-mode syscall handling: When the user-mode code executes sc, Xenia needs to intercept and dispatch based on the r0 register value rather than letting it fall through to the default syscall path. Key insight from emoose's #1352 emoose identified that XeFu also needs:

Correct filesystem mounts (specific device paths/drive letters) XEX companion module loading (xefutitle configs) Launch data format handling These are secondary to the KeCreateUserMode/KeEnterUserMode mechanism, which is the primary boot blocker.

References Xenia #1352: emoose's original XeFu investigation Free60 wiki: HV dispatch documentation XenonLibrary: Bootloader and system structures XbSymbolDatabase: Ordinal-to-name mappings