From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=45.249.212.190; helo=huawei.com; envelope-from=guoheyi@huawei.com; receiver=edk2-devel@lists.01.org Received: from huawei.com (szxga04-in.huawei.com [45.249.212.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 3CCD8211D35DC for ; Mon, 4 Mar 2019 05:52:44 -0800 (PST) Received: from DGGEMS409-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 8296FE2E8E68F0B2C309; Mon, 4 Mar 2019 21:52:40 +0800 (CST) Received: from [127.0.0.1] (10.177.31.55) by DGGEMS409-HUB.china.huawei.com (10.3.19.209) with Microsoft SMTP Server id 14.3.408.0; Mon, 4 Mar 2019 21:52:30 +0800 To: Laszlo Ersek , Ard Biesheuvel References: <1551341112-21645-1-git-send-email-guoheyi@huawei.com> CC: "edk2-devel@lists.01.org" , wanghaibin 00208455 , Jian J Wang , Hao Wu , Julien Grall , Peter Maydell From: Heyi Guo Message-ID: Date: Mon, 4 Mar 2019 21:52:28 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: X-Originating-IP: [10.177.31.55] X-CFilter-Loop: Reflected Subject: Re: [RFC 0/3] Enable runtime serial debug for ArmVirtQemu X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 13:52:44 -0000 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit On 2019/3/1 23:27, Laszlo Ersek wrote: > +Peter, for the last few paragraphs > > On 02/28/19 13:10, Ard Biesheuvel wrote: >> On Thu, 28 Feb 2019 at 09:06, Heyi Guo wrote: >>> Serial port output is useful when debugging UEFI runtime services in OS runtime. >>> The patches are trying to provide a handy method to enable runtime serial port >>> debug for ArmVirtQemu. >>> >>> Cc: Jian J Wang >>> Cc: Hao Wu >>> Cc: Laszlo Ersek >>> Cc: Ard Biesheuvel >>> Cc: Julien Grall >>> >>> Heyi Guo (3): >>> MdeModulePkg/StatusCode: Add PCD to enable runtime serial debug >>> ArmVirtPkg: add runtime instance of FdtPL011SerialPortLib >>> ArmVirtQemu: enable runtime debug by build flag >>> >> Hello Heyi, >> >> We have had this discussion before, and IIRC, the proposed solution >> was to use status codes. >> >> I'm not sure how that is supposed to work though - hopefully Laszlo or >> one of the MdeModulePkg maintainers can elaborate. > Here's the basic idea. > > Status Code reporting and routing are defined by the PI spec for OS > runtime as well, not just boot time. > > Recently we added status code *routing* to ArmVirtPkg, in commit > 5c574b222ec2, via the generic runtime driver > "ReportStatusCodeRouterRuntimeDxe". We also added the library resolution > > ReportStatusCodeLib --> > MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf > > (for some module types). As a result, when modules of those types report > status codes, they now reach the ReportStatusCodeRouterRuntimeDxe > driver, which "routes" the status codes. > > In the same series, we also modified ArmVirtPkg's PlatformBootManagerLib > (built into BdsDxe) to register a status code *handler* callback with > ReportStatusCodeRouterRuntimeDxe -- but only for boot time (not > runtime), and only for a very specific group of status codes. As a > result, when a module of suitable type reports a status code, > ReportStatusCodeRouterRuntimeDxe "routes it" to BdsDxe, and then BdsDxe > "handles it" (in our implementation, we simply format it to the UEFI > console), assuming the status code is the kind we are interested in. > > > Now we come to the current series. First, the series adds the following > DebugLib class resolution: > > DebugLib --> > MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf > > This will cause modules to publish their DEBUG messages as status codes > via ReportStatusCodeLib, rather than log them via SerialPortLib. (I'm > too lazy to check the exact status code classes etc that > PeiDxeDebugLibReportStatusCode embeds the DEBUG messages into.) As a > result, DEBUG messages will reach ReportStatusCodeRouterRuntimeDxe for > "routing". As another result, until we reach a late enough stage in the > boot, those messages will not be printed by anything (because there's > not going to be any "handling" for them). > > (The present series also updates the ReportStatusCodeLib resolution so > it can be used at runtime too, but that's quite auxiliary to this > discussion.) > > Second, this series includes the generic Status Code *handling* driver > (also a runtime driver): "StatusCodeHandlerRuntimeDxe". Independently of > the particular handling that we already have in BdsDxe via the earlier > series, this generic status handler driver registers a handler callback > that simply prints status codes to the serial port (dependent on a PCD > setting), via SerialPortLib. > > With the modification from the first patch, this generic status code > *handler* driver is extended to runtime serial port operation. And, the > second patch in the series provides a SerialPortLib instance for it that > can work at runtime. > > All in all, when a runtime driver calls DEBUG, this happens: > > runtime driver calls DEBUG > -> PeiDxeDebugLibReportStatusCode > -> RuntimeDxeReportStatusCodeLib > [status code reporting] > > => ReportStatusCodeRouterRuntimeDxe > [status code routing] > > => StatusCodeHandlerRuntimeDxe > [status code handling, such as SerialPortWrite():] > -> FdtPL011SerialPortLibRuntime > > This is actually a good idea, but it would be nice if: > - QEMU had two PL011 ports, > - the boot time firmware log, and the OS log, went to one port > - the runtme firmware log went to the other port. This makes sense. I'll try the 2nd serial port. Thanks, Heyi > > Given that this series provides the SerialPortLib instance for > StatusCodeHandlerRuntimeDxe anyway, we could implement it so that it > locate a "special" PL011 in QEMU's DTB -- the port that we'd only use > for runtime firmware logging. > > I don't insist that this series implement all of that, but it should > either prevent a conflict on the one PL011 between the firmware and the > OS, or else be very explicit about the possible conflict in the commit > messages. > > Thanks > Laszlo > > . >