From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= Subject: Re: ARM VM with networking support? Date: Mon, 09 Dec 2019 18:35:59 +0100 Message-ID: <87a781bdvk.fsf@gnu.org> References: <87r22p3trp.fsf@gnu.org> <87ftj4vqcy.fsf@gmail.com> <87mud59d47.fsf@gnu.org> <877e46b9ld.fsf@gmail.com> <878soeo2c5.fsf@gnu.org> <878snwvwiz.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:51547) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ieMx1-0004yY-69 for guix-devel@gnu.org; Mon, 09 Dec 2019 12:36:04 -0500 In-Reply-To: <878snwvwiz.fsf@gmail.com> (Mathieu Othacehe's message of "Sun, 01 Dec 2019 17:30:12 +0100") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Mathieu Othacehe Cc: guix-devel Hey ho! Mathieu Othacehe skribis: >> Here=E2=80=99s 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. [=E2=80=A6] > +(define-record-type > + (%native-qemu qemu system) > + native-qemu? > + (qemu native-qemu-qemu) > + (system native-qemu-system)) > + > +(define-gexp-compiler (native-qemu-compiler (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)))) >=20=20 > + (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)) >=20=20 > (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 =E2=80=A6 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 =E2=80=98binfmt-misc?=E2=80=99 predica= te we discussed in another thread, to somehow strip one emulation layer? Hmm probably not possible=E2=80=A6 Why do we have that syscall ID mismatch anyway?=E2=80=A6 Thoughts? Ludo=E2=80=99.