From nobody Fri Feb 14 09:15:21 2025 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 4YvRGn0Gp9z5p3b0; Fri, 14 Feb 2025 09:15:29 +0000 (UTC) (envelope-from zlei@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YvRGm5wXCz3Tbp; Fri, 14 Feb 2025 09:15:28 +0000 (UTC) (envelope-from zlei@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1739524528; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=cWTiBoLyt+IypfnQFzmghEk8CgvXXdpcXCoBZNwTfZY=; b=gYJERg/ewyo/r1mkXE2y8tuwUsggRJ/c4EoBLMf9YvNLG0QmX62Y4OFyAOj0QSWI4/wErN iI4dOcXGXO3GORwesKcSTy3jw0BwblUy7sJvl8PUMMAXnqn0fTSNfk1WKMwrgxrCj/ce0P luz9t4wkekVvSAYUENUNX1jEX50YcHAG3ig81Gko6QKFwWKeMtmoVKGnf9X7AqJiz1jv+p pAx+4IrHgoQ43zgjNmFzNnuVK2bOzQEaXNU31VQNvAtqfgEhns3BbyNMOA0ReX7Hm3aHqH jV0AjRPwKy+36GixMvRybKu4mJD7vzM6YPTq5kC0wBKr1Q6CoTbvw9mOvr33hQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1739524528; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=cWTiBoLyt+IypfnQFzmghEk8CgvXXdpcXCoBZNwTfZY=; b=JzZ4HPR4PWHINUYOUalCf3zM/VuIXrgR02wf2+TOvfU85ZiVSCii2mSgrtNrlCgIQUK1Ly qGbFTtZHsz13h4swpiEM+vKlYWYZCE+Xnyr+kl/QtIZ+WW/mjG84EX6Kw411IOGeBfs89F NF1jGHCg0D9S/z+s8THN2MXe9BB6b8Jdu/SH01Jg2PZxxGywjMcsFD+dj2bO2Zytnd/PhE mToR0KEsoqZ7ywVdauGm1+dYzCHS+KjfJfEFQ9lTdv7QQcpC6wy2ELBb6tIHZLtHfPC63R IPNYTiiOXeEe+gVDicVdsIyXlrSDsTqFoUPaGgqjxt1j3lx81KPgvZZd93HIrA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1739524528; a=rsa-sha256; cv=none; b=fVZ/rl23LbMLjVgDBXS7s4aqgu3dMgZYOqIWuE4MW+gXo61gIqk+U3LLPBrsSgvwY7Ojtu o8QUm+WWQ1ILD6T51qTLdhIhBlfjGrTN4EOoVXaTsTV6dZMUxpYGML3RrXlrRa/TpHVYfr SaLvuiabsK8Lm1t+LkTPVbkstF22R8AEjz1rOYCdSVy0x0snvp64IhVNiW+ZYGP/00PXbo Y6uNTd3Vp2hTBK33i10yU7U92qASGV/lhejSGo8emYC+8f/jxvzARV4nYELm5ZCD3tn2Ns pYQUs7w8uB5qhpzG/e8Zbrex1yLoHThzJmkgJFWtAitlH8iAdRx7PJNU9glD7Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from smtpclient.apple (ns1.oxydns.net [45.32.91.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: zlei/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4YvRGl0lYGzJlq; Fri, 14 Feb 2025 09:15:26 +0000 (UTC) (envelope-from zlei@FreeBSD.org) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3696.120.41.1.10\)) Subject: Re: A way to have a console (aarch64) under macOS Parallels: build the kernel with nodevice virtio_gpu; any way with an official kernel build? From: Zhenlei Huang In-Reply-To: Date: Fri, 14 Feb 2025 17:15:21 +0800 Cc: FreeBSD virtualization , freebsd-arm , Warner Losh , John Baldwin Content-Transfer-Encoding: quoted-printable Message-Id: <67D0FCFF-54FC-4121-91F6-EC48B437991A@FreeBSD.org> References: To: Mark Millard X-Mailer: Apple Mail (2.3696.120.41.1.10) > On Feb 14, 2025, at 6:39 AM, Mark Millard wrote: >=20 > I've been testing using FreeBSD under Parallels on a MacBook Pro M4 = MAX, > although the issue below and its handling may not be specific to = aarch64 > contexts. >=20 > After (from a demsg -a from a verbose boot): >=20 > . . . > 000.000078 [ 452] vtnet_netmap_attach vtnet attached txq=3D1, = txd=3D128 rxq=3D1, rxd=3D128 > pci0: at device 9.0 (no driver attached) > virtio_pci1: mem = 0x10000000-0x17ffffff,0x18008000-0x18008fff,0x18000000-0x18003fff at = device 10.0 on pci0 > vtgpu0: on virtio_pci1 > virtio_pci1: host features: 0x100000000 > virtio_pci1: negotiated features: 0x100000000 > virtio_pci1: attempting to allocate 1 MSI-X vectors (2 supported) > virtio_pci1: attempting to allocate 2 MSI-X vectors (2 supported) > pcib0: matched entry for 0.10.INTA > pcib0: slot 10 INTA hardwired to IRQ 39 > virtio_pci1: using legacy interrupt > VT: Replacing driver "efifb" with new "virtio_gpu". >=20 > I end have no console. I ended up in a state where it > turned out booting went to stand-alone mode for a manual > fsck. So: no ssh access or any other access. I ended up > using the Windows Dev Kit 2023 with the boot device in > order figure out what was going on and to the the needed > fsck. >=20 > Turns out that if I'm building, installing, and booting > my own kernel, there is a way around that replacement > of efifb by using: >=20 > nodevice virtio_gpu >=20 > in the kernel configuration, so that the boot ends up > using efifb (no replacement). >=20 > If course, this does not help with kernels from official > FreeBSD builds. >=20 > Is there a way to disable virtio_gpu for something that > runs an official kernel build (where virtio_gpu is > built into the kernel)? May you try with device.hints(5) ? It can mark a device disabled ( no driver loaded ) when probing, so you = can avoid `VT: Replacing driver "efifb" with new "virtio_gpu"` and should have the = same effect with `nodevice virtio_gpu`. Best regards, Zhenlei >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com >=20 >=20