From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 BC3C4208F7AD0 for ; Tue, 27 Jun 2017 06:21:36 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2E031142878; Tue, 27 Jun 2017 13:23:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 2E031142878 Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lersek@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 2E031142878 Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-38.phx2.redhat.com [10.3.116.38]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3C2C57BCDF; Tue, 27 Jun 2017 13:23:04 +0000 (UTC) From: Laszlo Ersek To: "Zeng, Star" , Amit Kumar , "edk2-devel@lists.01.org" Cc: "Kinney, Michael D" , "Tian, Feng" , "Gabriel L. Somlo (GMail)" , "Gao, Liming" , "Fan, Jeff" References: <0C09AFA07DD0434D9E2A0C6AEB0483103B8ED8A7@shsmsx102.ccr.corp.intel.com> <0C09AFA07DD0434D9E2A0C6AEB0483103B8ED94C@shsmsx102.ccr.corp.intel.com> <0C09AFA07DD0434D9E2A0C6AEB0483103B8EEED6@shsmsx102.ccr.corp.intel.com> Message-ID: Date: Tue, 27 Jun 2017 15:23:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Tue, 27 Jun 2017 13:23:06 +0000 (UTC) Subject: Re: [PATCH V4] MdeModulePkg/DxeCore: Fixed Interface returned by CoreOpenProtocol X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 13:21:37 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 06/27/17 13:15, Laszlo Ersek wrote: > On 06/27/17 11:59, Zeng, Star wrote: >> Laszlo, >> >> I got the point and I like the idea of wrapper function personally. >> Although we can clean up the UEFI drivers in EDK2 tree, but it is really hard to evaluate the UEFI drivers in OPROM on add-on card. >> The patch did not just break OVMF, but also broke all real platforms we have in hand (it's my fault that I did not catch the failure when reviewing patch), the patch is so risky. > > Can we perhaps add a FeaturePCD (default value: FALSE) and rework Amit's > patch to consider the PCD? I really like the idea of being true to the > UEFI spec. > > In the edk2 tree we could rebase the affected drivers to the wrapper > function. And in OVMF (and in other in-tree emulation platforms), we > could set the FeaturePCD to TRUE. > > It is possible to use OVMF with assigned physical PCI devices, but > people can easily rebuild OVMF themselves, with the FeaturePCD re-set to > FALSE. Users can also quickly report the exact cards / oproms that break > with the FeaturePCD set to TRUE. > > > If you think it's simply not worth the effort, I'm OK with that, but > then we should specify this behavior in the UEFI spec -- we'll need a > Mantis bug for that. IMO it's not great that so many UEFI_DRIVERs in the > wild depend on behavior that is expressly forbidden by the UEFI spec at > the moment. If we can't modify all those drivers, then we should adapt > the spec, so that it reflects reality. > > I'm not going to suggest specific language for the UEFI spec right now. > But the wording could be based on the documentation of the wrapper > function that I'm working on now. I think I might post the patches just > for illustration. OK, I'm giving up. It is too hard to track down every single crash -- the register dump written by UefiCpuPkg's exception handler to the serial port is not much help, even though it names a module to look at. So I guess we have to accept that the dependency on EFI_ALREADY_STARTED setting Interface is just too wide-spread. :/ As I wrote above, I think this should be documented in the UEFI spec. I filed the following mantis ticket: Permit OpenProtocol() to output the supported protocol interface even on error https://mantis.uefi.org/mantis/view.php?id=1815 Thanks Laszlo