[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [edk2] [PATCH] OvmfPkg: AcpiPlatformDxe: PCI enumeration may be disabled
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. 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, before booting the kernel; however this event group seems quite tied to the Boot Manager itself (see again its definition above). 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |