Re: ARM VM with networking support?

[Ludovic Courtès]

Hey ho!

Mathieu Othacehe <address@hidden> skribis:

>> Here’s my tentative config file.
>
> I just generated a disk-image with your config file! Just like you, I did
> hit the "unsupported ioctl" issue on both master and core-updates
> branch.
>
> The reason is that the command run when producing the disk image is:
>
>           qemu-arm qemu-system-arm disk-image-builder
>             ^           ^
>             |           |-- Native qemu (so for armhf-linux architecture).
>             |
>             Run by binfmt because qemu-system-arm is a binary for armhf
>             architecture.
>
> So a syscall issued somewhere in disk-image-builder goes through the
> kernel emulated by qemu-system-arm and via qemu-arm to your host kernel.
>
> The failing syscall is number 47601 (FS_IOC32_GETVERSION), I don't know
> why it is not supported by our host kernel. However, using a
> qemu-system-arm built for arm doesn't make much sense here, because we
> add an unecessary (and failing) layer of emulation.

Woow, good catch!

> So what I would propose is to produce a disk-image using a qemu-system-*
> built for the host architecture (and not the system specified by
> --system argument). This remains true when cross-compiling a system.

Indeed, makes sense.

> The attached patch does thin in an ugly way but that solves the issue.

[…]

> +(define-record-type <native-qemu>
> +  (%native-qemu qemu system)
> +  native-qemu?
> +  (qemu native-qemu-qemu)
> +  (system native-qemu-system))
> +
> +(define-gexp-compiler (native-qemu-compiler (native-qemu <native-qemu>) 
> system target)
> +  (package->derivation (native-qemu-qemu native-qemu)
> +                       (native-qemu-system native-qemu)))
> +
>  (define* (expression->derivation-in-linux-vm name exp
>                                               #:key
>                                               (system (%current-system)) 
> target
> @@ -193,6 +204,9 @@ made available under the /xchg CIFS share."
>                          (reboot)
>                          (exit 1))))
>  
> +  (define qemu-native
> +    (%native-qemu qemu (@ (guix config) %system)))
> +
>    (let ((initrd (or initrd
>                      (base-initrd file-systems
>                                   #:on-error 'backtrace
> @@ -215,7 +229,7 @@ made available under the /xchg CIFS share."
>                             (gnu build vm))
>  
>                (let* ((native-inputs
> -                      '#+(list qemu (canonical-package coreutils)))
> +                      '#+(list qemu-native (canonical-package coreutils)))

This is a clever hack, but now the result of:

  guix system build -s armhf-linux -d …

would be dependent on the actual system type.  In other words, the
result would be different if you run it on armhf-linux, if you run it on
x86_64-linux, or if you run it on i686-linux.  Not great.

Could we use an evil trick, like the ‘binfmt-misc?’ predicate we
discussed in another thread, to somehow strip one emulation layer?  Hmm
probably not possible…

Why do we have that syscall ID mismatch anyway?…

Thoughts?

Ludo’.