Re: [Xen-devel] [edk2] OVMF broken under Xen (in PCI initialisation)

[Gary Lin <glin@xxxxxxxx>]

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:glin@xxxxxxxx]
> Sent: Tuesday, April 26, 2016 3:35 PM
> To: Ni, Ruiyu <ruiyu.ni@xxxxxxxxx>
> Cc: Anthony PERARD <anthony.perard@xxxxxxxxxx>; edk2-devel@xxxxxxxxxxxx; Xen 
> Devel <xen-devel@xxxxxxxxxxxxx>
> 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-bounces@xxxxxxxxxxxx] On Behalf Of 
> > >Anthony PERARD
> > >Sent: Friday, April 22, 2016 10:48 PM
> > >To: edk2-devel@xxxxxxxxxxxx<mailto:edk2-devel@xxxxxxxxxxxx>
> > >Cc: Xen Devel <xen-devel@xxxxxxxxxxxxx<mailto:xen-devel@xxxxxxxxxxxxx>>
> > >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-devel@xxxxxxxxxxxx
> https://lists.01.org/mailman/listinfo/edk2-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel