[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 Feb 14, 2015, at 1:04 PM, Laszlo Ersek <lersek@xxxxxxxxxx> 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:


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

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?


 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

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

(2) The main reason is different: in both OVMF and ArmVirtualizationQemu
we can boot a kernel directly, taken from QEMU. That happens without

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:


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.


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.


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/
edk2-devel mailing list

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.