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 6D6A6941C23 for ; Thu, 26 Oct 2023 15:21:40 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=v2YqoqCAatg8lpqGtCTg0ZL3pWPPssf3dyJ/wEui//c=; c=relaxed/simple; d=groups.io; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:To:Cc:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type; s=20140610; t=1698333699; v=1; b=Ifkgnq2Js9Un7bN+OBW0kLwYCz/2P8wdXMN/Ur0Gv9FTudTxGCEm4XLSp9kGRw0CJ6CtD1bi THX0KbZZsCiyMscMYPqtYTxpVmMxzBh1hsVIdgp8A8LQwVAfWsjRCyAh3RDHQtB0XaSqQ45BATG Rls/lVMicSQ4y7DhI+dAonSE= X-Received: by 127.0.0.2 with SMTP id BJORYY7687511xPkKTipugLt; Thu, 26 Oct 2023 08:21:39 -0700 X-Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by mx.groups.io with SMTP id smtpd.web10.203254.1698333698136939237 for ; Thu, 26 Oct 2023 08:21:38 -0700 X-Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by ams.source.kernel.org (Postfix) with ESMTP id 91A5AB832FF for ; Thu, 26 Oct 2023 15:21:35 +0000 (UTC) X-Received: by smtp.kernel.org (Postfix) with ESMTPSA id E99B5C433C7 for ; Thu, 26 Oct 2023 15:21:34 +0000 (UTC) X-Received: by mail-lj1-f181.google.com with SMTP id 38308e7fff4ca-2c5629fdbf8so14528951fa.0 for ; Thu, 26 Oct 2023 08:21:34 -0700 (PDT) X-Gm-Message-State: 1qZJEHaOnyelJL5OV1Litgqmx7686176AA= X-Google-Smtp-Source: AGHT+IGpWk9mEYYLc4GuSwHmK5RKMX+cf/tgGasH5XZQWaf+RgNWp32a3p3HTX+fOEvNS7qa3ko16l4qAEJz7MFEsP4= X-Received: by 2002:a2e:8699:0:b0:2bc:dd96:147c with SMTP id l25-20020a2e8699000000b002bcdd96147cmr13151529lji.34.1698333693148; Thu, 26 Oct 2023 08:21:33 -0700 (PDT) MIME-Version: 1.0 References: <20231008153912.175941-1-lersek@redhat.com> <35314dd9-3705-d322-4137-f4708d420e3e@redhat.com> <9e698cf7-7e58-b32b-58e9-e18f54736f75@redhat.com> In-Reply-To: <9e698cf7-7e58-b32b-58e9-e18f54736f75@redhat.com> From: "Ard Biesheuvel" Date: Thu, 26 Oct 2023 17:21:21 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH 0/9] ArmVirtPkg: support two PL011 UARTs To: Laszlo Ersek Cc: Peter Maydell , devel@edk2.groups.io, Ard Biesheuvel , Gerd Hoffmann , Julien Grall , Leif Lindholm , Sami Mujawar 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,ardb@kernel.org List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: Content-Type: text/plain; charset="UTF-8" X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=Ifkgnq2J; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (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 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 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). > > > > 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 divergence > >> 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. > I'm happy for this to go in if it covers our needs. Acked-by: Ard Biesheuvel -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#110115): https://edk2.groups.io/g/devel/message/110115 Mute This Topic: https://groups.io/mt/101834880/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=-