From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id E1EA5941E5A for ; Mon, 2 Oct 2023 23:06:07 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=g+C1ScEyI9scsiCNFV1vvTrLpNJoazY/kD2VBuTDCRQ=; c=relaxed/simple; d=groups.io; h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:Reply-To:References:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Language:Content-Type:Content-Transfer-Encoding; s=20140610; t=1696287966; v=1; b=hJv7VY33q9tzpon5hXoxnES7/UEo/hTJ9/pbzj7yiNImrPgiesgn6HKEm+iaBYu8vkTrFdG9 GLXuyc+Hqu6M2opOaa0zbyaOa93iXkyjOqtioNzyPe7pSHTb0qJevKb+j0boMZLqxvIQmKV8q9w 4kgH2h3g2aYb5xBHoP1m+qUc= X-Received: by 127.0.0.2 with SMTP id 5t7hYY7687511xz6AqWa5BUx; Mon, 02 Oct 2023 16:06:06 -0700 X-Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web10.96940.1696287965784636001 for ; Mon, 02 Oct 2023 16:06:05 -0700 X-Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-66-FcBA-jXgMga_GjEAddr2-g-1; Mon, 02 Oct 2023 19:05:41 -0400 X-MC-Unique: FcBA-jXgMga_GjEAddr2-g-1 X-Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 4F30C858F1B; Mon, 2 Oct 2023 23:05:41 +0000 (UTC) X-Received: from [10.39.192.119] (unknown [10.39.192.119]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 161FE40C6EBF; Mon, 2 Oct 2023 23:05:39 +0000 (UTC) Message-ID: <09b516d7-559d-303e-1532-9b5abe157b5a@redhat.com> Date: Tue, 3 Oct 2023 01:05:38 +0200 MIME-Version: 1.0 Subject: Re: [edk2-devel] EDK2 ArmVirtQemu behaviour with multiple UARTs From: "Laszlo Ersek" To: Peter Maydell Cc: Ard Biesheuvel , Gerd Hoffmann , edk2-devel-groups-io Reply-To: devel@edk2.groups.io,lersek@redhat.com References: <1aee726a-4522-5513-95da-0160d92a1de2@redhat.com> In-Reply-To: <1aee726a-4522-5513-95da-0160d92a1de2@redhat.com> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: X7K3HeFqvFlMWaFboyMrTlRDx7686176AA= Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=hJv7VY33; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=redhat.com (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io On 10/2/23 03:51, Laszlo Ersek wrote: > On 9/21/23 12:50, peter.maydell at linaro.org (Peter Maydell) wrote: >=20 >> If you want to play around with this, I have some WIP patches at >> https://git.linaro.org/people/pmaydell/qemu-arm.git uart-edk-investigati= on >> (content wise they should be fine, but I haven't cleaned them up into >> a coherent set of distinct patches yet, so they're a bit messy.) >> A run of QEMU with both UARTs which sends all output to files looks like= : >> >> ./build/arm-clang/qemu-system-aarch64 -display none -vga none \ >> -machine virt,acpi=3Don,virtualization=3Don,mte=3Don,gic-version=3Dmax= ,iommu=3Dsmmuv3 \ >> -smp 2 -m 1024 -cpu max,pauth-impdef=3Don \ >> -bios ~/linaro/edk2/QEMU_EFI_DEBUG.fd \ >> -drive file=3D/home/petmay01/avocado/data/cache/by_location/0154b7cd3a= 4f5e135299060c8cabbeec10b70b6d/alpine-standard-3.17.2-aarch64.iso,format=3D= raw >> \ >> -device virtio-rng-pci,rng=3Drng0 \ >> -object rng-random,id=3Drng0,filename=3D/dev/urandom \ >> -chardev file,id=3Dchr0,path=3D/tmp/uart0-rev.txt \ >> -chardev file,id=3Dchr1,path=3D/tmp/uart1-rev.txt \ >> -serial chardev:chr0 -serial chardev:chr1 >> >> (adjust -serial options to taste) >=20 > Is the "uart-edk-investigation" branch still the most recent one for > this? (I've not checked it yet, but coming close.) I checked out your branch and built it at commit "virt: Reverse order of UA= RT dtb nodes". I included my edk2 patches in my edk2 binary. The QEMU command line is /opt/qemu-installed-optimized/bin/qemu-system-aarch64 \ -device virtio-gpu-pci \ -machine virt,acpi=3Don,virtualization=3Don,mte=3Don,gic-version=3Dmax,io= mmu=3Dsmmuv3 \ -smp 2 \ -m 1024 \ -cpu max,pauth-impdef=3Don \ -drive if=3Dpflash,file=3D/home/virt-images/arm/QEMU_EFI.fd.padded,format= =3Draw,readonly=3Don \ -drive if=3Dpflash,file=3D/home/virt-images/arm/QEMU_VARS.fd.padded,forma= t=3Draw,snapshot=3Don \ -drive if=3Dnone,file=3D/home/lacos/tmp/alpine-standard-3.18.4-aarch64.is= o,format=3Draw,readonly=3Don,id=3Dalpine \ -device virtio-scsi-pci,id=3Dvscsi \ -device scsi-cd,drive=3Dalpine,bus=3Dvscsi.0,bootindex=3D1 \ -device virtio-rng-pci,rng=3Drng0 \ -object rng-random,id=3Drng0,filename=3D/dev/urandom \ -device qemu-xhci,id=3Dxhci \ -device usb-kbd,bus=3Dxhci.0 \ -chardev stdio,mux=3Don,id=3Dmonitor-and-console \ -mon chardev=3Dmonitor-and-console,mode=3Dreadline \ -serial chardev:monitor-and-console \ -chardev file,id=3Ddebug-log,path=3D/home/lacos/tmp/debug.txt \ -serial chardev:debug-log With this command line, I have three windows to watch: (1) a graphical guest display window (virtio-gpu-pci), supposed to serve th= e following purposes: (1.1) multiplexed output from the UEFI console, (1.2) Linux virtual console (in character mode) (2) the terminal where I start the command from, supposed to serve (mux / C= -a) the following purposes: (2.1) the QEMU monitor, (2.2) the guest serial port that is *supposed* to serve the following purpo= ses: (2.2.1) direct SerialPortLib usage from edk2 modules, (2.2.2) the UEFI console, (2.2.3) the Linux boot log and a serial login prompt (3) a separate terminal where I run "tail -F debug.txt", intending to see: (3.1) the edk2 DEBUG log Also I intend to provide input via: (4) USB-3 keyboard when focusing the graphical window (1) (5) QEMU monitor commands in the terminal where I start QEMU (2) (6) serial input to the guest in the terminal where I start QEMU (2) Results: * edk2 writes the message UEFI firmware (version built at 03:38:24 on Oct 2 2023) to window (2), with direct SerialPortLib usage. * the edk2 DEBUG log goes solely to the file "debug.txt" / window (3), not = messing up the UEFI console (i.e., windows (1) and (2)) * the edk2 DEBUG log contains the following two lines: PlatformPeim: PL011 UART (console) @ 0x9000000 PlatformPeim: PL011 UART (debug) @ 0x9040000 * the UEFI console output is properly multiplexed to windows (1) and (2), a= nd the UEFI console properly takes input from both (4) and (6). This covers= both the edk2 Boot Manager, and Grub from the alpine ISO. * in Grub, I replace alpine's default kernel option "quiet" with the two op= tions "ignore_loglevel efi=3Ddebug". (Because grub uses the UEFI console, i= t properly takes input from both (4) and (6).) * I see the guest kernel's EFI Stub's messages on the UEFI console (multipl= exed to windows (1) and (2)) * I see the kernel boot log in window (2) -- that is, on the proper serial = port. This includes both kernel debug messages, and userspace boot log mess= ages * Finally I get the following printout: Welcome to Alpine Linux 3.18 Kernel 6.1.55-0-lts on an aarch64 (TTY_LINE) in *all three* windows. Notably, the TTY_LINE value is the following: - in window (1) -- virtio-gpu-pci --, it is "/dev/tty1" - in window (2) (the "console" serial port) it is "/dev/ttyAMA0" - in window (3) (that is, the "debug.txt" file) it is "/dev/ttyAMA1" * Linux takes keyboard input in both windows (1) and (2) via (4) and (6) re= spectively; (3) is not testable (and is not expected to take input) because= "-chardev file" is only good for output. So this is *total success*; the only (positive) surprise is that Linux prov= ides a login prompt on /dev/ttyAMA1 as well. * Rebuilding QEMU at the *parent* patch -- namely "add to acpi table" --, t= hat is, with patch "virt: Reverse order of UART dtb nodes" *popped*, all of= the above results remain identical. * dropping the "debug-log" chardev, and the serial port that references it,= from the QEMU cmdline, there is one difference (and those results generall= y match the current upstream status): the edk2 DEBUG log is merged into the= UEFI console output as the latter is multiplexed to the sole serial port -= - making a mess for the reader. And of course Linux cannot offer a login pr= ompt on "/dev/ttyAMA1". I say we want this! I have one patch under review ("[edk2-devel] [PATCH 1/1] ArmVirtPkg/FdtPL01= 1SerialPortLib: initialize implicitly"), which is independent, but contextu= ally a pre-requisite for my "armvirt-dual-serial" branch. Once that patch i= s merged, I'll post this branch. And I suggest going forward with the QEMU-= side patches as well. --*-- ... Just for kicks, I also tested the following change to the QEMU command = line: @@ -19,6 +19,7 @@ -device usb-kbd,bus=3Dxhci.0 \ -chardev stdio,mux=3Don,id=3Dmonitor-and-console \ -mon chardev=3Dmonitor-and-console,mode=3Dreadline \ - -serial chardev:monitor-and-console \ + -device virtio-serial-pci,id=3Dvserial \ + -device virtconsole,bus=3Dvserial.0,chardev=3Dmonitor-and-console \ -chardev file,id=3Ddebug-log,path=3D/home/lacos/tmp/debug.txt \ -serial chardev:debug-log The behavior is not immediately intuitive, but it's correct after all. The = *sole* PL011 UART -- now in "debug.txt" in window (3) -- unifies several pu= rposes in edk2: UEFI console IO (including edk2 Boot manager and Grub), dir= ect SerialPortLib output, and DEBUG messages. The virtio-gpu-pci window (1)= functions undisturbed (UEFI console). The virtio serial console in window = (2) properly works as a "head" of the UEFI console. Even with the virtio serial console, I think that having *two* PL011 serial= ports will be beneficial. With virtio-serial plus *one* PL011, we can have= undisturbed non-graphical UEFI console, but there still isn't an undisturb= ed DEBUG log -- the sole PL011 still includes both UEFI console (multiplexe= d) and DEBUG. If we add in the second PL011, then the DEBUG log is pristine= as well, same as with isa-debugcon under x86. Furthermore, a disadvantage of virtio-serial plus *one* PL011 is that once = I boot Linux, the kernel log + userspace log goes to the PL011. That's a bi= t of a UX disruption, because in this setup, we tend to look at the virtio-= serial console, due to the PL011 still being a mixture of UEFI console + DE= BUG. So the Linux boot log appears "elsewhere", and even the login prompt d= oes not appear on virtio-serial (probably because in this build of Alpine, = no virtio-serial driver is included; I guess anyway). So either way, to mirror the x86 experience most closely (where we have und= isturbed UEFI console on the ISA serial port *and/or* on virtio serial; *pl= us* undisturbed DEBUG output on isa-debugcon), we need two PL011 UARTs on a= arch64. With one PL011 plus virtio-serial, the UEFI console is cleaned up (= on virtio-serial), but the sole PL011 still contains a mixure of DEBUG and = UEFI console -- and that's the only way we get a (somewhat garbled) DEBUG l= og in that setup. Thanks, Laszlo -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#109268): https://edk2.groups.io/g/devel/message/109268 Mute This Topic: https://groups.io/mt/101498371/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/19134562= 12/xyzzy [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-