Yuzu: Missing SVCs 'MapPhysicalMemory' and 'UnmapPhysicalMemory'

Created on 28 Jun 2019 · 1Comment · Source: yuzu-emu/yuzu

kernel-issue unimplemented

Source

GDhex12

Most helpful comment

The actual implementation of this svc is not exactly the issue of it not working.

With MapPhysicalMemory, we also need to implement PersonalMnHeapSize which is at the time of writing(IsVirtualAddressMemoryEnabled). This will need to be renamed. The info is pulled from the npdm, under the field System resource size.
When implementing this cmd, games which were originally stubbed to 0, will now stop working. Notable examples of games which could be affected are games like Super Mario Odyssey. MapPhysicalMemory should stay in canary for a while whilst we test all previous 3.0.0+ games we have known to work before to make sure we don't have any regressions.
TotalPhysicalMemoryAvailableWithoutMmHeap and TotalPhysicalMemoryUsedWithoutMmHeap will also need to be updated as we require to store the personal_mn_heap size.
Games tend to start mapping at MapRegionBaseAddr. Currently, I believe this is the main issue to why MapPhysicalMemory games are throwing as what we call internally "Ascii Addr Reads". This will also need to be looked into and checked.
Our scheduler could also be a cause for some issues as the addresses which are being mapped aren't consistent as previously discussed in development. However, I believe the issue might still stem from our svcGetInfo returns for a few values as noted above.
Our total memory usage also is checked a few times for games and games might map too much or too little depending on what we return, we will need to correct this instead of returning a fixed value.

ogniK5377 on 28 Jun 2019

👍6

The actual implementation of this svc is not exactly the issue of it not working.

With MapPhysicalMemory, we also need to implement PersonalMnHeapSize which is at the time of writing(IsVirtualAddressMemoryEnabled). This will need to be renamed. The info is pulled from the npdm, under the field System resource size.
When implementing this cmd, games which were originally stubbed to 0, will now stop working. Notable examples of games which could be affected are games like Super Mario Odyssey. MapPhysicalMemory should stay in canary for a while whilst we test all previous 3.0.0+ games we have known to work before to make sure we don't have any regressions.
TotalPhysicalMemoryAvailableWithoutMmHeap and TotalPhysicalMemoryUsedWithoutMmHeap will also need to be updated as we require to store the personal_mn_heap size.
Games tend to start mapping at MapRegionBaseAddr. Currently, I believe this is the main issue to why MapPhysicalMemory games are throwing as what we call internally "Ascii Addr Reads". This will also need to be looked into and checked.
Our scheduler could also be a cause for some issues as the addresses which are being mapped aren't consistent as previously discussed in development. However, I believe the issue might still stem from our svcGetInfo returns for a few values as noted above.
Our total memory usage also is checked a few times for games and games might map too much or too little depending on what we return, we will need to correct this instead of returning a fixed value.