-
Notifications
You must be signed in to change notification settings - Fork 47
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
Introduce bsd-user-qemu and run-{shell,user}-riscv64-purecap targets. #264
base: main
Are you sure you want to change the base?
Conversation
README.md
Outdated
@@ -151,6 +151,8 @@ For the `cheribsd`, `disk-image` and `run` targets the hybrid vs purecap distinc | |||
- `freebsd-<architecture>` builds and installs [freebsd/freebsd](https://github.com/freebsd/freebsd). | |||
- `disk-image-freebsd-<architecture>` creates a FreeBSD disk-image. | |||
- `run-freebsd-<architecture>` launches QEMU with the FreeBSD disk image. | |||
- `run-shell-<architecture>` launches a shell with the QEMU user mode in a CheriBSD sysroot. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As mentioned on Slack in the past, I think run-user-shell does a better job of namespacing it as a qemu-user thing, since arguably run does get you a shell (once you log in)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done: 10d522b .
Besides run-user-shell
, we also have run-user
to execute an arbitrary command. What do you think about that target name? I wonder if we should remove run-user-shell
and only have run-user
which by default executes /bin/sh
, unless --run-user/command
is specified.
repository = GitRepository("https://github.com/CTSRD-CHERI/qemu.git", | ||
default_branch="qemu-cheri-bsd-user", | ||
force_branch=True) | ||
native_install_dir = DefaultInstallDir.BSD_USER_SDK |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You shouldn't need a whole new enum for this, just copy upstream-qemu's approach?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BuildUpstreamQEMU's way is quite complex. Wouldn't be it easier to maintain a separate enum for this?
Instead, we could add a comment the enum should be removed once the BSD user mode is merged to qemu-cheri
(which can take quite a while).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this install anything other than the qemu-user binaries? If not we could reuse the same installation directory?
hide_options_from_help = True | ||
|
||
@classmethod | ||
def qemu_cheri_binary(cls, caller: SimpleProject, xtarget: CrossCompileTarget = None, absolute_path=True): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is going to need to be a separate method as otherwise we won't be able to have a single target that builds both
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if we're going to be able to build both a system mode and a user mode with a single configure
. The BSD user mode needs to be static for Poudriere (it copies a single binary to a jail).
Would we want to build system modes with --static
? If not, would we want to add --static
per mode or target?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm aware the branch must be rebased before it can be merged to qemu-cheri. I'll do it once the current changes are accepted as I'd have to force push the rebase and hence ruin this review.
README.md
Outdated
@@ -151,6 +151,8 @@ For the `cheribsd`, `disk-image` and `run` targets the hybrid vs purecap distinc | |||
- `freebsd-<architecture>` builds and installs [freebsd/freebsd](https://github.com/freebsd/freebsd). | |||
- `disk-image-freebsd-<architecture>` creates a FreeBSD disk-image. | |||
- `run-freebsd-<architecture>` launches QEMU with the FreeBSD disk image. | |||
- `run-shell-<architecture>` launches a shell with the QEMU user mode in a CheriBSD sysroot. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done: 10d522b .
Besides run-user-shell
, we also have run-user
to execute an arbitrary command. What do you think about that target name? I wonder if we should remove run-user-shell
and only have run-user
which by default executes /bin/sh
, unless --run-user/command
is specified.
repository = GitRepository("https://github.com/CTSRD-CHERI/qemu.git", | ||
default_branch="qemu-cheri-bsd-user", | ||
force_branch=True) | ||
native_install_dir = DefaultInstallDir.BSD_USER_SDK |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BuildUpstreamQEMU's way is quite complex. Wouldn't be it easier to maintain a separate enum for this?
Instead, we could add a comment the enum should be removed once the BSD user mode is merged to qemu-cheri
(which can take quite a while).
hide_options_from_help = True | ||
|
||
@classmethod | ||
def qemu_cheri_binary(cls, caller: SimpleProject, xtarget: CrossCompileTarget = None, absolute_path=True): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if we're going to be able to build both a system mode and a user mode with a single configure
. The BSD user mode needs to be static for Poudriere (it copies a single binary to a jail).
Would we want to build system modes with --static
? If not, would we want to add --static
per mode or target?
87d2f95
to
b557b57
Compare
The target builds the QEMU CheriABI user mode targets from the qemu-cheri-bsd-user branch in CTSRD-CHERI/QEMU and installs it in a separate SDK directory. This target doesn't use SMB and hence doesn't require SMB support.
A run-<architecture>-shell target launches a shell with the QEMU user mode in a CheriBSD sysroot. * Since the run-<architecture>-shell targets run a QEMU user mode binary, different QEMU flags are required, as opposed to the run-<architecture> targets. Modify the QemuOptions class to provide separate methods to construct argument lists for a system or a user mode binary; * Instead of using the LaunchQEMUBase class, introduce the LaunchBsdUserQEMUBase class that runs a user mode binary; * Instead of using the LaunchCheriBSD class, introduce the LaunchCheriBSDShell class that creates run-<architecture> targets with the "-shell" suffix; * Describe the run-<architecture>-shell targets in README.
A run-<architecture>-exec target executes a command passed with an option --exec/command. Additionally, one of the following options can be used: * --exec/chroot tells cheribuild to change a root directory to a sysroot before executing the command; * --exec/jail tells cheribuild to enter a jail with a sysroot before executing the command. The flags --exec/{chroot,jail} require cheribuild to be run as root. At the moment, --allow-running-as-root can be used to run cheribuild with sudo but this option shouldn't be used without the flags --exec/{chroot,jail}. Additionally, --skip-update is recommended when carefully using --allow-running-as-root.
* Rename the targets to run-{shell,user}-<architecture> for consistency with other targets; * Describe the run-user-<architecture> in README. Pointed out by: @jrtc27
The jail-extra-args options allow to pass extra jail parameters to jail(8), e.g. to mount devfs(8).
BuildSystemQEMU is a parent class for all classes for system-mode targets. Thanks to this class, two issues are resolved: * BuildQEMUBase was adding --disable-bsd-user to configure flags also for user-mode targets; * BuildQEMU was adding morello-softmmu to the default targets if a QEMU branch includes Morello support. BuildBsdUserQEMU can manage its own list of targets and not use configuration flags only related to the system mode now.
Extend the bsd-user-qemu target to build BSD user modes for all targets we're interested in: aarch64, riscv64, riscv64c. Morello will be added to the above list once it's working.
* Rename the target to indiciate with a 'user' subword it's related to the BSD user mode (built with the bsd-user-qemu cheribuild target); * Update class names to match target names better. Pointed out by: jrtc27
Allow to specify an ELF interpreter path for the run-user and run-user-shell targets. The interpreter path can be different than an encoded one in an ELF binary in multi-ABI environments, e.g. a Poudriere jail.
Map the guest address space not to overlap with a host address space.
Pointed out by: jrtc27
AbstractLaunchFreeBSDProgram was the only child class of the LaunchBsdUserQEMUBase class. Instead of introducing another abstraction, move AbstractLaunchFreeBSDProgram login into LaunchBsdUserQEMUBase. Pointed out by: jrtc27
Set the default value of a command to execute with the user mode to /bin/sh within a rootfs.
The command should be computed depending on a target context. In case of run-user-shell, we'd like to append a rootfs path if the shell is not executed with chroot nor jail. Pointed out by: jrtc27
Reduce a number of additional abstractions required for the user mode support that should be eventually removed once the user mode is merged into the qemu-cheri branch. This change uses a hack to always pass --disabled-bsd-user to configure and later pass --enable-bsd-user to overwrite it. Pointed out by: jrtc27
b557b57
to
1590f85
Compare
The targets use QEMU code from the qemu-cheri-bsd-user branch.
Examples: