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 E78AB9419E5 for ; Thu, 26 Oct 2023 14:59:51 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=nqKETDLj+CrUCoKHhD3LofoDUfcnmSUgerSAJebhObs=; 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=1698332390; v=1; b=DSbyOC6Ou+x0BgKnILQfe4gsyUcAdGUniuRK3R8wk1oTn1jb+As6p00uF1Hbmi7mvcwWca2Q +rtdw1z4MgDjxrwx+z75Xqi3MWiJiihWhaW59XPqG8xmWRa5QuPdhUbFjX7XXpySV3PROkA5q9p Fqdjwlz1y9hi+e+JMKD6Sgxo= X-Received: by 127.0.0.2 with SMTP id 8NkcYY7687511xlo4NlvYxIa; Thu, 26 Oct 2023 07:59:50 -0700 X-Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com [209.85.208.44]) by mx.groups.io with SMTP id smtpd.web10.201563.1698330085748215586 for ; Thu, 26 Oct 2023 07:21:26 -0700 X-Received: by mail-ed1-f44.google.com with SMTP id 4fb4d7f45d1cf-5406c099cebso1435941a12.2 for ; Thu, 26 Oct 2023 07:21:25 -0700 (PDT) X-Gm-Message-State: 8FnIsYxHL148uWaRZM7Sxlbhx7686176AA= X-Google-Smtp-Source: AGHT+IH+iVfoddhrAnxNnZpP3z2c3oGl828PuEME44JsSlC857HzGpUf2260rUO0zCL84yfY1XVtJOZJ2JLrE3p2mCc= X-Received: by 2002:a50:875b:0:b0:53f:9ced:e5b4 with SMTP id 27-20020a50875b000000b0053f9cede5b4mr14415932edv.13.1698330084095; Thu, 26 Oct 2023 07:21:24 -0700 (PDT) MIME-Version: 1.0 References: <20231008153912.175941-1-lersek@redhat.com> <35314dd9-3705-d322-4137-f4708d420e3e@redhat.com> In-Reply-To: <35314dd9-3705-d322-4137-f4708d420e3e@redhat.com> From: Peter Maydell Date: Thu, 26 Oct 2023 15:21:13 +0100 Message-ID: Subject: Re: [edk2-devel] [PATCH 0/9] ArmVirtPkg: support two PL011 UARTs To: Laszlo Ersek Cc: devel@edk2.groups.io, ardb@kernel.org, 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,peter.maydell@linaro.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=DSbyOC6O; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=linaro.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 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] > 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. 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 -- PMM -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#110112): https://edk2.groups.io/g/devel/message/110112 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] -=-=-=-=-=-=-=-=-=-=-=-