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 2D39E7803E0 for ; Thu, 26 Oct 2023 19:00:58 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=N8nmwBMphjznEzJo3k/zDbiJBkVdbILEXUICtUfnp0g=; 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=1698346856; v=1; b=lpY3Avi9vGJIuEuMIoebU2fcaG7MCIrued7Dv2sTa48rl5anUwEUERbmEJ2RnsT2ey8zN5+k /CWL1qwLMIR5WZe8iCZn7DdgciVjUuvmz0dDH0ZKctutFw9iZbSNEOiDHhWTKFHRHuM1IsbkK8h 6LafRxjB0cGpjAUkggxf0mvE= X-Received: by 127.0.0.2 with SMTP id ND7vYY7687511xXBtqukzL5t; Thu, 26 Oct 2023 12:00:56 -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.web11.79636.1698346856257187247 for ; Thu, 26 Oct 2023 12:00:56 -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-656-LuWDZ0orNliRcE-CA4LfIA-1; Thu, 26 Oct 2023 15:00:52 -0400 X-MC-Unique: LuWDZ0orNliRcE-CA4LfIA-1 X-Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (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 82A6738117F5; Thu, 26 Oct 2023 19:00:51 +0000 (UTC) X-Received: from [10.39.192.119] (unknown [10.39.192.119]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0D4E01C060AE; Thu, 26 Oct 2023 19:00:49 +0000 (UTC) Message-ID: <0ce107d4-dfcf-1a18-ae05-15fa02fdb747@redhat.com> Date: Thu, 26 Oct 2023 21:00:48 +0200 MIME-Version: 1.0 Subject: Re: [edk2-devel] [PATCH 0/9] ArmVirtPkg: support two PL011 UARTs To: devel@edk2.groups.io, ardb@kernel.org Cc: Peter Maydell , Ard Biesheuvel , Gerd Hoffmann , Julien Grall , Leif Lindholm , Sami Mujawar References: <20231008153912.175941-1-lersek@redhat.com> <35314dd9-3705-d322-4137-f4708d420e3e@redhat.com> <9e698cf7-7e58-b32b-58e9-e18f54736f75@redhat.com> From: "Laszlo Ersek" In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.7 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: 5100W4rqQBbAJuycOsInTo1vx7686176AA= 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=lpY3Avi9; 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 17:21, Ard Biesheuvel wrote: > On Thu, 26 Oct 2023 at 17:19, Laszlo Ersek wrote: >> >> 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 t= o >>>> 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). >>> >>> 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. >>> >>> (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.) >>> >>> 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 :-) >>> >>> [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. >> >>> >>>> All in all, I think the implementation would be quite a steep divergen= ce >>>> from, or on top of, this patch set. :) >>> >>> 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. >> >>> >>> Does anybody have time to review Laszlo's code? It would be nice >>> to be able to get this into the next EDK2 release. >> >=20 > I'm happy for this to go in if it covers our needs. >=20 > Acked-by: Ard Biesheuvel Thank you, Ard! Merged as commit range 74c687cc2f2f..f945b72331d7 via . 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 (#110141): https://edk2.groups.io/g/devel/message/110141 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-