Jarkko Sakkinen
Posts
4416Following
315Followers
470OpenPGP: 3AB05486C7752FE1
Jarkko Sakkinen
jarkko
I don’t get this Sudoku. How do I detach that display? The replacement is on left but there is like no attachment points in it.
0
0
0
Jarkko Sakkinen
jarkko
Edited 9 months ago
One of the most useful purchases this year: rocket sockets. Could not live without:
https://peperspedals.bigcartel.com/product/rocket-sockets
https://peperspedals.bigcartel.com/product/rocket-sockets
0
0
0
@ljs Well as long as VMA setup stays static it's not a big of a deal. And I get the point. It just happens SGX ranges are always managed from in VMA level as they were regular memory but obviously core mm cannot trust on that even if that was the case.
I just check periodically if we could improve something in this area that's all.
I just check periodically if we could improve something in this area that's all.
1
0
1
@ljs Yeah, you know I fully get it :-) While doing SGX I really turned all rocks in the area of merging VMA's ,PAT etc. And I had Sean, Dave and Borislav helping me out while doing that.
I don't have better vision how to make SGX merging work without user space help so not blaming you guys really either.
If I did blame the implementation, the patches would be out there for review already... And we were able to nail virtualization, NUMA and cgroups for SGX and people do use it so it's exactly just a manageable glitch. World is not perfect :-)
I don't have better vision how to make SGX merging work without user space help so not blaming you guys really either.
If I did blame the implementation, the patches would be out there for review already... And we were able to nail virtualization, NUMA and cgroups for SGX and people do use it so it's exactly just a manageable glitch. World is not perfect :-)
0
0
0
@ljs I guess it could be perhaps treated separately in "E820" (or today EFI provided) code and mark it with something else than PFNMAP. But it also depends on direct PFN manipulation in order to evict pages between regular and enclave memory (PRMRR registers preserve fixed amount of memory for SGX use).
I guess with SGX we can conclude that mm subsystem does not fully scale to that task but since it is only of its kind how it uses memory I neither expect it to 🤷 And really cannot put any blame because I have no suggestions how to exactly fix mm.
I mean if there was two subsystems then I could imagine something like VM_PFNMAP_MERGEABLE or similar VMA type: SGX memory areas as far as merging VMA's go work 1:1 as regular memory areas. It is the access to them that differs.
I guess with SGX we can conclude that mm subsystem does not fully scale to that task but since it is only of its kind how it uses memory I neither expect it to 🤷 And really cannot put any blame because I have no suggestions how to exactly fix mm.
I mean if there was two subsystems then I could imagine something like VM_PFNMAP_MERGEABLE or similar VMA type: SGX memory areas as far as merging VMA's go work 1:1 as regular memory areas. It is the access to them that differs.
1
0
0
@ljs I'd actually claim that the driver is as good as it gets in this area. It has been turned over many times by me, Sean and Dave Hansen. The way things are done is also result of 2,5 years upstreaming period so it is pretty well screened code base, and I can say by large audience of the senior maintainers. https://www.phoronix.com/news/Intel-SGX-Linux-5.11
But It's Sunday and workaround of doing your own fake mm is not as bad as it sounds. You have code that basically draws a picture of how VMA layout should look like and then does optimal set of mmaps based on that :-) Once it is in run-time nobody cares.
I'm just merely interested when something related to merges comes up "could we still improve".
I.e. I merge by:
1. Close all VMA's.
2. Map new VMA's.
The shim tracks every mmap(), mprotected() etc. syscall and updates the database accordingly.
But It's Sunday and workaround of doing your own fake mm is not as bad as it sounds. You have code that basically draws a picture of how VMA layout should look like and then does optimal set of mmaps based on that :-) Once it is in run-time nobody cares.
I'm just merely interested when something related to merges comes up "could we still improve".
I.e. I merge by:
1. Close all VMA's.
2. Map new VMA's.
The shim tracks every mmap(), mprotected() etc. syscall and updates the database accordingly.
1
0
0
@ljs Not expecting you to fix this but this like the how the problem is scoped:
1. You have special memory without backing page structures.
2. The special memory can host executables executed by the CPU.
With those constraints there's no really other way I'm aware of than PFNMAP. Or perhaps there is better way to map the memory that I'm not just aware of? Have not really looked into the issue since 2022 :-)
1. You have special memory without backing page structures.
2. The special memory can host executables executed by the CPU.
With those constraints there's no really other way I'm aware of than PFNMAP. Or perhaps there is better way to map the memory that I'm not just aware of? Have not really looked into the issue since 2022 :-)
1
0
0
@ljs If there would be something that kernel could provide some day to enable merges in such corner that'd be great but it is not a total show stopper issue. We get shit work without kernel doing merges too by redoing it in user space and it is not that hard. But anyway something to think about ;-)
1
0
0
@ljs I think I worked this around in run time by closing old mmap and creating a completely new one, i.e. I literally implemented VMA merge in user space to workaround the kernel issue in https://github.com/enarx/enarx.
I even maintained my own database of memory spans with access rights etc because kernel does not merge properly :-) You cannot implement merge without having full picture of the mapped spans and their access rights. I.e. I merge in my database and then turn that into mmap() calls.
I even maintained my own database of memory spans with access rights etc because kernel does not merge properly :-) You cannot implement merge without having full picture of the mapped spans and their access rights. I.e. I merge in my database and then turn that into mmap() calls.
1
0
0
@ljs OK then it is still existing performance issue in the SGX driver. Sean (Christopherson) removed the close callback when I was working with him on the driver to enable merges but to this day it is using PFNMAP for mapping.
So once the program is running for some time inside enclave the memory map might look like something like:
https://lore.kernel.org/linux-sgx/c148ab48-1b70-6e20-5742-b0b2dc014dc3@intel.com/
It's a corner case where the current software abstraction does not map properly the physical reality (given that for enclave memory merge would be fine even tho we need to access it with PFNMAP).
So once the program is running for some time inside enclave the memory map might look like something like:
https://lore.kernel.org/linux-sgx/c148ab48-1b70-6e20-5742-b0b2dc014dc3@intel.com/
It's a corner case where the current software abstraction does not map properly the physical reality (given that for enclave memory merge would be fine even tho we need to access it with PFNMAP).
1
0
0