Exécution native de l'invité
Sous Windows x86-64, le code machine de l'invité s'exécute directement. Un worker hôte porte chaque pthread invité, et la base FS est restaurée après chaque appel bloquant, parce que Windows ne la conserve pas.
Notes du dépôt jusqu’au 10 octobre 2026
Un worker par thread invité
Le répartiteur démarre un worker hôte pour chaque pthread invité, installe le TLS de ce thread, et entre dans l'invité à l'adresse demandée avec les registres d'arguments System V. Join, detach, yield, sleep, les rappels imbriqués et scePthreadExit reviennent tous par ce chemin. Le thread HLE n'est achevé qu'une fois que l'exécution invitée a quitté ce contexte.
Le pont vérifie que le point d'entrée est exécutable et que la pile et le TLS sont mappés. Il sauvegarde les registres non volatils de Windows, MXCSR et le mot de contrôle x87, bascule vers la pile invitée, installe la base FS invitée, et appelle l'entrée. Un scePthreadExit synchrone sort par une échappée native qui abandonne les cadres invités et restaure le FS hôte avant que le répartiteur ne voie l'interruption.
Windows abandonne la base FS
Installer FS une seule fois ne suffit pas. Windows ne préserve pas une base FS écrite par l'utilisateur à travers un changement de contexte. Après un sommeil, rdfsbase relit zéro. Le code invité garde son stockage local de thread dans FS, selon la convention System V, de sorte que l'accès suivant relatif à FS provoquerait une faute près de l'adresse zéro. Rien n'est faux dans l'invité. L'hôte a abandonné un registre sur lequel l'invité est en droit de compter.
Le répartiteur restaure donc FS après les appels bloquants. Les attentes utilisent un futex sensible à la séquence, pour qu'un réveil arrivé entre un déverrouillage et le stationnement soit consommé une seule fois, et pour qu'un broadcast reste visible de chaque attendeur qui a observé la séquence plus ancienne. Si l'historique fixe des réveils vient à saturer, le répartiteur réveille en excès et laisse HLE revérifier l'objet. Les sommeils temporisés utilisent un délai privé non alertable, pour qu'un réveil sans rapport ne transforme pas un worker audio en boucle active.
Fautes et autres systèmes d'exploitation
Un thread invité en faute est contenu. Les diagnostics attribuent l'adresse à un module et à un symbole lorsqu'ils le peuvent, et le processus n'a pas à mourir sur une exception hôte non gérée. PS5_CPU_WAIT_DIAGNOSTICS=1 réactive la trace d'attente verbeuse. Elle est éteinte pendant le jeu normal, parce que plusieurs workers stationnés qui impriment en même temps peuvent eux-mêmes bloquer une image.
L'exécution native exige Windows x86-64 et la fonction processeur RDWRFSGSBASE. Les builds Linux et macOS compilent encore le décodeur, le chargeur et HLE, et ils signalent le pont natif comme non pris en charge. Les binaires invités sont du code machine x86-64. Ils ne sont pas interprétés.
Ce qui est en place
- Exécution native x86-64 de l'invité sous Windows, un worker hôte par pthread invité.
- Appels System V, piles invitées, et FS restauré après les appels bloquants.
- Attentes sensibles à la séquence, fautes contenues, et sortie de pthread qui restaure l'hôte.
- Inspection, décodage et HLE sous Linux et macOS, sans exécution native.
Ce qui manque encore
- Il n'y a pas d'interpréteur. Les hôtes autres que Windows x86-64 n'exécutent pas l'invité.
- Un CPU qui ne peut pas écrire les bases FS et GS ne peut pas entrer dans le pont natif.
- Les diagnostics d'attente verbeux sont éteints par défaut, parce que leur impression bloque le jeu.
Mécanismes liés
Ce que ces pages décrivent