From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Ni, Ruiyu" Subject: Re: [edk2] OVMF broken under Xen (in PCI initialisation) Date: Wed, 27 Apr 2016 07:18:21 +0000 Message-ID: <734D49CCEBEEF84792F5B80ED585239D0DA27F59__39875.3050751567$1461741586$gmane$org@SHSMSX103.ccr.corp.intel.com> References: <20160422144736.GD1885@perard.uk.xensource.com> <734D49CCEBEEF84792F5B80ED585239D0DA25884@SHSMSX103.ccr.corp.intel.com> <20160426073529.GC3109@GaryWorkstation> <734D49CCEBEEF84792F5B80ED585239D0DA25B98@SHSMSX103.ccr.corp.intel.com> <20160426084000.GD3109@GaryWorkstation> <734D49CCEBEEF84792F5B80ED585239D0DA25D38@SHSMSX103.ccr.corp.intel.com> <20160427042907.GH3109@GaryWorkstation> <734D49CCEBEEF84792F5B80ED585239D0DA27D1E@SHSMSX103.ccr.corp.intel.com> <20160427065428.GJ3109@GaryWorkstation> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2806949070895571990==" Return-path: In-Reply-To: <20160427065428.GJ3109@GaryWorkstation> Content-Language: en-US List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Gary Lin Cc: "edk2-devel@lists.01.org" , Xen Devel List-Id: xen-devel@lists.xenproject.org --===============2806949070895571990== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_734D49CCEBEEF84792F5B80ED585239D0DA27F59SHSMSX103ccrcor_" --_000_734D49CCEBEEF84792F5B80ED585239D0DA27F59SHSMSX103ccrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Gary, In PciEnumeratorLight(), please directly assign 0 to MinBus when Configuration() returns error, instead of calling PciGetBusRange() to extract MinBus from the descriptors returned from Configuration(). Regards, Ray >-----Original Message----- >From: Gary Lin [mailto:glin@suse.com] >Sent: Wednesday, April 27, 2016 2:54 PM >To: Ni, Ruiyu >Cc: edk2-devel@lists.01.org; Xen Devel >Subject: Re: [edk2] OVMF broken under Xen (in PCI initialisation) > >On Wed, Apr 27, 2016 at 05:39:40AM +0000, Ni, Ruiyu wrote: >> >> >> Regards, >> Ray >> >> >-----Original Message----- >> >From: Gary Lin [mailto:glin@suse.com] >> >Sent: Wednesday, April 27, 2016 12:29 PM >> >To: Ni, Ruiyu >> >Cc: edk2-devel@lists.01.org; Xen Devel >> >Subject: Re: [edk2] OVMF broken under Xen (in PCI initialisation) >> > >> >On Tue, Apr 26, 2016 at 09:40:42AM +0000, Ni, Ruiyu wrote: >> >> Gary, >> >> I can reproduce the issue and have debugged to get the reason. >> >> In MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c: >> >> PciEnumeratorLight() calls PciRootBridgeIo->Configuration() >> >> while the Configuration returns EFI_UNSUPPORTED resulting >> >> the PciBus driver exits earlier. >> >> You could try to manually set MinBus to 0 and MaxBus to 0xFF. >> >> >> >Do you mean to set MinBus and MaxBus in PciGetBusRange() ? >> >Should I also keep the EFI_UNSUPPORTED code in Configuration() ? >> Keep returning EFI_UNSUPPORTED in Configuration() and set >> MinBus/MaxBus in PciGetBusRange(). >> >> > >> >> The second change you need to make is in PciIo.c: >> >> Change GetMmioAddressTranslationOffset() to return 0 instead >> >> of -1 when error occurs >> >> >> > >> >Should I also remove "ASSERT (FALSE);" ? >> >> >> ASSERT() won't be hit. >> >It didn't work (see my attached patch) :( >BTW, if Configuration() already returns EFI_UNSUPPORTED, then there is >no way to invoke PciGetBusRange(). Besides, MaxBus was never used in >PciEnumeratorLight(), so it's meaningless to assign any value to it. > >Cheers, > >Gary Lin > >> > >> >Cheers, >> > >> >Gary Lin >> > >> >> With the above 2 changes, can you check whether the system can >> >> boot? >> >> >> >> If it can boot, then we need to think about what the proper fix is. >> >> For OVMF above Xen, the PCI resources are assigned by Xen other than >> >> PciBus driver. So PciRootBridgeIo->Configuration() doesn't know >> >> the resource assignment information. >> >> With old PciHostBridge driver, the Configuration() returns BUS resour= ce >> >> descriptor with MinBus =3D MaxBus =3D 0 (default value), so that the = PciBus >> >> driver can detect all devices in BUS 0, but I guess devices in BUS 1+= cannot >> >> be detected. >> >> >> >> Does Xen pass the resource assignment information through some memory >> >> blob to firmware? If yes, we could think about let PciHostBridgeLib p= ass that >> >> information to PciHostBridge driver. If no, we also could let PciHost= BridgeLib >> >> collect the information (IO/MEM/BUS resource assignment) and pass tha= t >> >> to PciHostBridgeDxe driver. >> >> >> >> And we need to have a way to tell PciHostBridgeDxe the resource infor= mation >> >> passed from PciHostBridgeLib is available resource to assign, or alre= ady allocated. >> >> Maybe just depends on the PcdPciBusDisableEnumeration. still thinking= . >> >> >> >> >> >> Regards, >> >> Ray >> >> >> >> >-----Original Message----- >> >> >From: Gary Lin [mailto:glin@suse.com] >> >> >Sent: Tuesday, April 26, 2016 4:40 PM >> >> >To: Ni, Ruiyu >> >> >Cc: edk2-devel@lists.01.org; Xen Devel >> >> >Subject: Re: [edk2] OVMF broken under Xen (in PCI initialisation) >> >> > >> >> >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 initializ= ed 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@suse.com] >> >> >> Sent: Tuesday, April 26, 2016 3:35 PM >> >> >> To: Ni, Ruiyu >> >> >> Cc: Anthony PERARD ; edk2-devel@lists.0= 1.org; Xen Devel >> >> >> 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@lists.01.org] On Be= half 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=3DTRUE. >> >> >> > > >> >> >> > >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/Xe= n.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 !=3D ((void *) 0) >> >> >> > > >> >> >> > >I have worked around this one with the following patch. That wo= uld >> >> >> > >correspond to how the former implementation in OvmfPkg was init= ializing the >> >> >> > >struct. Maybe a better way would be to fill ResAllocated under = Xen, >> >> >> > >somehow. Under Xen, the ResAllocNode status is not allocated, s= o no >> >> >> > >Descriptor are created. >> >> >> > > >> >> >> > >diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridg= eIo.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 =3D &RootBridge->ResAllocNode[Index]; >> >> >> > > >> >> >> > >- if (ResAllocNode->Status !=3D ResAllocated) { >> >> >> > >- continue; >> >> >> > >- } >> >> >> > >- >> >> >> > > Descriptor->Desc =3D ACPI_ADDRESS_SPACE_DESCRIPTOR; >> >> >> > > Descriptor->Len =3D sizeof (EFI_ACPI_ADDRESS_SPACE_DESCRI= PTOR) - 3; >> >> >> > >+ if (ResAllocNode->Status !=3D ResAllocated) { >> >> >> > > Descriptor->AddrRangeMin =3D ResAllocNode->Base; >> >> >> > > Descriptor->AddrRangeMax =3D ResAllocNode->Base + ResAllo= cNode->Length - 1; >> >> >> > > Descriptor->AddrLen =3D ResAllocNode->Length; >> >> >> > >+ } >> >> >> > > switch (ResAllocNode->Type) { >> >> >> > > >> >> >> > I think a more proper fix is to return EFI_UNSUPPORTED without r= eturning 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 t= rue. >> >> >> > >> >> >> > > >> >> >> > >That leads to one last assert: >> >> >> > >> QemuVideo: Cirrus 5446 detected >> >> >> > >> InstallProtocolInterface: 09576E91-6D3F-11D2-8E39-00A0C969723= B 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/PciBu= sDxe/PciIo.c(1789): ((BOOLEAN)(0=3D=3D1)) >> >> >> > >For this one, I've workaround by reverting patch 7b0a1ea >> >> >> > >(MdeModuelPkg/PciBus: Return AddrTranslationOffset in GetBarAtt= ributes). >> >> >> > >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 sy= stem >> >> >> stuck somewhere after loading shell.efi. Here are the messages fro= m the >> >> >> debug log: >> >> >> >> >> >> BdsLibConnectAll >> >> >> Select Item: 0xE >> >> >> Memory Previous Current Next >> >> >> Type Pages Pages Pages >> >> >> =3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D= =3D=3D =3D=3D=3D=3D=3D=3D=3D=3D >> >> >> 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 3EA= 580C0 >> >> >> Loading driver at 0x0003E03F000 EntryPoint=3D0x0003E03F240 Shell.e= fi >> >> >> InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 3EA= 58B98 >> >> >> InstallProtocolInterface: 387477C2-69C7-11D2-8E39-00A0C969723B 3EA= 54320 >> >> >> InstallProtocolInterface: 752F3136-4E16-4FDC-A22A-E5F46812F4CA 3EA= 53CD8 >> >> >> InstallProtocolInterface: 6302D008-7F9B-4F30-87AC-60C9FEF5DA4E 3E1= 6B580 >> >> >> >> >> >> 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@lists.01.org >> >> >> https://lists.01.org/mailman/listinfo/edk2-devel >> >> >> >> >> _______________________________________________ >> >> edk2-devel mailing list >> >> edk2-devel@lists.01.org >> >> https://lists.01.org/mailman/listinfo/edk2-devel >> >> >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel >> --_000_734D49CCEBEEF84792F5B80ED585239D0DA27F59SHSMSX103ccrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Gary,
In PciEnumeratorLight(), please = directly assign 0 to MinBus when
Configuration() returns error, instea= d of calling PciGetBusRange() to

