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

[Gary Lin <glin@xxxxxxxx>]

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
> >Cc: Xen Devel <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

Attachment: ovmf-return-unsupported.patch
Description: Text Data

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