[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


 


Rackspace

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