Fixes two issues that will never happen:
1. There are cases when VFP_REG_ZERO will be non-zero, but these will
never be encoutered in well behaved guest code (i.e. writing to D16).
2. If CONFIG_VFPv3 is defined, accessing VFP_REG_ZERO would be out of
bounds.
Kernel/Threads: Add a new thread status that will allow using a Kernel::Event to put a guest thread to sleep inside an HLE handler until said event is signaled
This could happen if the guest application performs a request with static buffer id X, and the service module responds with another static buffer with the same id X.
This was incorrect behavior that somehow found its way to 3dbrew. The correct behavior is to sleep until the port becomes available again and then return a session to it.
This is currently unimplemented due to the inability to put a guest thread to sleep during HLE requests.
The correct behavior was reverse engineered by TuxSH a while ago but we never corrected the code in citra.
Kernel/Arbiters: When doing ArbitrateAddress(Signal), always pick the highest priority thread, using the first one that was put to sleep if more than one thread with the same highest priority exists.
The real kernel requires services to set up their static buffer targets ahead of time. This implementation does not require that and will simply create the storage for the buffers as they are processed in the incoming IPC request.
Static buffers are kept in an unordered_map keyed by their buffer id, and are written into the already-setup area of the request thread when responding an IPC request.
This fixes a regression (crash) introduced in #2992.
This PR introduces more warnings due to the [[deprecated]] attribute being added to void PushStaticBuffer(VAddr buffer_vaddr, size_t size, u8 buffer_id); and VAddr PopStaticBuffer(size_t* data_size);
The error code 0xC920181A will be returned by svcReplyAndReceive when the wakeup callback runs.
This lets LLE services be properly notified of clients closing the connection so they can end their handler threads instead of letting them linger indefinitely, taking up connection slots in their parent port.
This descriptor requires the target process to set up a "receive buffer" beforehand, where the input data will be written to when the descriptor is processed.
The real kernel's ReplyAndReceive will retry the call until one of the objects can be acquired without causing a translation error, this is not currently implemented and the code will instead assert that the translation was a success.
