Hello,
On Wed, 15 Jan 2025 03:53:36 +0900, Benjamin Berg wrote: > > On Tue, 2025-01-14 at 20:30 +0900, Hajime Tazaki wrote: > > This patchset is another spin of nommu mode addition to UML. It doesn't > > change a lot since the last version (v5), but contain clean ups. It would > > be nice to hear about your opinions on that. > > > > There are still several limitations/issues which we already found; > > here is the list of those issues. > > > > - memory mapped by loadable modules are not distinguished from > > userspace memory. > > Maybe I am missing it, but I do not yet see proper FP register > handling. This will be needed for task/thread switches and also signal > emission/sigreturn. I am attaching the test program that I used to > verify the correct behaviour when dealing with the recent changes to FP > register handling in UML. thanks for the test program. I didn't address your comment on FP register handling as I couldn't see any reproducer that causes the issue you raised (and maybe didn't understand well the problem) so, the attached program helps a lot. Though nommu code only works with musl-libc, which I cannot use that as-is, now I see what you meant with the first function, test_fp(). (none):/# /root/test-signal-restore pre-signal: 0.5 post-signal: 0.5 floating point register was not manipulated Tests on task switch (test_fp_ptrace) might need more work for me as nommu only works with vfork(2) and vfork without exec(2) may not test well on the implementation. and also I'm wishing to have this kind of useful tests as a reusable way; as now I'm going to add a new configuration for UML, you're also going for another SECCOMP mode over MMU, we may have at least 3 running modes for UML, which I think we should share the test framework that we should pass. Not sure how it should be but using Kunit is the first thing in my mind. I'd like to work on such things once I've done this initial part for nommu. thanks, will get back here once I could see the right way to fix it. -- Hajime
