From nobody Fri May 19 07:45:17 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QMzQy4xbRz4BcYQ for ; Fri, 19 May 2023 07:45:30 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QMzQy2lSxz46xT for ; Fri, 19 May 2023 07:45:30 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-yb1-xb2d.google.com with SMTP id 3f1490d57ef6-ba818eb96dcso2595757276.0 for ; Fri, 19 May 2023 00:45:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684482329; x=1687074329; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=CtjLvqjxXOQAoavWxDZi0rLcHfk15L5roUhC1IcvmqM=; b=rL0sV/fEDm/QqBflpFNiRQsCw8m4Vsw6jccmOGDdvmJlqzpjGKm2ygKeKDZfUoJpab 3Mx+Xl3GgVXTvVY2In0fAYCGAozArEs9WwYWcSeIgmThsTYJlTWockQ4k3bDy4annqq4 0/9j7ICXmCvyLqogHE71aiiMLcI0Pp1sYqfaT55VK5Fzz1Wum1qcwNNYxtsI0s9iewR1 7UN28kdRoFuiHYl83Ym1kGbOD9DNbP7sesJP5kEWSI0lO0oSAIiyaZj0EUA8mNQlald7 Gu+9RkMkCDxWsR7nzbm+V7iYckOlVdOW2Kd0mwsmdJNAqbfP8sAU+6QGlR5Cwl+nI+we Izmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684482329; x=1687074329; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=CtjLvqjxXOQAoavWxDZi0rLcHfk15L5roUhC1IcvmqM=; b=Ze0UFy3Bqe8QBuxH63RwSg8Bkee1wj3JWJadJtu44SEcfjtNW33hcuTtUqwx6s86vn 1LevJAHW+gzw5EEr2YzrgjTrWXsefPbCZi1atSD0s6JXhMAv5A07X9kQpO24pHCVyarw 7Q2SKJ7/OS9ct1cBXS/UgQvE2dHl1bDvgwTK4EVLhvYoxOQiM+IN7/0MPU88lg6kCPxH P3Zpa/kIMPgXgb65MBtqrd5jIKAKnR9JWLBFUo0gGwEHFNCaAf54IWU83vtoK9Fm5AYJ z2K52S/T/JxcaaHcT/VNgOHNDwRQDw2JHdaKHPPc1WnjenxFfd2ASHsJU9rWnYun9ZSC IoeQ== X-Gm-Message-State: AC+VfDwycW0KFO1ozBsZPS/MiLmrn5h/3pcmm8iMrza7UjsxmdDMB+W0 OvlV/EX+HIsA7FLMiEw4MJkbOBYG/88Qb5l8V6GG3K4dnQU= X-Google-Smtp-Source: ACHHUZ7wmQrcLWNthm7hYQGHwLWgDCf+CzEYpl1TfYEE+dHCQNCabCZbalG2P153LkvnOXMlatEORheet9vuZc1bvEU= X-Received: by 2002:a05:6902:120c:b0:ba8:58f4:aaba with SMTP id s12-20020a056902120c00b00ba858f4aabamr1112199ybu.24.1684482329294; Fri, 19 May 2023 00:45:29 -0700 (PDT) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <202305190249.34J2n3hg029621@office.dignus.com> In-Reply-To: <202305190249.34J2n3hg029621@office.dignus.com> From: Mario Marietto Date: Fri, 19 May 2023 09:45:17 +0200 Message-ID: Subject: Re: some QEMU success in running armv7 To: Thomas David Rivers Cc: freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="000000000000de3b2505fc071a08" X-Rspamd-Queue-Id: 4QMzQy2lSxz46xT X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --000000000000de3b2505fc071a08 Content-Type: text/plain; charset="UTF-8" Nice review. infortunately kvm does not work ? and a qemu vm without kvm is very slow and useless. Il ven 19 mag 2023, 04:49 Thomas David Rivers ha scritto: > > Just f.y.i. - here's the steps I was able to deduce today > to get FreeBSD armv7 running under qemu... just in case > someone goes looking for this... (I was doing this on a > FreeBSD 12.3-RELEASE x86_64 system.) > > > 1. Retrieve the armv7 image from: > fetch > https://download.freebsd.org/releases/arm/armv7/ISO-IMAGES/13.2/FreeBSD-13.2-RELEASE-arm-armv7-GENERICSD.img.xz > and unzip it. This is an actual hard-drive image of a working > system. > > 2. Assuming the qemu port has been installed - this command > starts that system > > qemu-system-arm -M virt -m 512m -nographic \ > -bios edk2-arm-code.fd \ > -hda FreeBSD-13.2-RELEASE-arm-armv7-GENERICSD.img > > the existing terminal will be the console. There is no > networking. > > There root user's password is 'root'. > > Unfortunately this doesn't provide networking in the guest. This > compilation of QEMU also doesn't support the "-netdev user" mode > of networking so I can't take advantage of that. (The FreeBSD 12.3 > host is using QEMU emulator version 7.2.0 - from just the pkg > install.) However, I found that using this option on qemu: > > -nic tap,ifname=tap7,script=no,downscript=no > > got it to use the tap interface on the host to emulate the virtio > device to the guest. > > I also found this discussion regarding alignment issues in the > virtio driver in armv7: > > > https://forums.freebsd.org/threads/kernel-panic-on-armv7-with-qemu.89016/#post-610281 > > that resulted in PR 271288. Apparently it's because of newer versions > of QEMU doing a better job at reporting unaligned memory accesses in the > guest for the armv7 "ldm" instruction. > > When I use the tap interface, I did get the exact panic mentioned > in the forum and the PR. > > I did find that specifying the rtl8139 device worked around the panic > with the QEMU option: > > -nic tap,ifname=tap7,script=no,downscript=no,model=rtl8139 > > by the way - tap7 happens to be a tap device I'd already configured > on the host FreeBSD 12.3 system - if you're doing this yourself, > it will likely need to be a different tap device, see this > write-up for info about how to configure a tap + bridge on your > FreeBSD host: > > http://bsdwiki.reedmedia.net/wiki/networking_qemu_virtual_bsd_systems.html > > So - it seems a newer version of the armv7 kernel with the patch > applied will fix the virtio driver problem, until then, model=rtl8139 > works around it and I have networking and everything! > > - Dave R. - > > -- > rivers@dignus.com Work: (919) 676-0847 > Get your mainframe programming tools at http://www.dignus.com > > --000000000000de3b2505fc071a08 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Nice review. infortunately kvm does not work ? and a qemu= vm without kvm is very slow and useless.

