Gary,
thanks for providing the quick fix. How about directly return
EFI_UNSUPPORTED when the PcdPciDisableEnumeration is TRUE?
See my another mail reply to this thread.
Regards,
Ray
>-----Original Message-----
>From: edk2-devel [mailto:edk2-devel-bounces@xxxxxxxxxxxx] On Behalf Of Gary Lin
>Sent: Tuesday, April 26, 2016 2:29 PM
>To: Anthony PERARD <anthony.perard@xxxxxxxxxx>; Ni, Ruiyu <ruiyu.ni@xxxxxxxxx>
>Cc: edk2-devel@xxxxxxxxxxx; Laszlo Ersek <lersek@xxxxxxxxxx>; Xen Devel <xen-devel@xxxxxxxxxxxxx>
>Subject: Re: [edk2] OVMF broken under Xen (in PCI initialisation)
>
>On Mon, Apr 25, 2016 at 01:43:01PM +0200, Laszlo Ersek wrote:
>> On 04/22/16 16:47, Anthony PERARD wrote:
>> > Hi,
>> >
>> > Following the switch to MdeModulePkg/Bus/Pci/PciHostBridgeDxe, the pci root
>> > bridge does not finish to initialize and breaks under Xen.
>>
>> (Adding Ray Ni)
>>
>> > There are several issue probably due to the use of
>> > PcdPciDisableBusEnumeration=TRUE.
>> >
>> > First one:
>> > ASSERT MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c(99): Bridge->Mem.Limit <
>0x0000000100000000ULL
>> >
>> > This patch would fix the first assert:
>> > diff --git a/OvmfPkg/PlatformPei/Xen.c b/OvmfPkg/PlatformPei/Xen.c
>> > index 7fa9019..15ec7a7 100644
>> > --- a/OvmfPkg/PlatformPei/Xen.c
>> > +++ b/OvmfPkg/PlatformPei/Xen.c
>> > @@ -227,5 +227,11 @@ InitializeXen (
>> >
>> > PcdSetBool (PcdPciDisableBusEnumeration, TRUE);
>> >
>> > + // Values from hvmloader
>> > +#define PCI_MEM_END 0xFC000000
>> > +#define HVM_BELOW_4G_MMIO_START 0xF0000000
>> > + PcdSet64 (PcdPciMmio32Base, HVM_BELOW_4G_MMIO_START);
>> > + PcdSet64 (PcdPciMmio32Size, PCI_MEM_END - HVM_BELOW_4G_MMIO_START);
>> > +
>> > return EFI_SUCCESS;
>> > }
>>
>> For this, I am to blame; sorry about the regression. Can you please
>> submit the change as a standalone patch, and mention commit
>> 03845e90cc432 as the one that missed it?
>>
>> Also, can you please add the macros to "OvmfPkg/PlatformPei/Xen.h"
>> instead, near OVMF_INFO_PHYSICAL_ADDRESS?
>>
>> >
>> >
>> > But that not enough, next assert is:
>> > ASSERT MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c(807): RootBridge != ((void *) 0)
>> >
>> > I have worked around this one with the following patch. That would
>> > correspond to how the former implementation in OvmfPkg was initializing the
>> > struct. Maybe a better way would be to fill ResAllocated under Xen,
>> > somehow. Under Xen, the ResAllocNode status is not allocated, so no
>> > Descriptor are created.
>> >
>> > diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
>b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
>> > index cda9b49..eda92b6 100644
>> > --- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
>> > +++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
>> > @@ -1509,15 +1509,13 @@ RootBridgeIoConfiguration (
>> >
>> > ResAllocNode = &RootBridge->ResAllocNode[Index];
>> >
>> > - if (ResAllocNode->Status != ResAllocated) {
>> > - continue;
>> > - }
>> > -
>> > Descriptor->Desc = ACPI_ADDRESS_SPACE_DESCRIPTOR;
>> > Descriptor->Len = sizeof (EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR) - 3;
>> > + if (ResAllocNode->Status != ResAllocated) {
>> > Descriptor->AddrRangeMin = ResAllocNode->Base;
>> > Descriptor->AddrRangeMax = ResAllocNode->Base + ResAllocNode->Length - 1;
>> > Descriptor->AddrLen = ResAllocNode->Length;
>> > + }
>> > switch (ResAllocNode->Type) {
>> >
>> >
>> > That leads to one last assert:
>> >> QemuVideo: Cirrus 5446 detected
>> >> InstallProtocolInterface: 09576E91-6D3F-11D2-8E39-00A0C969723B 7B9EF598
>> >> Adding Mode 0 as Cirrus Internal Mode 0: 640x480, 32-bit, 60 Hz
>> >> Adding Mode 1 as Cirrus Internal Mode 1: 800x600, 32-bit, 60 Hz
>> >> Adding Mode 2 as Cirrus Internal Mode 2: 1024x768, 24-bit, 60 Hz
>> >> PixelBlueGreenRedReserved8BitPerColor
>> >> ASSERT /local/home/sheep/work/ovmf/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c(1789): ((BOOLEAN)(0==1))
>> > For this one, I've workaround by reverting patch 7b0a1ea
>> > (MdeModuelPkg/PciBus: Return AddrTranslationOffset in GetBarAttributes).
>> > That issue was introduce while still using the USE_OLD_PCI_HOST.
>> >
>> > Any idee or pointer on how to fix those issues ?
>>
>> I think your suggestion that PcdPciDisableBusEnumeration=TRUE causes
>> these problems is likely correct. Both of the above issues seem to
>> originate from PciHostBridgeDxe's assumption that resources have been
>> allocated (i.e., there has been an enumeration).
>>
>> Please discuss these questions with Ray -- I guess PciHostBridgeDxe may
>> not have received a lot of testing with
>> PcdPciDisableBusEnumeration=TRUE. I can imagine that simply considering
>> PcdPciDisableBusEnumeration, and acting conditionally upon its value,
>> might solve these problems.
>>
>I made a quick fix to skip those checks when PcdPciDisableBusEnumeration
>is TRUE. Plus the fix for OvmfPkg/PlatformPei/Xen.c, I can now boot to
>the UEFI shell.
>
>Ray,
>
>Do you think this is the right way to fix it?
>
>Thanks,
>
>Gary Lin
