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 326637803D9 for ; Thu, 26 Oct 2023 14:55:48 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=HAAONypx7Y/yrMZCMdAsBSAmrvRtBoWhlo8uxMKGq/Q=; 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=1698332146; v=1; b=L+XBPjTsRK+DaQrs3CapejlGuDhnOLFeDTQSgw/2CNS7y435hJgiukkcv/849O4QjuicEVHi V4/p9VM0lAw1pCXo4iUGhntebrdr5GFILlwoTmRoKryZ5Ns4F0mc+VfVYWdCrqCauAAV+b7YVE6 a3Wcai953e4DqmNEFBVd24bk= X-Received: by 127.0.0.2 with SMTP id IQgdYY7687511xZVHcYmlZ2Q; Thu, 26 Oct 2023 07:55:46 -0700 X-Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mx.groups.io with SMTP id smtpd.web11.73023.1698332146277384073 for ; Thu, 26 Oct 2023 07:55:46 -0700 X-Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id A49F163510 for ; Thu, 26 Oct 2023 14:55:45 +0000 (UTC) X-Received: by smtp.kernel.org (Postfix) with ESMTPSA id 52A5BC433CB for ; Thu, 26 Oct 2023 14:55:45 +0000 (UTC) X-Received: by mail-lj1-f172.google.com with SMTP id 38308e7fff4ca-2c3e23a818bso11358131fa.0 for ; Thu, 26 Oct 2023 07:55:45 -0700 (PDT) X-Gm-Message-State: 6eUmOSg4Qsfx7K38EGosMFaDx7686176AA= X-Google-Smtp-Source: AGHT+IGNoKYdd0DO0h/RVy+uCONKb9/FaZqGqvcthkWDt1hjd3aTBSFxTsULNrgxVzQLYk0oaWG5d0gYzEdF531NSSQ= X-Received: by 2002:a2e:875a:0:b0:2c5:1c6:80dc with SMTP id q26-20020a2e875a000000b002c501c680dcmr1074064ljj.15.1698332143448; Thu, 26 Oct 2023 07:55:43 -0700 (PDT) MIME-Version: 1.0 References: <20231008153912.175941-1-lersek@redhat.com> <35314dd9-3705-d322-4137-f4708d420e3e@redhat.com> <52ab22e6-94c5-4a79-a6f5-2a5c1ed62c27@xen.org> In-Reply-To: <52ab22e6-94c5-4a79-a6f5-2a5c1ed62c27@xen.org> From: "Ard Biesheuvel" Date: Thu, 26 Oct 2023 16:55:31 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH 0/9] ArmVirtPkg: support two PL011 UARTs To: Julien Grall Cc: Peter Maydell , Laszlo Ersek , devel@edk2.groups.io, Ard Biesheuvel , Gerd Hoffmann , 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=L+XBPjTs; 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 16:46, Julien Grall wrote: > > Hi, > > On 26/10/2023 15: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. > > I am not sure if it would help EDK2 in this case. But we had a similar > problem when adding support for ACPI in Xen. It was not trivial to > remove the UART from the ACPI tables provided by the host. So we ended > up to introduce the STAO table [1]. This is used to describe which > device will be hidden to the OS. > I'd much rather have an implementation of the _STA method on those devices where the underlying AML queries the fwcfg MMIO device -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#110108): https://edk2.groups.io/g/devel/message/110108 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] -=-=-=-=-=-=-=-=-=-=-=-