On Tue, Apr 26, 2016 at 06:43:56AM +0000, Ni, Ruiyu wrote: > > > Regards, > Ray > > >-----Original Message----- > >From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Anthony PERARD > >Sent: Friday, April 22, 2016 10:48 PM > >To: edk2-devel@lists.01.org > >Cc: Xen Devel > >Subject: [edk2] OVMF broken under Xen (in PCI initialisation) > > > >Hi, > > > >Following the switch to MdeModulePkg/Bus/Pci/PciHostBridgeDxe, the pci root > >bridge does not finish to initialize and breaks under Xen. > > > >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; > > } > > > > > >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) { > > > I think a more proper fix is to return EFI_UNSUPPORTED without returning any > descriptors when the PcdPciDisableBusEnumeration is TRUE. > Per UEFI Spec, EFI_UNSUPPORTED means "The current configuration of this PCI > root bridge could not be retrieved." It's true when the PCD is true. > > > > >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 ? > > When the PciRootBridgeIo.Configuration() returns EFI_UNSUPPORTED, this assertion > can be fixed as well. Correct? I tried to make RootBridgeIoConfiguration() return EFI_UNSUPPORTED (see the attachment), and those asserts were gone. However, the system stuck somewhere after loading shell.efi. Here are the messages from the debug log: BdsLibConnectAll Select Item: 0xE Memory Previous Current Next Type Pages Pages Pages ====== ======== ======== ======== 0A 00000004 00000001 00000004 09 00000008 00000011 00000015 00 00000004 00000001 00000004 06 00000024 00000057 0000006C 05 00000030 00000063 0000007B 03 00000180 0000048D 000005B0 04 00000F00 00000B65 00000F00 Booting EFI Internal Shell InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 3EA580C0 Loading driver at 0x0003E03F000 EntryPoint=0x0003E03F240 Shell.efi InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 3EA58B98 InstallProtocolInterface: 387477C2-69C7-11D2-8E39-00A0C969723B 3EA54320 InstallProtocolInterface: 752F3136-4E16-4FDC-A22A-E5F46812F4CA 3EA53CD8 InstallProtocolInterface: 6302D008-7F9B-4F30-87AC-60C9FEF5DA4E 3E16B580 I couldn't find out where it stuck unless there is a way to attach gdb to Xen HVM for source level debugging :-( Thanks, Gary Lin