ssrg-vt / popcorn-kernel

Popcorn Linux kernel for distributed thread execution
Other
155 stars 23 forks source link

clean up implementation of `pte_pfn` and `pte_modify` #55

Open bxatnarf opened 5 years ago

bxatnarf commented 5 years ago

In order to get popcorn working with the latest linux, pte_pfn and pte_modify were hackishly changed to work around the following commit: https://github.com/ssrg-vt/popcorn-kernel/commit/6b28baca9b1f0d4a42b865da7a05b1c81424bd5c

This workaround -- https://github.com/ssrg-vt/popcorn-kernel/commit/5520dd4ebffcd439f2322437ca4e40323d67f29e -- is ugly. We need to clean this up and remove the #ifdef CONFIG_POPCORN statements.

cesarjp commented 4 years ago

Is there a way to escalate this issue for the merge branch? On my system, just loading the msg_socket kernel module and running something innocuous like 'ls' or 'dmesg' is enough to cause page fault related oops. When I reverted L1TF patches in git revisions 42e4089c7 and 6b28baca9b1, I was able to successfully able to load the msg_socket module repeatedly and run NPB EP in a multi-ISA Arm64-x86 environment with the merge branch.

It looks like the L1TF patches invert the PTE values on x86 to workaround some hardware defect. As of Linux 5.2, Arm64 does not require such a workaround, so that explains why I could load the msg_socket module on that system without error.

Going forward, I'd recommend someone to either add a boot time argument to disable the PTE inversion, or teach the page server how to accommodate it, probably using target hooks to invert those entries.

For reference, I attached two patches. 0001- contains the changes necessary to enable the arm64 target in the merge branch. 0002- reverts the aforementioned changes in 42e4089c7 and 6b28baca9b1. Note that you might need to update your musl C library to get multi-ISA transitions working with Arm64. Also, note that 0002- is incomplete, as it does not consider the corresponding changes to the swap file. I haven't investigated how Popcorn Linux interacts with the swap file yet to determine if those changes are relevant.

This issue is also related to the closed issues #52, #53, and #73.

0001-enable-Arm64.patch.gz 0002-revert-42e4089c7-and-6b28baca9b1.patch.gz

bxatnarf commented 4 years ago

@cesarjp, you should use the master branch if you want to work with arm/heterogeneous migration. We do not intend on supporting arm in the merge branch (at least for now) and in fact have completely removed arm support in the latest patches to the merge branch.

bxatnarf commented 4 years ago

@cesarjp, you should use the master branch if you want to work with arm/heterogeneous migration. We do not intend on supporting arm in the merge branch (at least for now) and in fact have completely removed arm support in the latest patch to the merge branch.

cesarjp commented 4 years ago

ACK. But it should be noted that my Arm64 patch is independent from the workaround for the problem in pte_pfn and pte_modify. I only included it because that's how I tested it locally. As I mentioned before, just loading the msg_socket module and typing ls or dmesg was enough to trigger memory related oops on my system.

Anyway, I'm content with my kernel setup for now.

bxatnarf commented 4 years ago

Would you mind posting the log messages and test binary that triggers the errors (if you have one) in a separate issue? I don't want your issues to get lost since the issues reported here is merely a style issue.

ACK. But it should be noted that my Arm64 patch is independent from the workaround for the problem in pte_pfn and pte_modify. I only included it because that's how I tested it locally. As I mentioned before, just loading the msg_socket module and typing ls or dmesg was enough to trigger memory related oops on my system.

Anyway, I'm content with my kernel setup for now.

cesarjp commented 4 years ago

Sorry, I don't have a proper setup for homogeneous migration at present.