Jarkko Sakkinen
Posts
4804Following
319Followers
489OpenPGP: 3AB05486C7752FE1
@ljs That said, obviously core mm would better suit to any "random intel feature" as long as it has a user base :-) it is as random or not random feature as e.g. oracle database. Or any other random user for that matter. I think all three are equivalent.
I get your point tho, mm cannot be tuned to SGX at expense of Oracle DB, some random user or any other work load. Still I thought that it is good to a biennial query at LKML if there is something new in mm that could help to improve this part of the driver or something not too intrusive that could be changed in mm :-) I think this somewhat fair standing point.
I get your point tho, mm cannot be tuned to SGX at expense of Oracle DB, some random user or any other work load. Still I thought that it is good to a biennial query at LKML if there is something new in mm that could help to improve this part of the driver or something not too intrusive that could be changed in mm :-) I think this somewhat fair standing point.
1
0
0
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 1 year 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