Il ven 19 mag 2023, 04:49 Thomas D= avid Rivers <rivers@dignus.com&= gt; ha scritto:

Just f.y.i. - here's the steps I was able to deduce today
to get FreeBSD armv7 running under qemu... just in case
someone goes looking for this... (I was doing this on a
FreeBSD 12.3-RELEASE x86_64 system.)


1.=C2=A0 =C2=A0Retrieve the armv7 image from:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 fetch https://download.fr= eebsd.org/releases/arm/armv7/ISO-IMAGES/13.2/FreeBSD-13.2-RELEASE-arm-armv7= -GENERICSD.img.xz
=C2=A0 =C2=A0 =C2=A0and unzip it.=C2=A0 =C2=A0This is an actual hard-drive = image of a working
=C2=A0 =C2=A0 =C2=A0system.

2.=C2=A0 Assuming the qemu port has been installed - this command
=C2=A0 =C2=A0 starts that system

=C2=A0 =C2=A0 qemu-system-arm -M virt -m 512m -nographic \
=C2=A0 =C2=A0 =C2=A0 =C2=A0-bios edk2-arm-code.fd \
=C2=A0 =C2=A0 =C2=A0 =C2=A0-hda FreeBSD-13.2-RELEASE-arm-armv7-GENERICSD.im= g

=C2=A0 =C2=A0 the existing terminal will be the console.=C2=A0 There is no<= br> =C2=A0 =C2=A0 networking.

=C2=A0 =C2=A0 There root user's password is 'root'.

Unfortunately this doesn't provide networking in the guest.=C2=A0 This<= br> compilation of QEMU also doesn't support the "-netdev user" m= ode
of networking so I can't take advantage of that.=C2=A0 (The FreeBSD 12.= 3
host is using QEMU emulator version 7.2.0 - from just the pkg
install.)=C2=A0 However, I found that using this option on qemu:

=C2=A0 =C2=A0 -nic tap,ifname=3Dtap7,script=3Dno,downscript=3Dno

got it to use the tap interface on the host to emulate the virtio
device to the guest.

I also found this discussion regarding alignment issues in the
virtio driver in armv7:

=C2=A0 https://forums.freebsd.org/threads/kernel-panic-on-armv7-with-qemu.89016= /#post-610281

that resulted in PR 271288.=C2=A0 =C2=A0Apparently it's because of newe= r versions
of QEMU doing a better job at reporting unaligned memory accesses in the guest for the armv7 "ldm" instruction.

When I use the tap interface, I did get the exact panic mentioned
in the forum and the PR.

I did find that specifying the rtl8139 device worked around the panic
with the QEMU option:

=C2=A0 -nic tap,ifname=3Dtap7,script=3Dno,downscript=3Dno,model=3Drtl8139
by the way - tap7 happens to be a tap device I'd already configured
on the host FreeBSD 12.3 system - if you're doing this yourself,
it will likely need to be a different tap device, see this
write-up for info about how to configure a tap + bridge on your
FreeBSD host:
=C2=A0 =C2=A0ht= tp://bsdwiki.reedmedia.net/wiki/networking_qemu_virtual_bsd_systems.html

So - it seems a newer version of the armv7 kernel with the patch
applied will fix the virtio driver problem, until then, model=3Drtl8139
works around it and I have networking and everything!

=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Dave R. -

--
r= ivers@dignus.com=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
--000000000000de3b2505fc071a08--