> On Feb 14, 2015, at 1:04 PM, Laszlo Ersek <ler...@redhat.com> wrote: > > 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 exit > it, and boot something else, then the event group will be signalled each > time. > > We could use a static variable in AcpiPlatformDxe to avoid trying to > install 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 this > discussion is at its beginning (and a later patch also displays how I > mean it to be used). We can discuss it there too if you like. > > Thanks > Laszlo > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming. The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net/ > <http://goparallel.sourceforge.net/> > _______________________________________________ > edk2-devel mailing list > edk2-de...@lists.sourceforge.net <mailto:edk2-de...@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/edk2-devel > <https://lists.sourceforge.net/lists/listinfo/edk2-devel>
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