extract MinBus from the = descriptors returned from Configuration().

Regards,
Ray

>-----Original Message-----
>From: Gary Lin [mailto:glin= @suse.com]
>Sent: Wednesday, April 27,&= nbsp;2016 2:54 PM
>To: Ni, Ruiyu <ruiyu.ni@= intel.com>
>Cc: edk2-devel@lists.01.org; Xen=  Devel <xen-devel@lists.xen.org>
>Subject: Re: [edk2] OVMF&nb= sp;broken under Xen (in PCI initialisation)=
>
>On Wed, Apr 27, 2016&nbs= p;at 05:39:40AM +0000, Ni, Ruiyu wrote:=
>>
>>
>> Regards,
>> Ray
>>
>> >-----Original Message---= --
>> >From: Gary Lin = ;[mailto:glin@suse.com]
>> >Sent: Wednesday, Ap= ril 27, 2016 12:29 PM
>> >To: Ni, Ruiyu = <ruiyu.ni@intel.com>
>> >Cc: edk2-devel@lists.01.= org; Xen Devel <xen-devel@lists.xen.org>
>> >Subject: Re: [edk2]=  OVMF broken under Xen (in PCI initialis= ation)
>> >
>> >On Tue, Apr 26= , 2016 at 09:40:42AM +0000, Ni, Ruiyu&nbs= p;wrote:
>> >> Gary,
>> >> I can rep= roduce the issue and have debugged to ge= t the reason.
>> >> In MdeModulePk= g/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c:
>> >> PciEnumeratorLight(= ) calls PciRootBridgeIo->Configuration()
>> >> while the = ;Configuration returns EFI_UNSUPPORTED resulting
>> >> the PciBus&nbs= p;driver exits earlier.
>> >> You could = ;try to manually set MinBus to 0 and&nbs= p;MaxBus to 0xFF.
>> >>
>> >Do you mean to=  set MinBus and MaxBus in PciGetBusRange()&nb= sp;?
>> >Should I also = keep the EFI_UNSUPPORTED code in Configuration()&n= bsp;?
>> Keep returning EFI_UNSUP= PORTED in Configuration() and set
>> MinBus/MaxBus in PciGetB= usRange().
>>
>> >
>> >> The second&nbs= p;change you need to make is in PciIo.c:=
>> >> Change GetMmio= AddressTranslationOffset() to return 0 instead >> >> of -1 whe= n error occurs
>> >>
>> >
>> >Should I also = remove "ASSERT (FALSE);" ?
>>
>>
>> ASSERT() won't be h= it.
>>
>It didn't work (see my=  attached patch) :(
>BTW, if Configuration() alr= eady returns EFI_UNSUPPORTED, then there is=
>no way to invoke PciGe= tBusRange(). Besides, MaxBus was never used i= n
>PciEnumeratorLight(), so it's&nb= sp;meaningless to assign any value to it.
>
>Cheers,
>
>Gary Lin
>
>> >
>> >Cheers,
>> >
>> >Gary Lin
>> >
>> >> With the = above 2 changes, can you check whether t= he system can
>> >> boot?
>> >>
>> >> If it can=  boot, then we need to think about = what the proper fix is.
>> >> For OVMF = above Xen, the PCI resources are assigned&nbs= p;by Xen other than
>> >> PciBus driver.=  So PciRootBridgeIo->Configuration() doesn't know
>> >> the resource&n= bsp;assignment information.
>> >> With old = PciHostBridge driver, the Configuration() returns = BUS resource
>> >> descriptor wit= h MinBus =3D MaxBus =3D 0 (default value= ), so that the PciBus
>> >> driver can&nbs= p;detect all devices in BUS 0, but I&nbs= p;guess devices in BUS 1+ cannot
>> >> be detected.
>> >>
>> >> Does Xen = pass the resource assignment information through&n= bsp;some memory
>> >> blob to f= irmware? If yes, we could think about le= t PciHostBridgeLib pass that
>> >> information to=  PciHostBridge driver. If no, we also co= uld let PciHostBridgeLib
>> >> collect the&nb= sp;information (IO/MEM/BUS resource assignment) and&nbs= p;pass that
>> >> to PciHostBrid= geDxe driver.
>> >>
>> >> And we ne= ed to have a way to tell PciHostBridgeDx= e the resource information
>> >> passed from&nb= sp;PciHostBridgeLib is available resource to assig= n, or already allocated.
>> >> Maybe just&nbs= p;depends on the PcdPciBusDisableEnumeration. still&nbs= p;thinking.
>> >>
>> >>
>> >> Regards,
>> >> Ray
>> >>
>> >> >-----Original&n= bsp;Message-----
>> >> >From: Gary=  Lin [mailto:glin@suse.com]
>> >> >Sent: Tues= day, April 26, 2016 4:40 PM
>> >> >To: Ni,&nb= sp;Ruiyu <ruiyu.ni@intel.com>
>> >> >Cc: edk2-d= evel@lists.01.org; Xen Devel <xen-devel@lists.xen.org>=
>> >> >Subject: R= e: [edk2] OVMF broken under Xen (in PCI&= nbsp;initialisation)
>> >> >
>> >> >On Tue,&nb= sp;Apr 26, 2016 at 08:19:49AM +0000, Ni,&= nbsp;Ruiyu wrote:
>> >> >> Gary,=
>> >> >> Maybe=  the system boots to Shell well but = ;the video isn't initialized properly.
>> >> >> Can&n= bsp;you build the firmware using "-D DEB= UG_ON_SERIAL_PORT" switch and
>> >> >> give&= nbsp;me the boot log?
>> >> >>
>> >> >Hi Ray,
>> >> >
>> >> >I already&= nbsp;did and it's how I make the firmwar= e spit the log :-(
>> >> >
>> >> >Thanks,<= br> >> >> >
>> >> >Gary Lin
>> >> >
>> >> >> Regar= ds,
>> >> >> Ray
>> >> >>
>> >> >> From:=  Gary Lin [mailto:glin@suse.com]
>> >> >> Sent:=  Tuesday, April 26, 2016 3:35 PM
>> >> >> To:&n= bsp;Ni, Ruiyu <ruiyu.ni@intel.com>
>> >> >> Cc:&n= bsp;Anthony PERARD <anthony.perard@citrix.com>; edk2-d= evel@lists.01.org; Xen Devel <xen-devel@lists.xen.org>=
>> >> >> Subje= ct: Re: [edk2] OVMF broken under Xen (in=  PCI initialisation)
>> >> >>
>> >> >> On&nb= sp;Tue, Apr 26, 2016 at 06:43:56AM +0000,=  Ni, Ruiyu wrote:
>> >> >> ><= /span>
>> >> >> ><= /span>
>> >> >> >&= nbsp;Regards,
>> >> >> >&= nbsp;Ray
>> >> >> ><= /span>
>> >> >> >&= nbsp;>-----Original Message-----
>> >> >> >&= nbsp;>From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org= ] On Behalf Of Anthony PERARD
>> >> >> >&= nbsp;>Sent: Friday, April 22, 2016 10:48 P= M
>> >> >> >&= nbsp;>To: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org= >
>> >> >> >&= nbsp;>Cc: Xen Devel <xen-devel@lists.xen.org<mailto= :xen-devel@lists.xen.org>>
>> >> >> >&= nbsp;>Subject: [edk2] OVMF broken under Xen&nbs= p;(in PCI initialisation)
>> >> >> >&= nbsp;>
>> >> >> >&= nbsp;>Hi,
>> >> >> >&= nbsp;>
>> >> >> >&= nbsp;>Following the switch to MdeModulePkg/Bus/Pci/P= ciHostBridgeDxe, the pci root
>> >> >> >&= nbsp;>bridge does not finish to initialize = ;and breaks under Xen.
>> >> >> >&= nbsp;>
>> >> >> >&= nbsp;>There are several issue probably due = ;to the use of
>> >> >> >&= nbsp;>PcdPciDisableBusEnumeration=3DTRUE.
>> >> >> >&= nbsp;>
>> >> >> >&= nbsp;>First one:
>> >> >> >&= nbsp;>ASSERT MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.= c(99): Bridge->Mem.Limit <
>> >> >0x0000000100000= 000ULL
>> >> >> >&= nbsp;>
>> >> >> >&= nbsp;>This patch would fix the first asser= t:
>> >> >> >&= nbsp;>diff --git a/OvmfPkg/PlatformPei/Xen.c b/OvmfPkg/Pl= atformPei/Xen.c
>> >> >> >&= nbsp;>index 7fa9019..15ec7a7 100644
>> >> >> >&= nbsp;>--- a/OvmfPkg/PlatformPei/Xen.c
>> >> >> >&= nbsp;>+++ b/OvmfPkg/PlatformPei/Xen.c
>> >> >> >&= nbsp;>@@ -227,5 +227,11 @@ InitializeXen (<= /span>
>> >> >> >&= nbsp;>
>> >> >> >&= nbsp;>   PcdSetBool (PcdPciDisableBusEnumeration,&nb= sp;TRUE);
>> >> >> >&= nbsp;>
>> >> >> >&= nbsp;>+  // Values from hvmloader >> >> >> >&= nbsp;>+#define PCI_MEM_END      &= nbsp;  0xFC000000
>> >> >> >&= nbsp;>+#define HVM_BELOW_4G_MMIO_START 0xF0000000 >> >> >> >&= nbsp;>+  PcdSet64 (PcdPciMmio32Base, HVM_BELOW_4= G_MMIO_START);
>> >> >> >&= nbsp;>+  PcdSet64 (PcdPciMmio32Size, PCI_MEM_END=  - HVM_BELOW_4G_MMIO_START);
>> >> >> >&= nbsp;>+
>> >> >> >&= nbsp;>   return EFI_SUCCESS;
>> >> >> >&= nbsp;> }
>> >> >> >&= nbsp;>
>> >> >> >&= nbsp;>
>> >> >> >&= nbsp;>But that not enough, next assert is:=
>> >> >> >&= nbsp;>ASSERT MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c(807)= : RootBridge !=3D ((void *) 0)
>> >> >> >&= nbsp;>
>> >> >> >&= nbsp;>I have worked around this one with&n= bsp;the following patch. That would
>> >> >> >&= nbsp;>correspond to how the former implementati= on in OvmfPkg was initializing the
>> >> >> >&= nbsp;>struct. Maybe a better way would be&= nbsp;to fill ResAllocated under Xen,
>> >> >> >&= nbsp;>somehow. Under Xen, the ResAllocNode stat= us is not allocated, so no
>> >> >> >&= nbsp;>Descriptor are created.
>> >> >> >&= nbsp;>
>> >> >> >&= nbsp;>diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRo= otBridgeIo.c
>> >> >> >&= nbsp;>b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c >> >> >> >&= nbsp;>index cda9b49..eda92b6 100644
>> >> >> >&= nbsp;>--- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c=
>> >> >> >&= nbsp;>+++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRo= otBridgeIo.c
>> >> >> >&= nbsp;>@@ -1509,15 +1509,13 @@ RootBridgeIoConfig= uration (
>> >> >> >&= nbsp;>
>> >> >> >&= nbsp;>     ResAllocNode =3D &Root= Bridge->ResAllocNode[Index];
>> >> >> >&= nbsp;>
>> >> >> >&= nbsp;>-    if (ResAllocNode->Status != =3D ResAllocated) {
>> >> >> >&= nbsp;>-      continue;
>> >> >> >&= nbsp;>-    }
>> >> >> >&= nbsp;>-
>> >> >> >&= nbsp;>     Descriptor->Desc =3D AC= PI_ADDRESS_SPACE_DESCRIPTOR;
>> >> >> >&= nbsp;>     Descriptor->Len  =3D&nb= sp;sizeof (EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR) - 3; >> >> >> >&= nbsp;>+    if (ResAllocNode->Status = ;!=3D ResAllocated) {
>> >> >> >&= nbsp;>     Descriptor->AddrRangeMin &nb= sp;=3D ResAllocNode->Base;
>> >> >> >&= nbsp;>     Descriptor->AddrRangeMax &nb= sp;=3D ResAllocNode->Base + ResAllocNode->Length&n= bsp;- 1;
>> >> >> >&= nbsp;>     Descriptor->AddrLen  &n= bsp;    =3D ResAllocNode->Length;
>> >> >> >&= nbsp;>+    }
>> >> >> >&= nbsp;>     switch (ResAllocNode->Type)&= nbsp;{
>> >> >> >&= nbsp;>
>> >> >> >&= nbsp;I think a more proper fix is to&nbs= p;return EFI_UNSUPPORTED without returning any >> >> >> >&= nbsp;descriptors when the PcdPciDisableBusEnumeration i= s TRUE.
>> >> >> >&= nbsp;Per UEFI Spec, EFI_UNSUPPORTED means "Th= e current configuration of this PCI
>> >> >> >&= nbsp;root bridge could not be retrieved."&nbs= p;It's true when the PCD is true.
>> >> >> ><= /span>
>> >> >> >&= nbsp;>
>> >> >> >&= nbsp;>That leads to one last assert:
>> >> >> >&= nbsp;>> QemuVideo: Cirrus 5446 detected >> >> >> >&= nbsp;>> InstallProtocolInterface: 09576E91-6D3F-11D2-8E39-0= 0A0C969723B 7B9EF598
>> >> >> >&= nbsp;>> Adding Mode 0 as Cirrus Interna= l Mode 0: 640x480, 32-bit, 60 Hz
>> >> >> >&= nbsp;>> Adding Mode 1 as Cirrus Interna= l Mode 1: 800x600, 32-bit, 60 Hz
>> >> >> >&= nbsp;>> Adding Mode 2 as Cirrus Interna= l Mode 2: 1024x768, 24-bit, 60 Hz
>> >> >> >&= nbsp;>> PixelBlueGreenRedReserved8BitPerColor
>> >> >> >&= nbsp;>> ASSERT /local/home/sheep/work/ovmf/MdeModulePkg/Bus= /Pci/PciBusDxe/PciIo.c(1789): ((BOOLEAN)(0=3D=3D1))
>> >> >> >&= nbsp;>For this one, I've workaround by rev= erting patch 7b0a1ea
>> >> >> >&= nbsp;>(MdeModuelPkg/PciBus: Return AddrTranslationOffset = in GetBarAttributes).
>> >> >> >&= nbsp;>That issue was introduce while still = ;using the USE_OLD_PCI_HOST.
>> >> >> >&= nbsp;>
>> >> >> >&= nbsp;>Any idee or pointer on how to f= ix those issues ?
>> >> >> ><= /span>
>> >> >> >&= nbsp;When the PciRootBridgeIo.Configuration() returns E= FI_UNSUPPORTED, this assertion
>> >> >> >&= nbsp;can be fixed as well. Correct?
>> >> >>
>> >> >> I&nbs= p;tried to make RootBridgeIoConfiguration() return = ;EFI_UNSUPPORTED
>> >> >> (see&= nbsp;the attachment), and those asserts were = gone. However, the system
>> >> >> stuck=  somewhere after loading shell.efi. Here are&= nbsp;the messages from the
>> >> >> debug=  log:
>> >> >>
>> >> >> BdsLi= bConnectAll
>> >> >> Selec= t Item: 0xE
>> >> >> Memor= y  Previous  Current    Next=
>> >> >>  = ;Type    Pages     Pages =     Pages
>> >> >> =3D= =3D=3D=3D=3D=3D  =3D=3D=3D=3D=3D=3D=3D=3D  =3D=3D=3D=3D= =3D=3D=3D=3D  =3D=3D=3D=3D=3D=3D=3D=3D
>> >> >>  = ; 0A    00000004  00000001  00= 000004
>> >> >>  = ; 09    00000008  00000011  00= 000015
>> >> >>  = ; 00    00000004  00000001  00= 000004
>> >> >>  = ; 06    00000024  00000057  00= 00006C
>> >> >>  = ; 05    00000030  00000063  00= 00007B
>> >> >>  = ; 03    00000180  0000048D  00= 0005B0
>> >> >>  = ; 04    00000F00  00000B65  00= 000F00
>> >> >> Booti= ng EFI Internal Shell
>> >> >> Insta= llProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 3EA580C= 0
>> >> >> Loadi= ng driver at 0x0003E03F000 EntryPoint=3D0x0003E03F240&n= bsp;Shell.efi
>> >> >> Insta= llProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 3EA58B9= 8
>> >> >> Insta= llProtocolInterface: 387477C2-69C7-11D2-8E39-00A0C969723B 3EA5432= 0
>> >> >> Insta= llProtocolInterface: 752F3136-4E16-4FDC-A22A-E5F46812F4CA 3EA53CD= 8
>> >> >> Insta= llProtocolInterface: 6302D008-7F9B-4F30-87AC-60C9FEF5DA4E 3E16B58= 0
>> >> >>
>> >> >> I&nbs= p;couldn't find out where it stuck unless&nbs= p;there is a way to attach gdb
>> >> >> to&nb= sp;Xen HVM for source level debugging :-(
>> >> >>
>> >> >> Thank= s,
>> >> >>
>> >> >> Gary&= nbsp;Lin
>> >> >> _____= __________________________________________
>> >> >> edk2-= devel mailing list
>> >> >> edk2-= devel@lists.01.org
>> >> >> https= ://lists.01.org/mailman/listinfo/edk2-devel
>> >> >>
>> >> ___________________= ____________________________
>> >> edk2-devel mai= ling list
>> >> edk2-devel@lists.01= .org
>> >> https://lists.01.or= g/mailman/listinfo/edk2-devel
>> >>
>> __________________________________= _____________
>> edk2-devel mailing list<= /span>
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listi= nfo/edk2-devel
>>

--_000_734D49CCEBEEF84792F5B80ED585239D0DA27F59SHSMSX103ccrcor_-- --===============2806949070895571990== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y Zy94ZW4tZGV2ZWwK --===============2806949070895571990==--