Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for building under x86_64 User-Mode-Linux (UML) #766

Merged
merged 3 commits into from May 10, 2022

Conversation

sulix
Copy link

@sulix sulix commented May 10, 2022

User-Mode-Linux is a Linux architecture (ARCH=um) which builds the kernel as a normal user-mode binary. It's used, amonst other things, as the default architecture for KUnit tests, and acts as a very fast, lightweight platform for running and testing kernel code.

Since Rust-for-Linux already supports x86-64, it's relatively simple to add support for x86-64 UML. Most of the changes are simply excluding code whose dependencies are not met (CONFIG_IOMEM and CONFIG_IRQ_DOMAIN are not set on default UML configs). In addition, CONFIG_HAVE_RUST is set for X86_64 UML, and generate_rust_target is modified to check for CONFIG_X86_64 instead of CONFIG_X86.

With these changes, a UML kernel with CONFIG_RUST=y builds and runs successfully, and the KUnit tooling can run Rust-based tests as follows:

./tools/testing/kunit/kunit.py run --kconfig_add CONFIG_RUST=y --make_options LLVM=1

Signed-off-by: David Gow davidgow@google.com

Copy link
Member

@bjorn3 bjorn3 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we can also have a CI job for UML?

@ojeda
Copy link
Member

ojeda commented May 10, 2022

LGTM too, with the amba bit fixed.

Maybe we can also have a CI job for UML?

Indeed. I can do it in another PR.

sulix added 3 commits May 10, 2022 17:46
The kernel iomem functions are not available on all architectures, in
all configurations, so hide the rust bindings behind CONFIG_HAS_IOMEM.

This is required for rust to work under UML.

Signed-off-by: David Gow <davidgow@google.com>
IRQ domains are not supported under all architectures, so hide the
Domain struct (and its implementation) behind CONFIG_IRQ_DOMAIN.

This is required for CONFIG_RUST to build and run under UML.

Signed-off-by: David Gow <davidgow@google.com>
CONFIG_RUST currently supports x86_64, but does not support it under
UML. Adding support is trivial:
- Add CONFIG_HAVE_RUST to UML if X86_64 is set.
- Have generate_rust_target check for CONFIG_X86_64, which is present
  under UML, rather than CONFIG_X86, which isn't.

Signed-off-by: David Gow <davidgow@google.com>
@sulix
Copy link
Author

sulix commented May 10, 2022

Fixed the amba stuff: just needed to properly depend on HAS_IOMEM, not IOMEM.

Tested KUnit against arm64, and against UML+IOMEM, and it worked fine:

./tools/testing/kunit/kunit.py run --kconfig_add CONFIG_RUST=y --make_options LLVM=1 --arch arm64
./tools/testing/kunit/kunit.py run --kconfig_add CONFIG_RUST=y --make_options LLVM=1 --kconfig_add CONFIG_PCI=y --kconfig_add CONFIG_VIRTIO_UML=y --kconfig_add CONFIG_UML_PCI_OVER_VIRTIO=y

It'd be great to have a CI job for UML — it'd probably need to be quite different from the existing qemu-based jobs, though (but you could possibly reuse some x86 userspace / initrd stuff). The other option (which I could try hacking together) is to have separate KUnit CI jobs, which could piggy-back on the kunit_tool configs (and potentially run non-rust-specific tests as well, if that were useful).

@ojeda ojeda merged commit fbf6cf4 into Rust-for-Linux:rust May 10, 2022
@ojeda
Copy link
Member

ojeda commented May 10, 2022

Thanks a lot David!

it'd probably need to be quite different from the existing qemu-based jobs

Yeah, it would probably have to be different.

to have separate KUnit CI jobs

Do you mean having CI jobs that directly run kunit.py and reuse its configs?

@sulix
Copy link
Author

sulix commented May 10, 2022

Do you mean having CI jobs that directly run kunit.py and reuse its configs?
Yeah: it might prove easier than having a more complicated setup with its own initrd + module loading + KTAP parsing. It wouldn't be able to replace the existing CI for anything but running KUnit tests, but might prove easier to setup and maintain for the KUnit case specifically.

@sulix
Copy link
Author

sulix commented May 13, 2022

FYI: I looked briefly into CI with kunit_tool, and it looks like UML doesn't run nicely on GitHub actions, at least out-of-the-box. UML requires /dev/shm to not be marked noexec:

Checking PROT_EXEC mmap in /dev/shm...Operation not permitted
/dev/shm must be not mounted noexec

Other architectures (at least x86_64 and arm64), under qemu, can be made to work, though.

@sulix sulix mentioned this pull request Dec 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants