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 27DA574004A for ; Thu, 7 Sep 2023 13:10:21 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=Ysx4Swu0Smi5oi4rqaWWQd1WpCJcqCE9uB6VuuxMnK0=; c=relaxed/simple; d=groups.io; h=Subject:To:From:User-Agent:MIME-Version:Date:References:In-Reply-To:Message-ID:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type; s=20140610; t=1694092220; v=1; b=m0RdtlB3uMFTPgxPHLWG3d5bl41/Gu/Xb72SZ+FdUXG4d2MaMe0HtM6ID90pDVgc9LDH2Nny 1pc2hC+a0KrshXl/nRVpsiNwUz3pDz7n/5jLsrnYvdPz3YWujPCeE7zOLssCE+fyUrQcp4M8FpL 3KCbAr3s9aL76RZ5IKViyBIc= X-Received: by 127.0.0.2 with SMTP id GiCqYY7687511xErRMBPY0pI; Thu, 07 Sep 2023 06:10:20 -0700 Subject: Re: [edk2-devel] [PATCH v1 1/1] ArmVirtPkg: Enable Early Serial For DxeCore To: Ard Biesheuvel ,devel@edk2.groups.io From: "Laszlo Ersek" X-Originating-Location: Szada, Pest megye, HU (79.120.252.37) X-Originating-Platform: Linux Firefox 102 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Thu, 07 Sep 2023 06:10:20 -0700 References: In-Reply-To: Message-ID: <27912.1694092220075253890@groups.io> 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: ajsQZqSB6oajoOja4NuChhdXx7686176AA= Content-Type: multipart/alternative; boundary="fzrcKJS3Rwa5NPshJmaV" X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=m0RdtlB3; 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 --fzrcKJS3Rwa5NPshJmaV Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable (replying on the webui... sorry!) The problem is actually embedded in MdePkg and MdeModulePkg. - In DxeMain() (and in functions called by DxeMain()), we call DebugLib API= s *before* reaching ProcessLibraryConstructorList(). - In ArmVirtQemu, we resolve the DXE Core's DebugLib dependency to BaseDebu= gLibSerialPort (from MdePkg). - BaseDebugLibSerialPort has a constructor function (BaseDebugLibSerialPort= Constructor()). These already suffice for broken DebugLib behavior. APIs of a library class= should not be called because the library instance has a chance to initiali= ze. The rest is circumstantial. Like, BaseDebugLibSerialPortConstructor calls S= erialPortInitialize, but our SerialPortInitialize (in FdtPL011SerialPortLib= ) does nothing. Well, the latter doesn't need to do anything, because FdtPL= 011SerialPortLib has its own constructor (FdtPL011SerialPortLibInitialize),= thus, if constructors were called properly, then BaseDebugLibSerialPort + = FdtPL011SerialPortLib would work properly together, regardless of SerialPor= tInitialize being empty in the latter. Basically the DXE Core has a hidden requirement -- it can only use such Deb= ugLib instances that need no explicit initialization. The proposed patch works around the problem by satisfying that hidden requi= rement one level lower down: in the SerialPortLib instance. The initializat= ion of BaseDebugLibSerialPort is still busted (its constructor is not calle= d, so it cannot call SerialPortInitialize either), but now it is masked, be= cause EarlyFdtPL011SerialPortLib works withouth *both* SerialPortInitialize= and construction. The real fix would be to make the DXE Core requirement explicit, by introdu= cing separate (dedicated) DebugLib and SerialPortLib *classes* (whose APIs = are guaranteed to work without initialization). 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 (#108386): https://edk2.groups.io/g/devel/message/108386 Mute This Topic: https://groups.io/mt/101203427/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- --fzrcKJS3Rwa5NPshJmaV Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable (replying on the webui... sorry!)

The problem is actually embedd= ed in MdePkg and MdeModulePkg.

- In DxeMain() (and in functions = called by DxeMain()), we call DebugLib APIs *before* reaching ProcessLibrar= yConstructorList().

- In ArmVirtQemu, we resolve the DXE Core's = DebugLib dependency to BaseDebugLibSerialPort (from MdePkg).

- B= aseDebugLibSerialPort has a constructor function (BaseDebugLibSerialPortCon= structor()).

These already suffice for broken DebugLib behavior.= APIs of a library class should not be called because the library instance = has a chance to initialize.

The rest is circumstantial. Like, Ba= seDebugLibSerialPortConstructor calls SerialPortInitialize, but our SerialP= ortInitialize (in FdtPL011SerialPortLib) does nothing. Well, the latter doe= sn't need to do anything, because FdtPL011SerialPortLib has its own constru= ctor (FdtPL011SerialPortLibInitialize), thus, if constructors were called p= roperly, then BaseDebugLibSerialPort + FdtPL011SerialPortLib would work pro= perly together, regardless of SerialPortInitialize being empty in the latte= r.

Basically the DXE Core has a hidden requirement -- it can onl= y use such DebugLib instances that need no explicit initialization.
The proposed patch works around the problem by satisfying that hidden r= equirement one level lower down: in the SerialPortLib instance. The initial= ization of BaseDebugLibSerialPort is still busted (its constructor is not c= alled, so it cannot call SerialPortInitialize either), but now it is masked= , because EarlyFdtPL011SerialPortLib works withouth *both* SerialPortInitia= lize and construction.

The real fix would be to make the DXE Cor= e requirement explicit, by introducing separate (dedicated) DebugLib and Se= rialPortLib *classes* (whose APIs are guaranteed to work without initializa= tion).

Laszlo
_._,_._,_
Groups.io Links:

=20 You receive all messages sent to this group. =20 =20

View/Reply Online (#108386) | =20 | Mute= This Topic | New Topic
Your Subscriptio= n | Contact Group Owner | Unsubscribe [rebecca@openfw.io]

_._,_._,_
--fzrcKJS3Rwa5NPshJmaV--