From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45279) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eOlOa-0003WF-N1 for qemu-devel@nongnu.org; Tue, 12 Dec 2017 09:18:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eOlOS-00081O-9q for qemu-devel@nongnu.org; Tue, 12 Dec 2017 09:18:51 -0500 Date: Tue, 12 Dec 2017 15:18:32 +0100 From: Andrew Jones Message-ID: <20171212141832.gsvlcm77cxg7zbhc@kamzik.brq.redhat.com> References: <6b4b6351-eeb4-a4d3-8ddf-5401516671ae@redhat.com> <5e3798f7-e280-b6c3-1504-828283617c52@redhat.com> <09e7b89f-27f2-1787-b371-7b0c0eff78b8@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH 3/3] hw/arm/virt-acpi-build: Add second UART to ACPI tables List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ard Biesheuvel Cc: Laszlo Ersek , Peter Maydell , "Jason A . Donenfeld" , QEMU Developers , qemu-arm , Andrea Bolognani , Shannon Zhao On Tue, Dec 12, 2017 at 01:56:44PM +0000, Ard Biesheuvel wrote: > On 12 December 2017 at 13:28, Laszlo Ersek wrote: > > On 12/12/17 13:47, Peter Maydell wrote: > >> On 12 December 2017 at 12:41, Laszlo Ersek wrote: > >>> I agree. There's one user-visible complication: while with one UART, > >>> it's not possible to mix things up, with two UARTs, users will > >>> inevitably want to assign inverse roles to them, relative to what QEMU / > >>> the firmware assigns originally. > >>> > >>> E.g. if one PL011 is redirected to a regular file (debug messages) and > >>> the other one to stdio (console), there will be complaints that "I > >>> wanted it the other way around". The redirection happens on the backend > >>> (chardev) level, but the firmware won't see the difference on the > >>> frontend (PL011) level. > >>> > >>> Is it possible to add a new property to the UART nodes in the DTB, like > >>> "purpose"? > >> > >> This is what the "chosen" stdout-path node in the DTB is for, > >> but you said you didn't want to look at that :-) (it means > >> "device to be used for boot console output".) > > > > :( > > > > Ard is right that we really shouldn't do that kind of parsing magic in > > very early UEFI stuff. > > > > > >>> Or can we make a virt-arm policy that "first -serial is always ..., > >>> second -serial is always ..."? > >> > >> Well, the first -serial will always be the 0x09000000 one > >> that we have today, and the second -serial will be the other > >> one (unless you have -machine secure=yes, in which case > >> second -serial is the secure-only UART and third -serial is > >> the second NS UART). > >> > >> Is this any different to the x86 case, where there are two > >> UARTs at different IO port/IRQ locations? > > > > OVMF (x86) uses two distinct devices for the two purposes discussed. > > > > * It uses the "debug console device" for debug message output, at > > hard-coded IO port 0x402; so if you'd like to capture those messages, > > then you have to add: > > > > -chardev file,id=debugfile,path=debug.log \ > > -device isa-debugcon,iobase=0x402,chardev=debugfile \ > > > > (or the more traditional > > > > -debugcon file:debug.log \ > > -global isa-debugcon.iobase=0x402 \ > > ) > > > > * For console I/O, it uses the first serial port. (I think I have once > > investigated what it takes to use other serial ports for console I/O -- > > I'm no longer sure if "it happens to be impossible in OVMF", or just > > "nobody ever does that".) > > > > > > The important distinction (on the UEFI level anyway) is that the debug > > messages need to go to a super dumb device, while console I/O can use a > > much higher-level serial IO abstraction ("protocol"). > > > > > >> I think the only thing users really expect is that if you're > >> using just the one serial port for anything then it's the > >> first one. > > > > You are right -- we've never had two (non-secure) UARTs on virt-arm, so > > we can invent whatever assignment, as long as: > > > > - the single UART case doesn't break (keeps receiving both debug output > > and console IO), > > > > - whatever we invent for the two UARTs case now, it remains consistent > > over time. I think this implies we can rely on the FDT node ordering in > > the firmware (if we want to use the 2nd UART at all, that is), and then > > QEMU shouldn't change the serial_hds[] <-> FDT node mapping in the > > future, in machvirt_init() and the callees thereof. > > > > Given that the DEBUG output is only produced on DEBUG builds, couldn't > we simply stipulate that DEBUG output appears on the PL011 with the > lowest physical address? That keeps the current status quo, and is > probably sufficient for 99% of the use cases of people using the DEBUG > builds. I was thinking that if AAVMF learned to use a second UART for debug output, that the debug builds could go away, as they have for x86 (IIUC). If a user wires up a second UART, then AAVMF could unconditionally output debug messages to it. Not wiring it up would lose the messages, which is no different than the non-verbose build we have today. It would be nice if could tell AAVMF not to use a second UART for debug messages too, though, as the debug messages make AAVMF quite slow, and the user may want to provide the guest a second UART. > > Then, we can introduce some code to decode stdout-path in FdtClientDxe > (a higher level DT parsing driver) so that the actual serial console > gets installed onto whichever UART is described as the system console. > Also, given that ArmVirtQemu is tightly coupled to QEMU/mach-virt, we > could decide to only use node names in stdout-path (as we do > currently) to simplify the parsing logic. > That sounds reasonable and would only require adding a comment above the setting of stdout-path in the QEMU code to formalize it. Thanks, drew