Allow plugins with heaps of 5 MiB or less to use PRIVATE memory instead of SHARED #2079
Conversation
|
Hello, this is not backwards compatible and will break every single software that uses map process memory ex (many plugins and other apps). A backwards compatible solution should be implemented. About the memory state, a lot of tests will be needed to ensure it doesn't break anything. |
|
Ah, thank you for letting me know other apps use that svc. I was hoping I wouldn't have to implement a new svc since I thought that would be messier, but perhaps that would be more worth doing. I knew that the MK7 Deluxe plugin still worked (which is a 10 MiB plugin, so that was reassuring) but I'll be testing a lot with this to make sure it doesn't break anything else. If you could, can you give me an example of an application that uses |
|
Well I made a new svc for it instead, which will solve the applications from breaking in the way you described. In terms of testing to make sure changing MemState doesn't break anything, fortunately me and some other people will be testing this a whole lot. So if any issues come up they will most certainly be fixed, or at least outlined here if fixing is not possible. |
|
@TuxSH what do you think of this? Backwards compatibility should be kept, but at the same time having a new SVC seems overkill. I think the same SVC could be kept, but add a magic number to a register to signal the kernel it's the new version. |
|
I agree, if a new SVC can be avoided it probably should be. I can attempt the magic number idea. |
|
Also, do not add a boolean parameter, instead create a flags parameter and make an enum. That way it's more future proof. |
Yes, though only until I rewrite k11 (in a year or possibly more) Ideally a backwards compatible options should be done, but it needs to not be (more) difficult to refactor when I eventually need to, either. Agree it would be nice to avoid using up extra svc numbers |
|
|
||
| Result res = 0; | ||
|
|
||
| res = svcUnmapProcessMemoryEx(target, 0x07000000, header->exeSize); | ||
| res = svcMapProcessMemoryEx(target, header->heapVA, CUR_PROCESS_HANDLE, (u32) memblock->memblock + header->exeSize, header->heapSize, true); |
There was a problem hiding this comment.
What's the logic behind this change?
There was a problem hiding this comment.
Probably doesn't matter now, but two lines under you can see both original Unmaps were kept. The idea was to make sure it was still mapped the normal way with 0x5806 just in case Unmap would somehow break on PRIVATE memory.
Admittedly, perhaps a call to svcControlProcessMemory would have been more prudent, but I'm not sure.
|
Superseeded by #2086 with the remaining changes. |
|
@LittlestCube To add context, I am the one who was pushing to make a release. You will be credited regardless. |
Temporary fix to plugins giving them a
PRIVATEheap for use withsvcCreateMemoryBlockand other calls that expectMemStateto bePRIVATE. This opens the door for many plugin projects that are blocked since they cannot use these svc calls.This fixes #1777 and #2078.
To be clear, I do not necessarily expect this to be merged anytime soon (if at all) but I thought it would be nice to show that the fix really does not require that many changes, even if it's a few more changes than ideal.