From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.61]) by mx.groups.io with SMTP id smtpd.web12.1898.1575628421965413768 for ; Fri, 06 Dec 2019 02:33:42 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=CwPQmrPm; spf=pass (domain: redhat.com, ip: 205.139.110.61, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1575628421; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=213zueEzpH24ouQ9iuQjNsSl7qb4O86Nch2NE8L7/fk=; b=CwPQmrPmg8Jg+gnYL16DZq4LAzDdyoXSETmqUd4uqpbRRIj0qxjyfmaQUECU9mHg13ZYGx oPzuil9n66ytLDi/zsZRjZ8slm+EANrPe6aPoGh/wWlDQ0EPwBn3WnPKu2WJOMBKkpu+te PPK4SAT9UMF9xxHHoJrdMQp+LDQT+J0= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-238-OIc0yajJMtO4kXBxe3kWZg-1; Fri, 06 Dec 2019 05:33:37 -0500 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B5FFD8005BA; Fri, 6 Dec 2019 10:33:35 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-235.ams2.redhat.com [10.36.116.235]) by smtp.corp.redhat.com (Postfix) with ESMTP id F179710016E8; Fri, 6 Dec 2019 10:33:33 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH v1 1/1] ArmPkg: Dispatch deferred images after EndOfDxe To: Ard Biesheuvel Cc: edk2-devel-groups-io , Sami Mujawar , Leif Lindholm , Matteo Carlini , nd References: <20190501140146.33224-1-sami.mujawar@arm.com> <2689eabf-b2a4-466b-d0cc-f8786e7a35ee@redhat.com> <65b6fbb9-200f-1a78-db72-f75ea65f5919@redhat.com> From: "Laszlo Ersek" Message-ID: Date: Fri, 6 Dec 2019 11:33:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-MC-Unique: OIc0yajJMtO4kXBxe3kWZg-1 X-Mimecast-Spam-Score: 0 Content-Language: en-US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 12/06/19 11:02, Ard Biesheuvel wrote: > On Fri, 6 Dec 2019 at 00:05, Laszlo Ersek wrote: >> >> On 12/06/19 00:54, Laszlo Ersek wrote: >>> On 12/05/19 21:25, Ard Biesheuvel wrote: >>>> On Wed, 1 May 2019 at 15:02, Sami Mujawar >>>> wrote: >> >>>> I'm still curious why this difference exists, >>> >>> What difference do you mean? >>> >>> (I can't see the original patch posting in my list folder, so I could >>> be missing parts of the discussion thus far.) >> >> Haha, I missed that Sami's email, which you just replied to, is dated "1 >> May 2019" -- that's the reason I couldn't find the original posting in >> my edk2-devel folder. That message has already been moved into one of my >> archive folders :) >> >> But, now I do see it, and I also see that your first question in >> response was spot-on: >> >> https://edk2.groups.io/g/devel/message/39901 >> >> (alternative link: >> >> http://mid.mail-archive.com/CAKv+Gu92gPzGvGZ3M9B52q1TOAvnBjgxpvykbAZPevMULkcF6w@mail.gmail.com >> ) >> >> Your question there had a small typo -- I think you meant, "It might be >> that the PCI hierarchy is enumerated *after* EndOfDxe on Juno, and >> *before* on the other platforms." >> >> And yes, that would explain the difference between Juno and {SynQuacer, >> Overdrive} very well -- i.e. why Juno was broken and the other platforms >> were OK. (Assuming in all cases, the 3rd party dispatch occurred after >> EndOfDxe, where it is supposed to.) >> > > Hi Laszlo, > > Thanks for chiming in. > > My question did not have a typo: if Juno enumerates PCI before > EndOfDxe, any option ROMs it encounters will not be dispatched and put > on the deferred list, which never gets processed. If it enumerates > after EndOfDxe, they just get dispatched immediately. Ugh, indeed! > That would > explain this behavior, *except* for the fact that these platforms use > the same PCI host bridge and bus drivers, the only difference is the > PciHostBridgeLib used. > > The difference is probably explained by the explicit > gBS->ConnectController () connecting the PCI root bridge that takes > place in ArmJunoDxe in an EndOfDxe handler, which seems to be there so > we can set the MAC address on the Marvell Yukon. Aha! That does seem to explain why this patch makes a difference. Because, signaling EndOfDxe leads *internally* to the production of some PciIo instances, and the deferral of the oprom images found on those. So there *are* some deferred images to dispatch, in platform BDS, right after signaling EndOfDxe (even before blanket-enumerating all (other) root bridges). So commit 0f9395d7c5cc looks justified, only its message may not tell the whole story. (I didn't realize oproms could be found and deferred *inside* signaling EndofDxe, and was looking at the blanket-enumeration that *followed* the proposed location of EfiBootManagerDispatchDeferredImages().) > We should probably > move that to a protocol registration notification callback on the > PciIo protocol, and remove the ConnectController altogether. I think this makes sense. It sounds like a platform tweak, so I agree that a PciIo notification callback is acceptable (a UEFI driver following the UEFI driver model doesn't seem to make any sense just for this one-shot platform tweak). > Concerning your analysis regarding the order of connecting the PCI > root bridge and signalling EndOfDxe: I agree the OvmfPkg order is > better, since it permits builtin drivers (which are 'trusted') to > attach to devices in the PCIe hierarchy before EndOfDxe is signalled, > which may be useful. Thanks -- but, ultimately, I do think my analysis, in the form I meant it, was flawed. I missed that, if the enumeration occurs after EndOfDxe, then the PCI oprom images will simply be dispatched at once! So, I have to change my mind now: I realize & accept that there is no immediate need to update the order of operations around signaling EndOfDxe, in the ArmVirtPkg and ArmPks PlatformBootManagerLib instances. In OvmfPkg, the order is stricter / more intricate , due to a chain of dependencies around S3 (FACS, boot script opcodes, SMRAM lockbox, locking down SMRAM etc). Thank you for the enlightenment! :) Laszlo