On 02/14/15 21:03, Jordan Justen wrote:On 2015-02-14 08:38:37, Laszlo Ersek wrote:
On 02/12/15 21:53, Jordan Justen wrote:
I think gEfiPciEnumerationCompleteProtocolGuid should be installed by
MdeModulePkg/Bus/Pci/PciBusDxe, even when PcdPciDisableBusEnumeration
is set.
Ray's main feedback seemed to be that we need to make sure PciBusDxe
only installs the protocol once. (I'll also reply to the other related
patch thread.)
First, I now agree that this patch of mine should not go in, hence:
Self-NAK
Second, I tend to disagree that that
gEfiPciEnumerationCompleteProtocolGuid should be installed even if full
enumeration was eschewed. This might slightly change the de-facto
meaning of the protocol (because no resource allocation took place).
De-facto seems the correct term here, since the PI1.2 spec says very
little about the protocol.
My interpretation of the protocol is that it is a signal that the EFI
knows about the basic PCI topology, and has installed most PciIo
instances.
Maybe PcdPciDisableBusEnumeration wasn't the best name. Perhaps
PcdPciBusPreEnumerated would have been better.
At any rate, in the case of Xen, the hypervisor has pre-enumerated the
bus. PciBusDxe uses this and 'enumerates' PCI devices by simply
scanning the pre-enumerated topology.
So, I still think PciBusDxe should install
gEfiPciEnumerationCompleteProtocolGuid, because it still seems like it
acurately reflects the phase of the boot process.
Regarding the ACPI tables issue, would a callback for the ReadyToBoot
event work?
EFI_EVENT_GROUP_READY_TO_BOOT This event group is notified by the system when the Boot Manager is about to load and execute a boot option.(1) As far as I understand, if you boot a UEFI application, then exitit, and boot something else, then the event group will be signalled eachtime.We could use a static variable in AcpiPlatformDxe to avoid trying toinstall again and again, but it wouldn't be nice IMHO.
You can always use a global. This is the secondary reason I'm not enthusiastic about
EFI_EVENT_GROUP_READY_TO_BOOT. :)
(2) The main reason is different: in both OVMF and ArmVirtualizationQemu
we can boot a kernel directly, taken from QEMU. That happens without
EFI_EVENT_GROUP_READY_TO_BOOT being signalled.
However, the kernel booted thus should have both ACPI tables and
configured PCI devices (if there is a PCI host). In OVMF this is ensured by:
PlatformBdsPolicyBehavior()
PlatformBdsConnectSequence()
BdsLibConnectAll()
TryRunningQemuKernel()
where the BdsLibConnectAll() call listed above will cover the
enumeration, and trigger the dependent ACPI table installation as well,
before we go to the kernel.
One idea could be to signal EFI_EVENT_GROUP_READY_TO_BOOT ourselves,
That sounds like the right thing to do. before booting the kernel; however this event group seems quite tied to
the Boot Manager itself (see again its definition above).
The Boot Manager has a few responsibilities in EFI (and few more in PI where it is called the BDS), but in general it is a place where a lot of platform specific policy is enforced. So updating the Boot Manager do do the right thing sees like a good answer.
Thanks,
Andrew Fish
I'll post my patch series soon; my idea that is relevant for thisdiscussion is at its beginning (and a later patch also displays how Imean it to be used). We can discuss it there too if you like.ThanksLaszlo------------------------------------------------------------------------------Dive into the World of Parallel Programming. The Go Parallel Website,sponsored by Intel and developed in partnership with Slashdot Media, is yourhub for all things parallel software development, from weekly thoughtleadership blogs to news, videos, case studies, tutorials and more. Take alook and join the conversation now. http://goparallel.sourceforge.net/_______________________________________________edk2-devel mailing listedk2-devel@xxxxxxxxxxxxxxxxxxxxxhttps://lists.sourceforge.net/lists/listinfo/edk2-devel
|
