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 5C394AC1448 for ; Thu, 26 Oct 2023 15:19:26 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=Ox7OmTep8aMOVVK7genH8m96NKQzpWRuXi5viBDZnJs=; c=relaxed/simple; d=groups.io; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Language:Content-Type:Content-Transfer-Encoding; s=20140610; t=1698333564; v=1; b=ZwSxZuQaoJEU+MdtlNFmaQr44nh8kHbnVPXxzw6lGdqRi69ex6cgmWmmZFsLVxBCaCtMzWe4 3EiY45AKrLzeLkV5Xom9Onsr5bySU9tcJLoPyLLpzpL6K+ZEU1ejPREwowFazCztOXoRwjsc3P9 0gxbNk47W+7M0qgMREvD4fLc= X-Received: by 127.0.0.2 with SMTP id tzRjYY7687511x7mv3QkqF67; Thu, 26 Oct 2023 08:19:24 -0700 X-Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mx.groups.io with SMTP id smtpd.web10.203189.1698333564017888798 for ; Thu, 26 Oct 2023 08:19:24 -0700 X-Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-101-T88s6CEeNHK6yk-aZ8zHbA-1; Thu, 26 Oct 2023 11:19:19 -0400 X-MC-Unique: T88s6CEeNHK6yk-aZ8zHbA-1 X-Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 4B7A3380606E; Thu, 26 Oct 2023 15:19:19 +0000 (UTC) X-Received: from [10.39.192.119] (unknown [10.39.192.119]) by smtp.corp.redhat.com (Postfix) with ESMTPS id DBE2F40C6F7F; Thu, 26 Oct 2023 15:19:17 +0000 (UTC) Message-ID: <9e698cf7-7e58-b32b-58e9-e18f54736f75@redhat.com> Date: Thu, 26 Oct 2023 17:19:16 +0200 MIME-Version: 1.0 Subject: Re: [edk2-devel] [PATCH 0/9] ArmVirtPkg: support two PL011 UARTs To: Peter Maydell Cc: devel@edk2.groups.io, ardb@kernel.org, Ard Biesheuvel , Gerd Hoffmann , Julien Grall , Leif Lindholm , Sami Mujawar References: <20231008153912.175941-1-lersek@redhat.com> <35314dd9-3705-d322-4137-f4708d420e3e@redhat.com> From: "Laszlo Ersek" In-Reply-To: X-Scanned-By: MIMEDefang 3.4.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 Reply-To: devel@edk2.groups.io,lersek@redhat.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: v0UMtrEwidgbC8wX07GNgTswx7686176AA= 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=ZwSxZuQa; 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/26/23 16:21, Peter Maydell wrote: > On Tue, 10 Oct 2023 at 16:33, Laszlo Ersek wrote: >> On 10/10/23 09:43, Ard Biesheuvel wrote: >>> Thanks for looking into this - a cleanup was overdue here. >>> >>> I will take a look in more detail later, but one thing that occurred >>> to me when reading this overview is that having a separate DEBUG >>> serial port would permit us to >>> >>> a) remove it from the DT >> >> ... as in, hide it from Linux, I assume? >> >>> b) add a runtime mapping for it >>> c) keep using it after ExitBootServices >>> >>> This could be useful for debugging issues with the variable store etc. >>> >>> Not saying this is something to address in this series, but I'd like >>> to hear your take on this. >>> >> >> Sounds like a useful feature. >> >> I see four challenges: >> >> >> (1) We'd have to coordinate it with Peter. If we hide any one of the >> serial ports from Linux, that may not be what QEMU intends for Linux to >> happen. Linux currently ties getties to all serial ports -- via the >> serial* aliases, IIUC. Thus, some "positive identification" in the DT >> could be necessary (i.e., that edk2 was welcome to hide that port from >> Linux). >=20 > The potential awkwardness here is that what the guest thinks about > the serial ports depends on the ACPI table fragments which QEMU > provides. EDK2 would need to edit the table fragment to remove any > mention of the second UART if it wanted to hide it from the kernel. > I don't know how hard that would be in EDK2. >=20 > (As far as I'm aware usually a boot via EDK2 doesn't pass the > dtb on to Linux, though I guess there's no reason it can't.) >=20 > From QEMU's point of view, we provide two UARTs to the guest, and we > don't really care whether that means one is used by EDK2 and one by > Linux, or both are used as getty terminals by Linux, or whether the > Linux guest uses one serial as a terminal and leaves the other to its > userspace programs -- it's all just guest software to us :-) >=20 > [snip other technical stuff] Thanks, good point -- I wasn't aware of the ACPI impact. We don't edit / patch QEMU's ACPI tables, ever. (Beyond obeying the ACPI linker/loader script.) That's a principle we've upheld many times. Whenever ACPI content needs to change, that implies a QEMU patch. So, for this purpose, only the following could have a chance of working: - Expose a new config option on the QEMU command line to the user, regarding the intended use of the serial port(s). This could be of any tolerable form (machine property, front-end (device) property, whatever -- anything that QEMU reviewers can accept). - In QEMU, generate both the DT and the ACPI tables accordingly. The ACPI tables would have to immediately *not* contain the UART-to-hide (so as to keep it secret from the guest OS). The DT at the same time would still have to expose the "runtime DEBUG UART", because edk2 would have to know where that UART was (and that it was meant specifically for OS runtime debug output). - Edk2 would have to patch the DT (we tend to do that already), because (in some configs) we do forward the DT to the guest OS. This need for patching could be lifted if QEMU adopted such a form of expression for the "runtime DEBUG UART" that would be ignored by Linux out of the box. >=20 >> All in all, I think the implementation would be quite a steep divergence >> from, or on top of, this patch set. :) >=20 > I agree with this and with Ard's "not something to address in this > series" comment above; it doesn't sound like this is something that > needs to hold up the patchset we have currently. Right; I'd like to flush this one. The runtime debug UART seems to need more joint pondering. >=20 > Does anybody have time to review Laszlo's code? It would be nice > to be able to get this into the next EDK2 release. 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 (#110114): https://edk2.groups.io/g/devel/message/110114 Mute This Topic: https://groups.io/mt/101834880/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-