That's not a good sign.
The backdoor service that the test driver uses to control the VM is not printing the sentinel value that the test driver recognises as "VM is ready". There are a number of ways for this to go wrong, none of which are easy to identify without logs.
It might not be writing system logs to a visible location.

Can you try adding this to the VM's system configuration?

boot.kernelParams = [ "console=ttyS0" "console=hvc0" ];

One of these console options might allow you to see kernel and early userspace logs.

Is anyone able to build the latest Nixpkgs natively?
My build is failing during xgcc.

checking for suffix of object files... configure: error: in `/build/build/riscv64-unknown-linux-gnu/libgcc':
configure: error: cannot compute suffix of object files: cannot compile

Oh so you are getting kernel logs even without setting console=....
One of the annoying things about systemd is that it doesn't log anything useful during boot.
Btw the console=... isn't really helping, even if it no longer prints warnings about backdoor.service, because it's still unable to send commands to the VM.

You could I guess try building the driverInteractive version of the test, then inside the interactive prompt run machine.shell_interact() to get a prompt (assuming this doesn't require the backdoor service, which it might).

It's also pretty slow.

I think that's because you're emulating RISC-V using binfmt emulation to run a riscv64-linux build of qEMU to run the test? That sounds to me like you have qEMU running under qEMU.

You could I guess try building the driverInteractive version of the test, then inside the interactive prompt run machine.shell_interact() to get a prompt (assuming this doesn't require the backdoor service, which it might).

I tried that, but I wasn't able to do anything:

• shell_interact(): same issues and doesn't give return a shell
• ssh backdoor: crashes the VM

It's also pretty slow.

I think that's because you're emulating RISC-V using binfmt emulation to run a riscv64-linux build of qEMU to run the test? That sounds to me like you have qEMU running under qEMU.

When I first read this comment, I thought so as well, but then it got me thinking: why not enable binfmt inside the test itself? So I commented out everything I previously made and did just that. Performance-wise, everything seemed ... fine, actually.

The test fails ofc, because the package wasn't installed. But then I noticed something interesting:

{
  # the package works when installed directly
  environment.systemPackages = [
    pkgs.pkgsCross.riscv64.felix86
  ];
}

Whereas:

{
  # enabling the module, I get the previous issue with `backdoor.service`
  programs.felix86.enable = true;
}

Investigating further, I tracked this back to the felix86 boot.binfmt.registrations. More importantly, the logs now actually print something useful:

machine # [    6.846377] systemd[1]: lastlog2-import.service: Failed to spawn executor: Exec format error
machine # [    6.852359] systemd[1]: lastlog2-import.service: Failed to spawn 'start' task: Exec format error
machine # [    6.857462] firewall-start[607]: /nix/store/qhsrmq9784wvy0la4nr62dhgrjwn93sv-firewall-start/bin/firewall-start: line 105: /nix/store/s657hsrj1cknm7c4cbi87f6w7f3mlv11-iptables-1.8.11/bin/iptables: cannot execute binary file: Exec format error

Then everything clicked: my system is x86_64-linux and I'm using binfmt to emulate risc64-linux, but the module also enables emulation in the other direction, after which chaos ensues.

I already suspected this would happen, but I'm glad to actually confirm it. In a way, this kinda means the module's binfmt registration is working and I can just disable it for now in the test.

You could I guess try building the driverInteractive version of the test, then inside the interactive prompt run machine.shell_interact() to get a prompt (assuming this doesn't require the backdoor service, which it might).

I tried that, but I wasn't able to do anything:

• shell_interact(): same issues and doesn't return a shell
• ssh backdoor: crashes the VM

It's also pretty slow.

I think that's because you're emulating RISC-V using binfmt emulation to run a riscv64-linux build of qEMU to run the test? That sounds to me like you have qEMU running under qEMU.

When I first read this comment, I thought so as well, but then it got me thinking: why not enable binfmt inside the test itself? So I commented out everything I previously made and did just that. Performance-wise, everything seemed ... fine, actually.

The test fails ofc, because the package wasn't installed. But then I noticed something interesting:

{
  # the package works when installed directly
  environment.systemPackages = [
    pkgs.pkgsCross.riscv64.felix86
  ];
}

Whereas:

{
  # enabling the module, I get the previous issue with `backdoor.service`
  programs.felix86.enable = true;
}

Investigating further, I tracked this back to the felix86 boot.binfmt.registrations. More importantly, the logs now actually print something useful:

machine # [    6.846377] systemd[1]: lastlog2-import.service: Failed to spawn executor: Exec format error
machine # [    6.852359] systemd[1]: lastlog2-import.service: Failed to spawn 'start' task: Exec format error
machine # [    6.857462] firewall-start[607]: /nix/store/qhsrmq9784wvy0la4nr62dhgrjwn93sv-firewall-start/bin/firewall-start: line 105: /nix/store/s657hsrj1cknm7c4cbi87f6w7f3mlv11-iptables-1.8.11/bin/iptables: cannot execute binary file: Exec format error

Then everything clicked: my system is x86_64-linux and I'm using binfmt to emulate risc64-linux, but the module also enables emulation in the other direction, after which chaos ensues.

I already suspected this would happen, but I'm glad to actually confirm it. In a way, this kinda means the module's binfmt registration is working and I can just disable it for now in the test.