On Tue, Apr 26, 2016 at 08:19:49AM +0000, Ni, Ruiyu wrote: > Gary, > Maybe the system boots to Shell well but the video isn't initialized properly. > Can you build the firmware using "-D DEBUG_ON_SERIAL_PORT" switch and > give me the boot log? > Hi Ray,
I already did and it's how I make the firmware spit the log :-( Thanks, Gary Lin > Regards, > Ray > > From: Gary Lin [mailto:g...@suse.com] > Sent: Tuesday, April 26, 2016 3:35 PM > To: Ni, Ruiyu <ruiyu...@intel.com> > Cc: Anthony PERARD <anthony.per...@citrix.com>; edk2-de...@lists.01.org; Xen > Devel <xen-devel@lists.xen.org> > Subject: Re: [edk2] OVMF broken under Xen (in PCI initialisation) > > On Tue, Apr 26, 2016 at 06:43:56AM +0000, Ni, Ruiyu wrote: > > > > > > Regards, > > Ray > > > > >-----Original Message----- > > >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > > >Anthony PERARD > > >Sent: Friday, April 22, 2016 10:48 PM > > >To: edk2-de...@lists.01.org<mailto:edk2-de...@lists.01.org> > > >Cc: Xen Devel <xen-devel@lists.xen.org<mailto:xen-devel@lists.xen.org>> > > >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 > _______________________________________________ > edk2-devel mailing list > edk2-de...@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel