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 C0E5D740045 for ; Thu, 26 Oct 2023 15:36:38 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=LTfnSrPFUuaqg0c/QluiYLW30QJ4rhYALfqqKbV0YaI=; 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=1698334597; v=1; b=DEV1xlCRzEdLGriSD+bZ8H6oDJ7Xm+tANZNxcGR1MKd2YicZCPAEOrMccUgy+TGY0f2Kn0Ic yvcUmagvMqKfn1mATlYKpCt8hJoOcFUO+ZVhUB5AVhJkemetePovymftE+Cs+TiYUqs6OTTU2+C OnT7qgJwjl7o+7VVgkWA9TTg= X-Received: by 127.0.0.2 with SMTP id qtQNYY7687511xhQ0XejiwCk; Thu, 26 Oct 2023 08:36:37 -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.web11.74063.1698334596832111450 for ; Thu, 26 Oct 2023 08:36:37 -0700 X-Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-533-bb_tyb2EPP2FooM30qPu1w-1; Thu, 26 Oct 2023 11:36:31 -0400 X-MC-Unique: bb_tyb2EPP2FooM30qPu1w-1 X-Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (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 05DD28678AA; Thu, 26 Oct 2023 15:36:31 +0000 (UTC) X-Received: from [10.39.192.119] (unknown [10.39.192.119]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8EC8F2026D68; Thu, 26 Oct 2023 15:36:29 +0000 (UTC) Message-ID: Date: Thu, 26 Oct 2023 17:36:28 +0200 MIME-Version: 1.0 Subject: Re: [edk2-devel] [PATCH 0/9] ArmVirtPkg: support two PL011 UARTs To: Ard Biesheuvel , Julien Grall Cc: Peter Maydell , devel@edk2.groups.io, Ard Biesheuvel , Gerd Hoffmann , Leif Lindholm , Sami Mujawar References: <20231008153912.175941-1-lersek@redhat.com> <35314dd9-3705-d322-4137-f4708d420e3e@redhat.com> <52ab22e6-94c5-4a79-a6f5-2a5c1ed62c27@xen.org> From: "Laszlo Ersek" In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.4 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: lSOP9y5YMOMUbBIEfkJTyEn3x7686176AA= 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=DEV1xlCR; 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:55, Ard Biesheuvel wrote: > 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 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. >> >> 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. >> >=20 > I'd much rather have an implementation of the _STA method on those > devices where the underlying AML queries the fwcfg MMIO device Yes, this is possible too; the AML generated by QEMU need not be constant, it can interact at OS runtime with QEMU. An example for this is the VCPU hotplug register block. The hot(un)plug AML is super sophisticated, it connects the guest kernel, QEMU (via the register block) and the firmware (via raising SMIs). One word of caution against accessing fw_cfg specifically, from AML: fw_cfg is already exposed via guest sysfs (IIRC -- see "drivers/firmware/qemu_fw_cfg.c"), because fw_cfg ended up being "abused" (IMO) as a generic info channel from the host-side user to guest OS + applications. (I call this "abuse" because "fw_cfg" literally says "firmware configuration" in the name, and this particular use case is anything *but* firmware configuration.) Accessing the same device from AML may not be without risks. But "non-fw_cfg platform registers" might work well with AML. 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 (#110123): https://edk2.groups.io/g/devel/message/110123 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-