[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ARM VM with networking support?

From: Ludovic Courtès
Subject: Re: ARM VM with networking support?
Date: Mon, 09 Dec 2019 18:35:59 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

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?…



reply via email to

[Prev in Thread] Current Thread [Next in Thread]