Mémoire directe, mémoire flexible et pools
Les adresses invitées sont de vraies adresses hôtes. La mémoire directe est un pool physique partagé creux mappé dans cet espace, et MemoryPool ajoute la réserve, le commit et les opérations par lot au-dessus du même support.
Notes du dépôt jusqu’au 10 octobre 2026
L'adresse invitée est l'adresse hôte
Le code x86-64 invité s'exécute nativement et contient des adresses absolues, donc PS5PCEM ne peut pas reloger le processus dans une allocation arbitraire. Le module mémoire réserve la disposition de la console avant le chargement de tout module. La fenêtre gérée par le système commence à 0x40000 et va jusqu'à un peu moins de 32 GiB. Les fenêtres réservées au système et aux périphériques suivent. La fenêtre utilisateur sous Windows et Linux va de 0x10_0000_0000 à 0xFC_0000_0000, soit 944 GiB d'espace d'adressage. macOS commence cette fenêtre plus haut et obtient 560 GiB.
Ces plages sont des réservations, pas de la RAM déjà sous commit. Les pages font l'objet d'un commit par unités de 16 KiB lorsqu'un mappage est créé, et le démappage en fait le decommit tandis que la réservation extérieure demeure. Une autre allocation hôte ne peut pas voler l'adresse invitée entre deux usages.
Mémoire directe et flexible
La mémoire directe est le nom, côté invité, de la mémoire vidéo physique. Le titre réserve une plage physique, puis la mappe. Les deux étapes sont séparées. Le mappage vérifie que toute la plage physique a été réservée, traduit les protections CPU et GPU, et soit fait le commit à l'adresse fixe exacte, soit cherche un trou aligné. Le même décalage physique peut être mappé à plusieurs adresses virtuelles, et ces alias sont cohérents parce qu'ils partagent un seul objet de support creux.
Un mappage fixe dans une plage que le titre a déjà réservée fait le commit à l'intérieur de la réservation. Relâcher d'abord la réservation abandonnerait la revendication du titre sur les morceaux qu'il n'a pas encore mappés. La mémoire physique est relâchée dans la forme que le titre demande, qui peut être un trou au milieu ou une étendue de plusieurs réservations. La mémoire flexible utilise la même table d'espace d'adressage, avec un budget par défaut de plateforme de 4 GiB, et cherche dans la fenêtre gérée par le système à partir de 0x02_0000_0000 avant de se replier sur la fenêtre utilisateur.
MemoryPool et le commit Windows
Les six exports MemoryPool de libkernel réservent une arène virtuelle, étendent la capacité physique, font le commit et le decommit du support partagé, exécutent des lots ordonnés et rapportent des statistiques de blocs. Les blocs donnés ne peuvent pas être mappés comme mémoire directe ordinaire, ni relâchés tant qu'ils restent sous commit. Le commit, le decommit, la protection et les changements de type par lot fonctionnent. Le MOVE par lot reste non pris en charge et renvoie une erreur plutôt que de prétendre que les blocs ont bougé.
Sous Windows, les vues de mémoire directe alignées partagent des vues de section de 64 KiB. Les envois temporaires, les relectures et les pages invitées de 16 KiB ne deviennent donc pas, chacun, leur propre charge de commit sans cesse croissante. Les requêtes sur une réservation utilisent l'enregistrement de requête virtuelle de 72 octets de l'invité et rapportent des plages semi-ouvertes avec les bits de protection d'origine.
Ce qui est en place
- Fenêtres d'adresses invitées fixes, sous commit par pages de 16 KiB et relâchées sans abandonner la réservation.
- Alias cohérents d'un même décalage physique de mémoire directe.
- Mémoire flexible avec le budget par défaut de 4 GiB, et démappages fixes, sans écrasement et partiels.
- Réserve, extension, commit, decommit, statistiques et lots ordonnés de MemoryPool, sauf MOVE.
Ce qui manque encore
- Le MOVE par lot de MemoryPool est explicitement non pris en charge.
- Le relâchement d'une plage que le titre ne possède pas reste une erreur.
- Les réservations sont virtuelles. Seules les pages que le titre mappe consomment du commit hôte.
Mécanismes liés
Ce que ces pages décrivent