* Re: [edk2] OVMF broken under Xen (in PCI initialisation) [not found] <20160422144736.GD1885@perard.uk.xensource.com> @ 2016-04-25 11:43 ` Laszlo Ersek [not found] ` <571E02C5.1000906@redhat.com> ` (2 subsequent siblings) 3 siblings, 0 replies; 25+ messages in thread From: Laszlo Ersek @ 2016-04-25 11:43 UTC (permalink / raw) To: Anthony PERARD; +Cc: Ni, Ruiyu, edk2-devel, Xen Devel On 04/22/16 16:47, Anthony PERARD wrote: > Hi, > > Following the switch to MdeModulePkg/Bus/Pci/PciHostBridgeDxe, the pci root > bridge does not finish to initialize and breaks under Xen. (Adding Ray Ni) > 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; > } For this, I am to blame; sorry about the regression. Can you please submit the change as a standalone patch, and mention commit 03845e90cc432 as the one that missed it? Also, can you please add the macros to "OvmfPkg/PlatformPei/Xen.h" instead, near OVMF_INFO_PHYSICAL_ADDRESS? > > > 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) { > > > 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 ? I think your suggestion that PcdPciDisableBusEnumeration=TRUE causes these problems is likely correct. Both of the above issues seem to originate from PciHostBridgeDxe's assumption that resources have been allocated (i.e., there has been an enumeration). Please discuss these questions with Ray -- I guess PciHostBridgeDxe may not have received a lot of testing with PcdPciDisableBusEnumeration=TRUE. I can imagine that simply considering PcdPciDisableBusEnumeration, and acting conditionally upon its value, might solve these problems. Thanks! Laszlo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <571E02C5.1000906@redhat.com>]
* Re: [edk2] OVMF broken under Xen (in PCI initialisation) [not found] ` <571E02C5.1000906@redhat.com> @ 2016-04-26 6:29 ` Gary Lin [not found] ` <20160426062914.GB3109@GaryWorkstation> 1 sibling, 0 replies; 25+ messages in thread From: Gary Lin @ 2016-04-26 6:29 UTC (permalink / raw) To: Anthony PERARD, Ni, Ruiyu; +Cc: edk2-devel, Laszlo Ersek, Xen Devel [-- Attachment #1: Type: text/plain, Size: 4443 bytes --] On Mon, Apr 25, 2016 at 01:43:01PM +0200, Laszlo Ersek wrote: > On 04/22/16 16:47, Anthony PERARD wrote: > > Hi, > > > > Following the switch to MdeModulePkg/Bus/Pci/PciHostBridgeDxe, the pci root > > bridge does not finish to initialize and breaks under Xen. > > (Adding Ray Ni) > > > 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; > > } > > For this, I am to blame; sorry about the regression. Can you please > submit the change as a standalone patch, and mention commit > 03845e90cc432 as the one that missed it? > > Also, can you please add the macros to "OvmfPkg/PlatformPei/Xen.h" > instead, near OVMF_INFO_PHYSICAL_ADDRESS? > > > > > > > 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) { > > > > > > 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 ? > > I think your suggestion that PcdPciDisableBusEnumeration=TRUE causes > these problems is likely correct. Both of the above issues seem to > originate from PciHostBridgeDxe's assumption that resources have been > allocated (i.e., there has been an enumeration). > > Please discuss these questions with Ray -- I guess PciHostBridgeDxe may > not have received a lot of testing with > PcdPciDisableBusEnumeration=TRUE. I can imagine that simply considering > PcdPciDisableBusEnumeration, and acting conditionally upon its value, > might solve these problems. > I made a quick fix to skip those checks when PcdPciDisableBusEnumeration is TRUE. Plus the fix for OvmfPkg/PlatformPei/Xen.c, I can now boot to the UEFI shell. Ray, Do you think this is the right way to fix it? Thanks, Gary Lin [-- Attachment #2: ovmf-xen-quick-fix.patch --] [-- Type: text/x-patch, Size: 3512 bytes --] diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c b/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c index f72598d..0fb150c 100644 --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c @@ -1824,6 +1824,7 @@ PciIoGetBarAttributes ( PCI_IO_DEVICE *PciIoDevice; EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR *Descriptor; EFI_ACPI_END_TAG_DESCRIPTOR *End; + BOOLEAN EnablePciEnumeration; PciIoDevice = PCI_IO_DEVICE_FROM_PCI_IO_THIS (This); @@ -1918,7 +1919,8 @@ PciIoGetBarAttributes ( // // Get the Address Translation Offset // - if (Descriptor->ResType == ACPI_ADDRESS_SPACE_TYPE_MEM) { + EnablePciEnumeration = !PcdGetBool (PcdPciDisableBusEnumeration); + if (Descriptor->ResType == ACPI_ADDRESS_SPACE_TYPE_MEM && EnablePciEnumeration) { Descriptor->AddrTranslationOffset = GetMmioAddressTranslationOffset ( PciIoDevice->PciRootBridgeIo, Descriptor->AddrRangeMin, diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf index ab5d87e..712497d 100644 --- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf +++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf @@ -53,3 +53,6 @@ [Protocols] [Depex] gEfiCpuIo2ProtocolGuid AND gEfiMetronomeArchProtocolGuid + +[Pcd] + gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration ## SOMETIMES_CONSUMES diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c index cda9b49..4bac355 100644 --- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c +++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c @@ -13,6 +13,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. **/ +#include <Library/PcdLib.h> #include "PciHostBridge.h" #include "PciRootBridge.h" #include "PciHostResource.h" @@ -1495,6 +1496,7 @@ RootBridgeIoConfiguration ( PCI_RES_NODE *ResAllocNode; EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR *Descriptor; EFI_ACPI_END_TAG_DESCRIPTOR *End; + BOOLEAN EnablePciEnumeration; // // Get this instance of the Root Bridge. @@ -1505,19 +1507,22 @@ RootBridgeIoConfiguration ( TypeMax * sizeof (EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR) + sizeof (EFI_ACPI_END_TAG_DESCRIPTOR) ); Descriptor = RootBridge->ConfigBuffer; + EnablePciEnumeration = !PcdGetBool (PcdPciDisableBusEnumeration); for (Index = TypeIo; Index < TypeMax; Index++) { ResAllocNode = &RootBridge->ResAllocNode[Index]; - if (ResAllocNode->Status != ResAllocated) { + if (ResAllocNode->Status != ResAllocated && EnablePciEnumeration) { continue; } Descriptor->Desc = ACPI_ADDRESS_SPACE_DESCRIPTOR; Descriptor->Len = sizeof (EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR) - 3; - Descriptor->AddrRangeMin = ResAllocNode->Base; - Descriptor->AddrRangeMax = ResAllocNode->Base + ResAllocNode->Length - 1; - Descriptor->AddrLen = ResAllocNode->Length; + if (ResAllocNode->Status == ResAllocated) { + Descriptor->AddrRangeMin = ResAllocNode->Base; + Descriptor->AddrRangeMax = ResAllocNode->Base + ResAllocNode->Length - 1; + Descriptor->AddrLen = ResAllocNode->Length; + } switch (ResAllocNode->Type) { case TypeIo: [-- Attachment #3: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply related [flat|nested] 25+ messages in thread
[parent not found: <20160426062914.GB3109@GaryWorkstation>]
* Re: [edk2] OVMF broken under Xen (in PCI initialisation) [not found] ` <20160426062914.GB3109@GaryWorkstation> @ 2016-04-26 6:45 ` Ni, Ruiyu 0 siblings, 0 replies; 25+ messages in thread From: Ni, Ruiyu @ 2016-04-26 6:45 UTC (permalink / raw) To: Gary Lin, Anthony PERARD; +Cc: edk2-devel, Laszlo Ersek, Xen Devel [-- Attachment #1.1: Type: text/plain, Size: 5238 bytes --] Gary, thanks for providing the quick fix. How about directly return EFI_UNSUPPORTED when the PcdPciDisableEnumeration is TRUE? See my another mail reply to this thread. Regards, Ray >-----Original Message----- >From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Gary Lin >Sent: Tuesday, April 26, 2016 2:29 PM >To: Anthony PERARD <anthony.perard@citrix.com>; Ni, Ruiyu <ruiyu.ni@intel.com> >Cc: edk2-devel@ml01.01.org; Laszlo Ersek <lersek@redhat.com>; Xen Devel <xen-devel@lists.xen.org> >Subject: Re: [edk2] OVMF broken under Xen (in PCI initialisation) > >On Mon, Apr 25, 2016 at 01:43:01PM +0200, Laszlo Ersek wrote: >> On 04/22/16 16:47, Anthony PERARD wrote: >> > Hi, >> > >> > Following the switch to MdeModulePkg/Bus/Pci/PciHostBridgeDxe, the pci root >> > bridge does not finish to initialize and breaks under Xen. >> >> (Adding Ray Ni) >> >> > 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; >> > } >> >> For this, I am to blame; sorry about the regression. Can you please >> submit the change as a standalone patch, and mention commit >> 03845e90cc432 as the one that missed it? >> >> Also, can you please add the macros to "OvmfPkg/PlatformPei/Xen.h" >> instead, near OVMF_INFO_PHYSICAL_ADDRESS? >> >> > >> > >> > 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) { >> > >> > >> > 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 ? >> >> I think your suggestion that PcdPciDisableBusEnumeration=TRUE causes >> these problems is likely correct. Both of the above issues seem to >> originate from PciHostBridgeDxe's assumption that resources have been >> allocated (i.e., there has been an enumeration). >> >> Please discuss these questions with Ray -- I guess PciHostBridgeDxe may >> not have received a lot of testing with >> PcdPciDisableBusEnumeration=TRUE. I can imagine that simply considering >> PcdPciDisableBusEnumeration, and acting conditionally upon its value, >> might solve these problems. >> >I made a quick fix to skip those checks when PcdPciDisableBusEnumeration >is TRUE. Plus the fix for OvmfPkg/PlatformPei/Xen.c, I can now boot to >the UEFI shell. > >Ray, > >Do you think this is the right way to fix it? > >Thanks, > >Gary Lin [-- Attachment #1.2: Type: text/html, Size: 16335 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [edk2] OVMF broken under Xen (in PCI initialisation) [not found] <20160422144736.GD1885@perard.uk.xensource.com> 2016-04-25 11:43 ` [edk2] OVMF broken under Xen (in PCI initialisation) Laszlo Ersek [not found] ` <571E02C5.1000906@redhat.com> @ 2016-04-26 6:43 ` Ni, Ruiyu [not found] ` <734D49CCEBEEF84792F5B80ED585239D0DA25884@SHSMSX103.ccr.corp.intel.com> 3 siblings, 0 replies; 25+ messages in thread From: Ni, Ruiyu @ 2016-04-26 6:43 UTC (permalink / raw) To: Anthony PERARD, edk2-devel; +Cc: Xen Devel 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 <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? > >Thanks, > >-- >Anthony PERARD >_______________________________________________ >edk2-devel mailing list >edk2-devel@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 ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <734D49CCEBEEF84792F5B80ED585239D0DA25884@SHSMSX103.ccr.corp.intel.com>]
* Re: [edk2] OVMF broken under Xen (in PCI initialisation) [not found] ` <734D49CCEBEEF84792F5B80ED585239D0DA25884@SHSMSX103.ccr.corp.intel.com> @ 2016-04-26 7:35 ` Gary Lin [not found] ` <20160426073529.GC3109@GaryWorkstation> 1 sibling, 0 replies; 25+ messages in thread From: Gary Lin @ 2016-04-26 7:35 UTC (permalink / raw) To: Ni, Ruiyu; +Cc: Anthony PERARD, edk2-devel, Xen Devel [-- Attachment #1: Type: text/plain, Size: 5169 bytes --] 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 <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 [-- Attachment #2: ovmf-return-unsupported.patch --] [-- Type: text/x-patch, Size: 1268 bytes --] diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf index ab5d87e..712497d 100644 --- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf +++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf @@ -53,3 +53,6 @@ [Protocols] [Depex] gEfiCpuIo2ProtocolGuid AND gEfiMetronomeArchProtocolGuid + +[Pcd] + gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration ## SOMETIMES_CONSUMES diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c index cda9b49..31a8467 100644 --- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c +++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c @@ -13,6 +13,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. **/ +#include <Library/PcdLib.h> #include "PciHostBridge.h" #include "PciRootBridge.h" #include "PciHostResource.h" @@ -1496,6 +1497,8 @@ RootBridgeIoConfiguration ( EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR *Descriptor; EFI_ACPI_END_TAG_DESCRIPTOR *End; + if (PcdGetBool (PcdPciDisableBusEnumeration)) + return EFI_UNSUPPORTED; // // Get this instance of the Root Bridge. // [-- Attachment #3: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply related [flat|nested] 25+ messages in thread
[parent not found: <20160426073529.GC3109@GaryWorkstation>]
* Re: [edk2] OVMF broken under Xen (in PCI initialisation) [not found] ` <20160426073529.GC3109@GaryWorkstation> @ 2016-04-26 8:19 ` Ni, Ruiyu [not found] ` <734D49CCEBEEF84792F5B80ED585239D0DA25B98@SHSMSX103.ccr.corp.intel.com> 2016-04-26 9:31 ` Andrew Cooper 2 siblings, 0 replies; 25+ messages in thread From: Ni, Ruiyu @ 2016-04-26 8:19 UTC (permalink / raw) To: Gary Lin; +Cc: Anthony PERARD, edk2-devel, Xen Devel [-- Attachment #1.1: Type: text/plain, Size: 5849 bytes --] 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? Regards, Ray From: Gary Lin [mailto:glin@suse.com] Sent: Tuesday, April 26, 2016 3:35 PM To: Ni, Ruiyu <ruiyu.ni@intel.com> Cc: Anthony PERARD <anthony.perard@citrix.com>; edk2-devel@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-bounces@lists.01.org] On Behalf Of Anthony PERARD > >Sent: Friday, April 22, 2016 10:48 PM > >To: edk2-devel@lists.01.org<mailto:edk2-devel@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 [-- Attachment #1.2: Type: text/html, Size: 18560 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <734D49CCEBEEF84792F5B80ED585239D0DA25B98@SHSMSX103.ccr.corp.intel.com>]
* Re: [edk2] OVMF broken under Xen (in PCI initialisation) [not found] ` <734D49CCEBEEF84792F5B80ED585239D0DA25B98@SHSMSX103.ccr.corp.intel.com> @ 2016-04-26 8:40 ` Gary Lin [not found] ` <20160426084000.GD3109@GaryWorkstation> 1 sibling, 0 replies; 25+ messages in thread From: Gary Lin @ 2016-04-26 8:40 UTC (permalink / raw) To: Ni, Ruiyu; +Cc: edk2-devel, Xen Devel 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@suse.com] > Sent: Tuesday, April 26, 2016 3:35 PM > To: Ni, Ruiyu <ruiyu.ni@intel.com> > Cc: Anthony PERARD <anthony.perard@citrix.com>; edk2-devel@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-bounces@lists.01.org] On Behalf Of Anthony PERARD > > >Sent: Friday, April 22, 2016 10:48 PM > > >To: edk2-devel@lists.01.org<mailto:edk2-devel@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-devel@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 ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <20160426084000.GD3109@GaryWorkstation>]
* Re: [edk2] OVMF broken under Xen (in PCI initialisation) [not found] ` <20160426084000.GD3109@GaryWorkstation> @ 2016-04-26 9:40 ` Ni, Ruiyu [not found] ` <734D49CCEBEEF84792F5B80ED585239D0DA25D38@SHSMSX103.ccr.corp.intel.com> 1 sibling, 0 replies; 25+ messages in thread From: Ni, Ruiyu @ 2016-04-26 9:40 UTC (permalink / raw) To: Gary Lin; +Cc: edk2-devel, Xen Devel 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. The second change you need to make is in PciIo.c: Change GetMmioAddressTranslationOffset() to return 0 instead of -1 when error occurs 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 resource descriptor with MinBus = MaxBus = 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 pass that information to PciHostBridge driver. If no, we also could let PciHostBridgeLib collect the information (IO/MEM/BUS resource assignment) and pass that to PciHostBridgeDxe driver. And we need to have a way to tell PciHostBridgeDxe the resource information passed from PciHostBridgeLib is available resource to assign, or already 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 <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 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 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@suse.com] >> Sent: Tuesday, April 26, 2016 3:35 PM >> To: Ni, Ruiyu <ruiyu.ni@intel.com> >> Cc: Anthony PERARD <anthony.perard@citrix.com>; edk2-devel@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-bounces@lists.01.org] On Behalf Of Anthony PERARD >> > >Sent: Friday, April 22, 2016 10:48 PM >> > >To: edk2-devel@lists.01.org<mailto:edk2-devel@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-devel@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 ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <734D49CCEBEEF84792F5B80ED585239D0DA25D38@SHSMSX103.ccr.corp.intel.com>]
* Re: [edk2] OVMF broken under Xen (in PCI initialisation) [not found] ` <734D49CCEBEEF84792F5B80ED585239D0DA25D38@SHSMSX103.ccr.corp.intel.com> @ 2016-04-27 4:29 ` Gary Lin [not found] ` <20160427042907.GH3109@GaryWorkstation> 1 sibling, 0 replies; 25+ messages in thread From: Gary Lin @ 2016-04-27 4:29 UTC (permalink / raw) To: Ni, Ruiyu; +Cc: edk2-devel, Xen Devel 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() ? > 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);" ? 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 resource > descriptor with MinBus = MaxBus = 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 pass that > information to PciHostBridge driver. If no, we also could let PciHostBridgeLib > collect the information (IO/MEM/BUS resource assignment) and pass that > to PciHostBridgeDxe driver. > > And we need to have a way to tell PciHostBridgeDxe the resource information > passed from PciHostBridgeLib is available resource to assign, or already 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 <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 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 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@suse.com] > >> Sent: Tuesday, April 26, 2016 3:35 PM > >> To: Ni, Ruiyu <ruiyu.ni@intel.com> > >> Cc: Anthony PERARD <anthony.perard@citrix.com>; edk2-devel@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-bounces@lists.01.org] On Behalf Of Anthony PERARD > >> > >Sent: Friday, April 22, 2016 10:48 PM > >> > >To: edk2-devel@lists.01.org<mailto:edk2-devel@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-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 > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <20160427042907.GH3109@GaryWorkstation>]
* Re: [edk2] OVMF broken under Xen (in PCI initialisation) [not found] ` <20160427042907.GH3109@GaryWorkstation> @ 2016-04-27 5:39 ` Ni, Ruiyu [not found] ` <734D49CCEBEEF84792F5B80ED585239D0DA27D1E@SHSMSX103.ccr.corp.intel.com> 1 sibling, 0 replies; 25+ messages in thread From: Ni, Ruiyu @ 2016-04-27 5:39 UTC (permalink / raw) To: Gary Lin; +Cc: edk2-devel, Xen Devel Regards, Ray >-----Original Message----- >From: Gary Lin [mailto:glin@suse.com] >Sent: Wednesday, April 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 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. > >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 resource >> descriptor with MinBus = MaxBus = 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 pass that >> information to PciHostBridge driver. If no, we also could let PciHostBridgeLib >> collect the information (IO/MEM/BUS resource assignment) and pass that >> to PciHostBridgeDxe driver. >> >> And we need to have a way to tell PciHostBridgeDxe the resource information >> passed from PciHostBridgeLib is available resource to assign, or already 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 <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 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 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@suse.com] >> >> Sent: Tuesday, April 26, 2016 3:35 PM >> >> To: Ni, Ruiyu <ruiyu.ni@intel.com> >> >> Cc: Anthony PERARD <anthony.perard@citrix.com>; edk2-devel@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-bounces@lists.01.org] On Behalf Of Anthony PERARD >> >> > >Sent: Friday, April 22, 2016 10:48 PM >> >> > >To: edk2-devel@lists.01.org<mailto:edk2-devel@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-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 >> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <734D49CCEBEEF84792F5B80ED585239D0DA27D1E@SHSMSX103.ccr.corp.intel.com>]
* Re: [edk2] OVMF broken under Xen (in PCI initialisation) [not found] ` <734D49CCEBEEF84792F5B80ED585239D0DA27D1E@SHSMSX103.ccr.corp.intel.com> @ 2016-04-27 6:54 ` Gary Lin [not found] ` <20160427065428.GJ3109@GaryWorkstation> 1 sibling, 0 replies; 25+ messages in thread From: Gary Lin @ 2016-04-27 6:54 UTC (permalink / raw) To: Ni, Ruiyu; +Cc: edk2-devel, Xen Devel [-- Attachment #1: Type: text/plain, Size: 10709 bytes --] 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 <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 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 resource > >> descriptor with MinBus = MaxBus = 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 pass that > >> information to PciHostBridge driver. If no, we also could let PciHostBridgeLib > >> collect the information (IO/MEM/BUS resource assignment) and pass that > >> to PciHostBridgeDxe driver. > >> > >> And we need to have a way to tell PciHostBridgeDxe the resource information > >> passed from PciHostBridgeLib is available resource to assign, or already 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 <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 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 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@suse.com] > >> >> Sent: Tuesday, April 26, 2016 3:35 PM > >> >> To: Ni, Ruiyu <ruiyu.ni@intel.com> > >> >> Cc: Anthony PERARD <anthony.perard@citrix.com>; edk2-devel@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-bounces@lists.01.org] On Behalf Of Anthony PERARD > >> >> > >Sent: Friday, April 22, 2016 10:48 PM > >> >> > >To: edk2-devel@lists.01.org<mailto:edk2-devel@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-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 > [-- Attachment #2: ovmf-hack-1.patch --] [-- Type: text/x-patch, Size: 2610 bytes --] diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c b/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c index a6ade26..5821fce 100644 --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c @@ -2466,11 +2466,13 @@ PciGetBusRange ( while ((*Descriptors)->Desc != ACPI_END_TAG_DESCRIPTOR) { if ((*Descriptors)->ResType == ACPI_ADDRESS_SPACE_TYPE_BUS) { if (MinBus != NULL) { - *MinBus = (UINT16) (*Descriptors)->AddrRangeMin; + //*MinBus = (UINT16) (*Descriptors)->AddrRangeMin; + *MinBus = 0; } if (MaxBus != NULL) { - *MaxBus = (UINT16) (*Descriptors)->AddrRangeMax; + //*MaxBus = (UINT16) (*Descriptors)->AddrRangeMax; + *MinBus = 0xFF; } if (BusRange != NULL) { diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c b/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c index f72598d..39a0e4c 100644 --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c @@ -1770,7 +1770,7 @@ GetMmioAddressTranslationOffset ( (VOID **) &Configuration ); if (EFI_ERROR (Status)) { - return (UINT64) -1; + return (UINT64) 0; } while (Configuration->Desc == ACPI_ADDRESS_SPACE_DESCRIPTOR) { diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf index ab5d87e..712497d 100644 --- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf +++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf @@ -53,3 +53,6 @@ [Protocols] [Depex] gEfiCpuIo2ProtocolGuid AND gEfiMetronomeArchProtocolGuid + +[Pcd] + gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration ## SOMETIMES_CONSUMES diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c index cda9b49..9ca98d4 100644 --- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c +++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c @@ -13,6 +13,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. **/ +#include <Library/PcdLib.h> #include "PciHostBridge.h" #include "PciRootBridge.h" #include "PciHostResource.h" @@ -1496,6 +1497,9 @@ RootBridgeIoConfiguration ( EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR *Descriptor; EFI_ACPI_END_TAG_DESCRIPTOR *End; + if (PcdGetBool (PcdPciDisableBusEnumeration)) + return EFI_UNSUPPORTED; + // // Get this instance of the Root Bridge. // [-- Attachment #3: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply related [flat|nested] 25+ messages in thread
[parent not found: <20160427065428.GJ3109@GaryWorkstation>]
* Re: [edk2] OVMF broken under Xen (in PCI initialisation) [not found] ` <20160427065428.GJ3109@GaryWorkstation> @ 2016-04-27 7:18 ` Ni, Ruiyu [not found] ` <734D49CCEBEEF84792F5B80ED585239D0DA27F59@SHSMSX103.ccr.corp.intel.com> 1 sibling, 0 replies; 25+ messages in thread From: Ni, Ruiyu @ 2016-04-27 7:18 UTC (permalink / raw) To: Gary Lin; +Cc: edk2-devel, Xen Devel [-- Attachment #1.1: Type: text/plain, Size: 11722 bytes --] 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 <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 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 <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 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 resource >> >> descriptor with MinBus = MaxBus = 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 pass that >> >> information to PciHostBridge driver. If no, we also could let PciHostBridgeLib >> >> collect the information (IO/MEM/BUS resource assignment) and pass that >> >> to PciHostBridgeDxe driver. >> >> >> >> And we need to have a way to tell PciHostBridgeDxe the resource information >> >> passed from PciHostBridgeLib is available resource to assign, or already 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 <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 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 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@suse.com] >> >> >> Sent: Tuesday, April 26, 2016 3:35 PM >> >> >> To: Ni, Ruiyu <ruiyu.ni@intel.com> >> >> >> Cc: Anthony PERARD <anthony.perard@citrix.com>; edk2-devel@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-bounces@lists.01.org] On Behalf Of Anthony PERARD >> >> >> > >Sent: Friday, April 22, 2016 10:48 PM >> >> >> > >To: edk2-devel@lists.01.org<mailto:edk2-devel@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-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 >> [-- Attachment #1.2: Type: text/html, Size: 36843 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <734D49CCEBEEF84792F5B80ED585239D0DA27F59@SHSMSX103.ccr.corp.intel.com>]
* Re: [edk2] OVMF broken under Xen (in PCI initialisation) [not found] ` <734D49CCEBEEF84792F5B80ED585239D0DA27F59@SHSMSX103.ccr.corp.intel.com> @ 2016-04-27 8:26 ` Gary Lin [not found] ` <20160427082641.GK3109@GaryWorkstation> 1 sibling, 0 replies; 25+ messages in thread From: Gary Lin @ 2016-04-27 8:26 UTC (permalink / raw) To: Ni, Ruiyu; +Cc: edk2-devel, Xen Devel [-- Attachment #1: Type: text/plain, Size: 12296 bytes --] On Wed, Apr 27, 2016 at 07:18:21AM +0000, Ni, Ruiyu wrote: > 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(). > OK, I ignored PciGetBusRange() and the check of the return status of Configuration(). Since MinBus is already initialized, I don't bother to change the value anyway. The change is attached. And yes, this time the shell showed. Thanks, Gary Lin > Regards, > Ray > > >-----Original Message----- > >From: Gary Lin [mailto:glin@suse.com] > >Sent: Wednesday, April 27, 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 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 <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 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 resource > >> >> descriptor with MinBus = MaxBus = 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 pass that > >> >> information to PciHostBridge driver. If no, we also could let PciHostBridgeLib > >> >> collect the information (IO/MEM/BUS resource assignment) and pass that > >> >> to PciHostBridgeDxe driver. > >> >> > >> >> And we need to have a way to tell PciHostBridgeDxe the resource information > >> >> passed from PciHostBridgeLib is available resource to assign, or already 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 <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 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 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@suse.com] > >> >> >> Sent: Tuesday, April 26, 2016 3:35 PM > >> >> >> To: Ni, Ruiyu <ruiyu.ni@intel.com> > >> >> >> Cc: Anthony PERARD <anthony.perard@citrix.com>; edk2-devel@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-bounces@lists.01.org] On Behalf Of Anthony PERARD > >> >> >> > >Sent: Friday, April 22, 2016 10:48 PM > >> >> >> > >To: edk2-devel@lists.01.org<mailto:edk2-devel@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-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 > >> [-- Attachment #2: ovmf-hack-2.patch --] [-- Type: text/x-patch, Size: 3026 bytes --] diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c b/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c index a6ade26..8f36e90 100644 --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c @@ -2382,21 +2382,21 @@ PciEnumeratorLight ( Status = PciRootBridgeIo->Configuration (PciRootBridgeIo, (VOID **) &Descriptors); - if (EFI_ERROR (Status)) { - return Status; - } +// if (EFI_ERROR (Status)) { +// return Status; +// } - while (PciGetBusRange (&Descriptors, &MinBus, &MaxBus, NULL) == EFI_SUCCESS) { +// while (PciGetBusRange (&Descriptors, &MinBus, &MaxBus, NULL) == EFI_SUCCESS) { // // Create a device node for root bridge device with a NULL host bridge controller handle // RootBridgeDev = CreateRootBridge (Controller); - if (RootBridgeDev == NULL) { - Descriptors++; - continue; - } +// if (RootBridgeDev == NULL) { +// Descriptors++; +// continue; +// } // // Record the root bridgeio protocol @@ -2437,8 +2437,8 @@ PciEnumeratorLight ( DestroyRootBridge (RootBridgeDev); } - Descriptors++; - } +// Descriptors++; +// } return EFI_SUCCESS; } diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c b/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c index f72598d..39a0e4c 100644 --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c @@ -1770,7 +1770,7 @@ GetMmioAddressTranslationOffset ( (VOID **) &Configuration ); if (EFI_ERROR (Status)) { - return (UINT64) -1; + return (UINT64) 0; } while (Configuration->Desc == ACPI_ADDRESS_SPACE_DESCRIPTOR) { diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf index ab5d87e..712497d 100644 --- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf +++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf @@ -53,3 +53,6 @@ [Protocols] [Depex] gEfiCpuIo2ProtocolGuid AND gEfiMetronomeArchProtocolGuid + +[Pcd] + gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration ## SOMETIMES_CONSUMES diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c index cda9b49..9ca98d4 100644 --- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c +++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c @@ -13,6 +13,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. **/ +#include <Library/PcdLib.h> #include "PciHostBridge.h" #include "PciRootBridge.h" #include "PciHostResource.h" @@ -1496,6 +1497,9 @@ RootBridgeIoConfiguration ( EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR *Descriptor; EFI_ACPI_END_TAG_DESCRIPTOR *End; + if (PcdGetBool (PcdPciDisableBusEnumeration)) + return EFI_UNSUPPORTED; + // // Get this instance of the Root Bridge. // [-- Attachment #3: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply related [flat|nested] 25+ messages in thread
[parent not found: <20160427082641.GK3109@GaryWorkstation>]
* Re: [edk2] OVMF broken under Xen (in PCI initialisation) [not found] ` <20160427082641.GK3109@GaryWorkstation> @ 2016-04-27 9:48 ` Ni, Ruiyu 2016-04-27 9:50 ` Ni, Ruiyu [not found] ` <734D49CCEBEEF84792F5B80ED585239D0DA291E5@SHSMSX103.ccr.corp.intel.com> 2 siblings, 0 replies; 25+ messages in thread From: Ni, Ruiyu @ 2016-04-27 9:48 UTC (permalink / raw) To: Gary Lin; +Cc: edk2-devel, Laszlo Ersek, Xen Devel Gary, Thanks for the try. I now understand why the issue happens. 1. PciEnumeratorLight() depends on the MinBus returned from PciRootBridgeIo.Configuration(). 2. PciRootBridgeIo.Configuration() returns the resource descriptors initialized by PciHostBridge.NotifyPhase(EfiPciHostBridgeAllocateResources). 3. PciHostBridge.NotifyPhase(EfiPciHostBridgeAllocateResources) is not called when PcdPciDisableBusEnumeration is TRUE I am thinking about let PciRootBridgeIo.Configuration() returns the correct resource consumption information even when PcdPciDisableBusEnumeration is TRUE. I can add a new field to PCI_ROOT_BRIDGE structure defined in MdeModulePkg/Include/Library/PciHostBridgeLib.h to indicate that the resources filled in PCI_ROOT_BRIDGE.Bus/Io/Mem/ MemAbove4G/PMem/PMemAbove4G are already assigned to PCI bus. So that PciRootBridgeIo.Configuration() can return these value even when PciHostBridge.NotifyPhase(EfiPciHostBridgeAllocateResources) is not called due to PcdPciDisableBusEnumeration is TRUE. Do you know whether Xen passes the PCI device resource information to firmware? Copying Laszlo. Regards, Ray >-----Original Message----- >From: Gary Lin [mailto:glin@suse.com] >Sent: Wednesday, April 27, 2016 4:27 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 initialisation) > >On Wed, Apr 27, 2016 at 07:18:21AM +0000, Ni, Ruiyu wrote: >> 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(). >> >OK, I ignored PciGetBusRange() and the check of the return status of >Configuration(). Since MinBus is already initialized, I don't bother to >change the value anyway. The change is attached. > >And yes, this time the shell showed. > >Thanks, > >Gary Lin > >> Regards, >> Ray >> >> >-----Original Message----- >> >From: Gary Lin [mailto:glin@suse.com] >> >Sent: Wednesday, April 27, 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 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 <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 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 resource >> >> >> descriptor with MinBus = MaxBus = 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 pass that >> >> >> information to PciHostBridge driver. If no, we also could let PciHostBridgeLib >> >> >> collect the information (IO/MEM/BUS resource assignment) and pass that >> >> >> to PciHostBridgeDxe driver. >> >> >> >> >> >> And we need to have a way to tell PciHostBridgeDxe the resource information >> >> >> passed from PciHostBridgeLib is available resource to assign, or already 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 <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 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 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@suse.com] >> >> >> >> Sent: Tuesday, April 26, 2016 3:35 PM >> >> >> >> To: Ni, Ruiyu <ruiyu.ni@intel.com> >> >> >> >> Cc: Anthony PERARD <anthony.perard@citrix.com>; edk2-devel@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-bounces@lists.01.org] On Behalf Of Anthony PERARD >> >> >> >> > >Sent: Friday, April 22, 2016 10:48 PM >> >> >> >> > >To: edk2-devel@lists.01.org<mailto:edk2-devel@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-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 >> >> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [edk2] OVMF broken under Xen (in PCI initialisation) [not found] ` <20160427082641.GK3109@GaryWorkstation> 2016-04-27 9:48 ` Ni, Ruiyu @ 2016-04-27 9:50 ` Ni, Ruiyu [not found] ` <734D49CCEBEEF84792F5B80ED585239D0DA291E5@SHSMSX103.ccr.corp.intel.com> 2 siblings, 0 replies; 25+ messages in thread From: Ni, Ruiyu @ 2016-04-27 9:50 UTC (permalink / raw) To: Gary Lin; +Cc: Kinney, Michael D, edk2-devel, Laszlo Ersek, Xen Devel Copying Mike. Regards, Ray >-----Original Message----- >From: Ni, Ruiyu >Sent: Wednesday, April 27, 2016 5:49 PM >To: 'Gary Lin' <glin@suse.com> >Cc: edk2-devel@lists.01.org; Xen Devel <xen-devel@lists.xen.org>; Laszlo Ersek <lersek@redhat.com> >Subject: RE: [edk2] OVMF broken under Xen (in PCI initialisation) > >Gary, >Thanks for the try. > >I now understand why the issue happens. >1. PciEnumeratorLight() depends on the MinBus returned from >PciRootBridgeIo.Configuration(). >2. PciRootBridgeIo.Configuration() returns the resource descriptors >initialized by PciHostBridge.NotifyPhase(EfiPciHostBridgeAllocateResources). >3. PciHostBridge.NotifyPhase(EfiPciHostBridgeAllocateResources) >is not called when PcdPciDisableBusEnumeration is TRUE > >I am thinking about let PciRootBridgeIo.Configuration() returns >the correct resource consumption information even when >PcdPciDisableBusEnumeration is TRUE. > >I can add a new field to PCI_ROOT_BRIDGE structure defined in >MdeModulePkg/Include/Library/PciHostBridgeLib.h to indicate >that the resources filled in PCI_ROOT_BRIDGE.Bus/Io/Mem/ >MemAbove4G/PMem/PMemAbove4G are already assigned >to PCI bus. So that PciRootBridgeIo.Configuration() can return >these value even when >PciHostBridge.NotifyPhase(EfiPciHostBridgeAllocateResources) >is not called due to PcdPciDisableBusEnumeration is TRUE. > >Do you know whether Xen passes the PCI device resource >information to firmware? > >Copying Laszlo. > >Regards, >Ray > >>-----Original Message----- >>From: Gary Lin [mailto:glin@suse.com] >>Sent: Wednesday, April 27, 2016 4:27 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 initialisation) >> >>On Wed, Apr 27, 2016 at 07:18:21AM +0000, Ni, Ruiyu wrote: >>> 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(). >>> >>OK, I ignored PciGetBusRange() and the check of the return status of >>Configuration(). Since MinBus is already initialized, I don't bother to >>change the value anyway. The change is attached. >> >>And yes, this time the shell showed. >> >>Thanks, >> >>Gary Lin >> >>> Regards, >>> Ray >>> >>> >-----Original Message----- >>> >From: Gary Lin [mailto:glin@suse.com] >>> >Sent: Wednesday, April 27, 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 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 <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 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 resource >>> >> >> descriptor with MinBus = MaxBus = 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 pass that >>> >> >> information to PciHostBridge driver. If no, we also could let PciHostBridgeLib >>> >> >> collect the information (IO/MEM/BUS resource assignment) and pass that >>> >> >> to PciHostBridgeDxe driver. >>> >> >> >>> >> >> And we need to have a way to tell PciHostBridgeDxe the resource information >>> >> >> passed from PciHostBridgeLib is available resource to assign, or already 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 <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 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 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@suse.com] >>> >> >> >> Sent: Tuesday, April 26, 2016 3:35 PM >>> >> >> >> To: Ni, Ruiyu <ruiyu.ni@intel.com> >>> >> >> >> Cc: Anthony PERARD <anthony.perard@citrix.com>; edk2-devel@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-bounces@lists.01.org] On Behalf Of Anthony PERARD >>> >> >> >> > >Sent: Friday, April 22, 2016 10:48 PM >>> >> >> >> > >To: edk2-devel@lists.01.org<mailto:edk2-devel@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-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 >>> >> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <734D49CCEBEEF84792F5B80ED585239D0DA291E5@SHSMSX103.ccr.corp.intel.com>]
* Re: [edk2] OVMF broken under Xen (in PCI initialisation) [not found] ` <734D49CCEBEEF84792F5B80ED585239D0DA291E5@SHSMSX103.ccr.corp.intel.com> @ 2016-04-27 10:43 ` Laszlo Ersek [not found] ` <572097E4.1070300@redhat.com> 1 sibling, 0 replies; 25+ messages in thread From: Laszlo Ersek @ 2016-04-27 10:43 UTC (permalink / raw) To: Ni, Ruiyu, Gary Lin; +Cc: Kinney, Michael D, edk2-devel@lists.01.org, Xen Devel On 04/27/16 11:50, Ni, Ruiyu wrote: > Copying Mike. > > Regards, > Ray > >> -----Original Message----- >> From: Ni, Ruiyu >> Sent: Wednesday, April 27, 2016 5:49 PM >> To: 'Gary Lin' <glin@suse.com> >> Cc: edk2-devel@lists.01.org; Xen Devel <xen-devel@lists.xen.org>; Laszlo Ersek <lersek@redhat.com> >> Subject: RE: [edk2] OVMF broken under Xen (in PCI initialisation) >> >> Gary, >> Thanks for the try. >> >> I now understand why the issue happens. >> 1. PciEnumeratorLight() depends on the MinBus returned from >> PciRootBridgeIo.Configuration(). >> 2. PciRootBridgeIo.Configuration() returns the resource descriptors >> initialized by PciHostBridge.NotifyPhase(EfiPciHostBridgeAllocateResources). >> 3. PciHostBridge.NotifyPhase(EfiPciHostBridgeAllocateResources) >> is not called when PcdPciDisableBusEnumeration is TRUE >> >> I am thinking about let PciRootBridgeIo.Configuration() returns >> the correct resource consumption information even when >> PcdPciDisableBusEnumeration is TRUE. >> >> I can add a new field to PCI_ROOT_BRIDGE structure defined in >> MdeModulePkg/Include/Library/PciHostBridgeLib.h to indicate >> that the resources filled in PCI_ROOT_BRIDGE.Bus/Io/Mem/ >> MemAbove4G/PMem/PMemAbove4G are already assigned >> to PCI bus. So that PciRootBridgeIo.Configuration() can return >> these value even when >> PciHostBridge.NotifyPhase(EfiPciHostBridgeAllocateResources) >> is not called due to PcdPciDisableBusEnumeration is TRUE. Can you use PcdPciDisableBusEnumeration directly for this? (If you don't like the idea, we could certainly set the new field in PCI_ROOT_BRIDGE from the PCD too, in OvmfPkg/Library/PciHostBridgeLib.) >> Do you know whether Xen passes the PCI device resource >> information to firmware? I don't think so, no. But, given that the previous PciHostBridgeDxe driver was working on Xen, can we perhaps emulate that behavior in "OvmfPkg/Library/PciHostBridgeLib" somehow? Do you think that step (2) above behaves differently between the old and the new PCI host bridge driver? (Steps (1) and (3) should be identical, they are initiated by the PCI Bus driver.) Thanks Laszlo >> >> Copying Laszlo. >> >> Regards, >> Ray >> >>> -----Original Message----- >>> From: Gary Lin [mailto:glin@suse.com] >>> Sent: Wednesday, April 27, 2016 4:27 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 initialisation) >>> >>> On Wed, Apr 27, 2016 at 07:18:21AM +0000, Ni, Ruiyu wrote: >>>> 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(). >>>> >>> OK, I ignored PciGetBusRange() and the check of the return status of >>> Configuration(). Since MinBus is already initialized, I don't bother to >>> change the value anyway. The change is attached. >>> >>> And yes, this time the shell showed. >>> >>> Thanks, >>> >>> Gary Lin >>> >>>> Regards, >>>> Ray >>>> >>>>> -----Original Message----- >>>>> From: Gary Lin [mailto:glin@suse.com] >>>>> Sent: Wednesday, April 27, 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 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 <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 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 resource >>>>>>>> descriptor with MinBus = MaxBus = 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 pass that >>>>>>>> information to PciHostBridge driver. If no, we also could let PciHostBridgeLib >>>>>>>> collect the information (IO/MEM/BUS resource assignment) and pass that >>>>>>>> to PciHostBridgeDxe driver. >>>>>>>> >>>>>>>> And we need to have a way to tell PciHostBridgeDxe the resource information >>>>>>>> passed from PciHostBridgeLib is available resource to assign, or already 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 <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 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 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@suse.com] >>>>>>>>>> Sent: Tuesday, April 26, 2016 3:35 PM >>>>>>>>>> To: Ni, Ruiyu <ruiyu.ni@intel.com> >>>>>>>>>> Cc: Anthony PERARD <anthony.perard@citrix.com>; edk2-devel@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-bounces@lists.01.org] On Behalf Of Anthony PERARD >>>>>>>>>>>> Sent: Friday, April 22, 2016 10:48 PM >>>>>>>>>>>> To: edk2-devel@lists.01.org<mailto:edk2-devel@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-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 >>>>>> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <572097E4.1070300@redhat.com>]
* Re: [edk2] OVMF broken under Xen (in PCI initialisation) [not found] ` <572097E4.1070300@redhat.com> @ 2016-04-28 5:08 ` Ni, Ruiyu [not found] ` <734D49CCEBEEF84792F5B80ED585239D0DA29FD5@SHSMSX103.ccr.corp.intel.com> 1 sibling, 0 replies; 25+ messages in thread From: Ni, Ruiyu @ 2016-04-28 5:08 UTC (permalink / raw) To: Laszlo Ersek, Gary Lin Cc: Kinney, Michael D, edk2-devel@lists.01.org, Xen Devel Regards, Ray >-----Original Message----- >From: Laszlo Ersek [mailto:lersek@redhat.com] >Sent: Wednesday, April 27, 2016 6:44 PM >To: Ni, Ruiyu <ruiyu.ni@intel.com>; Gary Lin <glin@suse.com> >Cc: edk2-devel@lists.01.org <edk2-devel@ml01.01.org>; Xen Devel <xen-devel@lists.xen.org>; Kinney, Michael D ><michael.d.kinney@intel.com> >Subject: Re: [edk2] OVMF broken under Xen (in PCI initialisation) > >On 04/27/16 11:50, Ni, Ruiyu wrote: >> Copying Mike. >> >> Regards, >> Ray >> >>> -----Original Message----- >>> From: Ni, Ruiyu >>> Sent: Wednesday, April 27, 2016 5:49 PM >>> To: 'Gary Lin' <glin@suse.com> >>> Cc: edk2-devel@lists.01.org; Xen Devel <xen-devel@lists.xen.org>; Laszlo Ersek <lersek@redhat.com> >>> Subject: RE: [edk2] OVMF broken under Xen (in PCI initialisation) >>> >>> Gary, >>> Thanks for the try. >>> >>> I now understand why the issue happens. >>> 1. PciEnumeratorLight() depends on the MinBus returned from >>> PciRootBridgeIo.Configuration(). >>> 2. PciRootBridgeIo.Configuration() returns the resource descriptors >>> initialized by PciHostBridge.NotifyPhase(EfiPciHostBridgeAllocateResources). >>> 3. PciHostBridge.NotifyPhase(EfiPciHostBridgeAllocateResources) >>> is not called when PcdPciDisableBusEnumeration is TRUE >>> >>> I am thinking about let PciRootBridgeIo.Configuration() returns >>> the correct resource consumption information even when >>> PcdPciDisableBusEnumeration is TRUE. >>> >>> I can add a new field to PCI_ROOT_BRIDGE structure defined in >>> MdeModulePkg/Include/Library/PciHostBridgeLib.h to indicate >>> that the resources filled in PCI_ROOT_BRIDGE.Bus/Io/Mem/ >>> MemAbove4G/PMem/PMemAbove4G are already assigned >>> to PCI bus. So that PciRootBridgeIo.Configuration() can return >>> these value even when >>> PciHostBridge.NotifyPhase(EfiPciHostBridgeAllocateResources) >>> is not called due to PcdPciDisableBusEnumeration is TRUE. > >Can you use PcdPciDisableBusEnumeration directly for this? > >(If you don't like the idea, we could certainly set the new field in >PCI_ROOT_BRIDGE from the PCD too, in OvmfPkg/Library/PciHostBridgeLib.) > >>> Do you know whether Xen passes the PCI device resource >>> information to firmware? > >I don't think so, no. > >But, given that the previous PciHostBridgeDxe driver was working on Xen, >can we perhaps emulate that behavior in >"OvmfPkg/Library/PciHostBridgeLib" somehow? Let me explain the reason why previous PciHostBridgeDxe driver was working on Xen: The PciRootBridgeIo.Configuration() in new driver only create resource descriptor when the resource status is allocated: if (ResAllocNode->Status != ResAllocated) { continue; } The same function in old driver doesn't check the Status field so it unconditionally returns BUS descriptor with AddrRangeMin and AddrRangeMax both equal 0. So that PciEnumeratorLight() in PciBus driver can still search the devices from starting bus 0. It just happened to work. I think the new driver's Configuration() implementation is correct while the old driver's one is wrong. So I don't want to change to wrong implementation to fix this issue. The issue can be resolved if we have a way to tell PciBus PciEnumeratorLight() which bus number to start searching. It's almost true that starting bus number for root bridge #0 is 0. But it might not be true for the rest root bridges. OVMF's PciHostBridgeLib currently returns multiple root bridges and for root bridge #1, the starting bus number is obviously not 0 unless "etc/extra-pci-roots" doesn't exist or is 0 so there is only one root bridge. My question is in OVMF over Xen, does "etc/extra-pci-roots" exist? If it exists, device behind root bridge #1, #2... can *not* be found with the current implementation. > >Do you think that step (2) above behaves differently between the old and >the new PCI host bridge driver? (Steps (1) and (3) should be identical, >they are initiated by the PCI Bus driver.) > >Thanks >Laszlo > >>> >>> Copying Laszlo. >>> >>> Regards, >>> Ray >>> >>>> -----Original Message----- >>>> From: Gary Lin [mailto:glin@suse.com] >>>> Sent: Wednesday, April 27, 2016 4:27 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 initialisation) >>>> >>>> On Wed, Apr 27, 2016 at 07:18:21AM +0000, Ni, Ruiyu wrote: >>>>> 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(). >>>>> >>>> OK, I ignored PciGetBusRange() and the check of the return status of >>>> Configuration(). Since MinBus is already initialized, I don't bother to >>>> change the value anyway. The change is attached. >>>> >>>> And yes, this time the shell showed. >>>> >>>> Thanks, >>>> >>>> Gary Lin >>>> >>>>> Regards, >>>>> Ray >>>>> >>>>>> -----Original Message----- >>>>>> From: Gary Lin [mailto:glin@suse.com] >>>>>> Sent: Wednesday, April 27, 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 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 <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 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 resource >>>>>>>>> descriptor with MinBus = MaxBus = 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 pass that >>>>>>>>> information to PciHostBridge driver. If no, we also could let PciHostBridgeLib >>>>>>>>> collect the information (IO/MEM/BUS resource assignment) and pass that >>>>>>>>> to PciHostBridgeDxe driver. >>>>>>>>> >>>>>>>>> And we need to have a way to tell PciHostBridgeDxe the resource information >>>>>>>>> passed from PciHostBridgeLib is available resource to assign, or already 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 <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 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 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@suse.com] >>>>>>>>>>> Sent: Tuesday, April 26, 2016 3:35 PM >>>>>>>>>>> To: Ni, Ruiyu <ruiyu.ni@intel.com> >>>>>>>>>>> Cc: Anthony PERARD <anthony.perard@citrix.com>; edk2-devel@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-bounces@lists.01.org] On Behalf Of Anthony PERARD >>>>>>>>>>>>> Sent: Friday, April 22, 2016 10:48 PM >>>>>>>>>>>>> To: edk2-devel@lists.01.org<mailto:edk2-devel@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-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 >>>>>>> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <734D49CCEBEEF84792F5B80ED585239D0DA29FD5@SHSMSX103.ccr.corp.intel.com>]
* Re: [edk2] OVMF broken under Xen (in PCI initialisation) [not found] ` <734D49CCEBEEF84792F5B80ED585239D0DA29FD5@SHSMSX103.ccr.corp.intel.com> @ 2016-04-28 9:12 ` Gary Lin [not found] ` <20160428091209.GL3109@GaryWorkstation> ` (2 subsequent siblings) 3 siblings, 0 replies; 25+ messages in thread From: Gary Lin @ 2016-04-28 9:12 UTC (permalink / raw) To: Ni, Ruiyu Cc: Kinney, Michael D, edk2-devel@lists.01.org, Laszlo Ersek, Xen Devel On Thu, Apr 28, 2016 at 05:08:50AM +0000, Ni, Ruiyu wrote: > > > Regards, > Ray > > >-----Original Message----- > >From: Laszlo Ersek [mailto:lersek@redhat.com] > >Sent: Wednesday, April 27, 2016 6:44 PM > >To: Ni, Ruiyu <ruiyu.ni@intel.com>; Gary Lin <glin@suse.com> > >Cc: edk2-devel@lists.01.org <edk2-devel@ml01.01.org>; Xen Devel <xen-devel@lists.xen.org>; Kinney, Michael D > ><michael.d.kinney@intel.com> > >Subject: Re: [edk2] OVMF broken under Xen (in PCI initialisation) > > > >On 04/27/16 11:50, Ni, Ruiyu wrote: > >> Copying Mike. > >> > >> Regards, > >> Ray > >> > >>> -----Original Message----- > >>> From: Ni, Ruiyu > >>> Sent: Wednesday, April 27, 2016 5:49 PM > >>> To: 'Gary Lin' <glin@suse.com> > >>> Cc: edk2-devel@lists.01.org; Xen Devel <xen-devel@lists.xen.org>; Laszlo Ersek <lersek@redhat.com> > >>> Subject: RE: [edk2] OVMF broken under Xen (in PCI initialisation) > >>> > >>> Gary, > >>> Thanks for the try. > >>> > >>> I now understand why the issue happens. > >>> 1. PciEnumeratorLight() depends on the MinBus returned from > >>> PciRootBridgeIo.Configuration(). > >>> 2. PciRootBridgeIo.Configuration() returns the resource descriptors > >>> initialized by PciHostBridge.NotifyPhase(EfiPciHostBridgeAllocateResources). > >>> 3. PciHostBridge.NotifyPhase(EfiPciHostBridgeAllocateResources) > >>> is not called when PcdPciDisableBusEnumeration is TRUE > >>> > >>> I am thinking about let PciRootBridgeIo.Configuration() returns > >>> the correct resource consumption information even when > >>> PcdPciDisableBusEnumeration is TRUE. > >>> > >>> I can add a new field to PCI_ROOT_BRIDGE structure defined in > >>> MdeModulePkg/Include/Library/PciHostBridgeLib.h to indicate > >>> that the resources filled in PCI_ROOT_BRIDGE.Bus/Io/Mem/ > >>> MemAbove4G/PMem/PMemAbove4G are already assigned > >>> to PCI bus. So that PciRootBridgeIo.Configuration() can return > >>> these value even when > >>> PciHostBridge.NotifyPhase(EfiPciHostBridgeAllocateResources) > >>> is not called due to PcdPciDisableBusEnumeration is TRUE. > > > >Can you use PcdPciDisableBusEnumeration directly for this? > > > >(If you don't like the idea, we could certainly set the new field in > >PCI_ROOT_BRIDGE from the PCD too, in OvmfPkg/Library/PciHostBridgeLib.) > > > >>> Do you know whether Xen passes the PCI device resource > >>> information to firmware? > > > >I don't think so, no. > > > >But, given that the previous PciHostBridgeDxe driver was working on Xen, > >can we perhaps emulate that behavior in > >"OvmfPkg/Library/PciHostBridgeLib" somehow? > > Let me explain the reason why previous PciHostBridgeDxe driver was > working on Xen: > The PciRootBridgeIo.Configuration() in new driver only create resource > descriptor when the resource status is allocated: > > if (ResAllocNode->Status != ResAllocated) { > continue; > } > > The same function in old driver doesn't check the Status field so it > unconditionally returns BUS descriptor with AddrRangeMin and > AddrRangeMax both equal 0. So that PciEnumeratorLight() > in PciBus driver can still search the devices from starting bus 0. > It just happened to work. > > I think the new driver's Configuration() implementation is correct > while the old driver's one is wrong. So I don't want to change to > wrong implementation to fix this issue. > > The issue can be resolved if we have a way to tell PciBus > PciEnumeratorLight() which bus number to start searching. > > It's almost true that starting bus number for root bridge #0 > is 0. But it might not be true for the rest root bridges. > > OVMF's PciHostBridgeLib currently returns multiple root bridges > and for root bridge #1, the starting bus number is obviously > not 0 unless "etc/extra-pci-roots" doesn't exist or is 0 so there is > only one root bridge. > > My question is in OVMF over Xen, does "etc/extra-pci-roots" exist? > If it exists, device behind root bridge #1, #2... can *not* be found > with the current implementation. > From my OVMF/Xen debug log: [...] QemuFwCfg interface not supported. I guess "etc/extra-pci-roots" won't exist in Xen though I can't guarantee it due to my limited experience with Xen. Cheers, Gary Lin > > > > >Do you think that step (2) above behaves differently between the old and > >the new PCI host bridge driver? (Steps (1) and (3) should be identical, > >they are initiated by the PCI Bus driver.) > > > >Thanks > >Laszlo > > > >>> > >>> Copying Laszlo. > >>> > >>> Regards, > >>> Ray > >>> > >>>> -----Original Message----- > >>>> From: Gary Lin [mailto:glin@suse.com] > >>>> Sent: Wednesday, April 27, 2016 4:27 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 initialisation) > >>>> > >>>> On Wed, Apr 27, 2016 at 07:18:21AM +0000, Ni, Ruiyu wrote: > >>>>> 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(). > >>>>> > >>>> OK, I ignored PciGetBusRange() and the check of the return status of > >>>> Configuration(). Since MinBus is already initialized, I don't bother to > >>>> change the value anyway. The change is attached. > >>>> > >>>> And yes, this time the shell showed. > >>>> > >>>> Thanks, > >>>> > >>>> Gary Lin > >>>> > >>>>> Regards, > >>>>> Ray > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Gary Lin [mailto:glin@suse.com] > >>>>>> Sent: Wednesday, April 27, 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 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 <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 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 resource > >>>>>>>>> descriptor with MinBus = MaxBus = 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 pass that > >>>>>>>>> information to PciHostBridge driver. If no, we also could let PciHostBridgeLib > >>>>>>>>> collect the information (IO/MEM/BUS resource assignment) and pass that > >>>>>>>>> to PciHostBridgeDxe driver. > >>>>>>>>> > >>>>>>>>> And we need to have a way to tell PciHostBridgeDxe the resource information > >>>>>>>>> passed from PciHostBridgeLib is available resource to assign, or already 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 <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 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 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@suse.com] > >>>>>>>>>>> Sent: Tuesday, April 26, 2016 3:35 PM > >>>>>>>>>>> To: Ni, Ruiyu <ruiyu.ni@intel.com> > >>>>>>>>>>> Cc: Anthony PERARD <anthony.perard@citrix.com>; edk2-devel@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-bounces@lists.01.org] On Behalf Of Anthony PERARD > >>>>>>>>>>>>> Sent: Friday, April 22, 2016 10:48 PM > >>>>>>>>>>>>> To: edk2-devel@lists.01.org<mailto:edk2-devel@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-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 > >>>>>>> > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <20160428091209.GL3109@GaryWorkstation>]
* Re: [edk2] OVMF broken under Xen (in PCI initialisation) [not found] ` <20160428091209.GL3109@GaryWorkstation> @ 2016-04-28 9:44 ` Andrew Cooper 0 siblings, 0 replies; 25+ messages in thread From: Andrew Cooper @ 2016-04-28 9:44 UTC (permalink / raw) To: Gary Lin, Ni, Ruiyu Cc: Kinney, Michael D, edk2-devel@lists.01.org, Laszlo Ersek, Xen Devel On 28/04/16 10:12, Gary Lin wrote: > On Thu, Apr 28, 2016 at 05:08:50AM +0000, Ni, Ruiyu wrote: >> >> Regards, >> Ray >> >>> -----Original Message----- >>> From: Laszlo Ersek [mailto:lersek@redhat.com] >>> Sent: Wednesday, April 27, 2016 6:44 PM >>> To: Ni, Ruiyu <ruiyu.ni@intel.com>; Gary Lin <glin@suse.com> >>> Cc: edk2-devel@lists.01.org <edk2-devel@ml01.01.org>; Xen Devel <xen-devel@lists.xen.org>; Kinney, Michael D >>> <michael.d.kinney@intel.com> >>> Subject: Re: [edk2] OVMF broken under Xen (in PCI initialisation) >>> >>> On 04/27/16 11:50, Ni, Ruiyu wrote: >>>> Copying Mike. >>>> >>>> Regards, >>>> Ray >>>> >>>>> -----Original Message----- >>>>> From: Ni, Ruiyu >>>>> Sent: Wednesday, April 27, 2016 5:49 PM >>>>> To: 'Gary Lin' <glin@suse.com> >>>>> Cc: edk2-devel@lists.01.org; Xen Devel <xen-devel@lists.xen.org>; Laszlo Ersek <lersek@redhat.com> >>>>> Subject: RE: [edk2] OVMF broken under Xen (in PCI initialisation) >>>>> >>>>> Gary, >>>>> Thanks for the try. >>>>> >>>>> I now understand why the issue happens. >>>>> 1. PciEnumeratorLight() depends on the MinBus returned from >>>>> PciRootBridgeIo.Configuration(). >>>>> 2. PciRootBridgeIo.Configuration() returns the resource descriptors >>>>> initialized by PciHostBridge.NotifyPhase(EfiPciHostBridgeAllocateResources). >>>>> 3. PciHostBridge.NotifyPhase(EfiPciHostBridgeAllocateResources) >>>>> is not called when PcdPciDisableBusEnumeration is TRUE >>>>> >>>>> I am thinking about let PciRootBridgeIo.Configuration() returns >>>>> the correct resource consumption information even when >>>>> PcdPciDisableBusEnumeration is TRUE. >>>>> >>>>> I can add a new field to PCI_ROOT_BRIDGE structure defined in >>>>> MdeModulePkg/Include/Library/PciHostBridgeLib.h to indicate >>>>> that the resources filled in PCI_ROOT_BRIDGE.Bus/Io/Mem/ >>>>> MemAbove4G/PMem/PMemAbove4G are already assigned >>>>> to PCI bus. So that PciRootBridgeIo.Configuration() can return >>>>> these value even when >>>>> PciHostBridge.NotifyPhase(EfiPciHostBridgeAllocateResources) >>>>> is not called due to PcdPciDisableBusEnumeration is TRUE. >>> Can you use PcdPciDisableBusEnumeration directly for this? >>> >>> (If you don't like the idea, we could certainly set the new field in >>> PCI_ROOT_BRIDGE from the PCD too, in OvmfPkg/Library/PciHostBridgeLib.) >>> >>>>> Do you know whether Xen passes the PCI device resource >>>>> information to firmware? >>> I don't think so, no. >>> >>> But, given that the previous PciHostBridgeDxe driver was working on Xen, >>> can we perhaps emulate that behavior in >>> "OvmfPkg/Library/PciHostBridgeLib" somehow? >> Let me explain the reason why previous PciHostBridgeDxe driver was >> working on Xen: >> The PciRootBridgeIo.Configuration() in new driver only create resource >> descriptor when the resource status is allocated: >> >> if (ResAllocNode->Status != ResAllocated) { >> continue; >> } >> >> The same function in old driver doesn't check the Status field so it >> unconditionally returns BUS descriptor with AddrRangeMin and >> AddrRangeMax both equal 0. So that PciEnumeratorLight() >> in PciBus driver can still search the devices from starting bus 0. >> It just happened to work. >> >> I think the new driver's Configuration() implementation is correct >> while the old driver's one is wrong. So I don't want to change to >> wrong implementation to fix this issue. >> >> The issue can be resolved if we have a way to tell PciBus >> PciEnumeratorLight() which bus number to start searching. >> >> It's almost true that starting bus number for root bridge #0 >> is 0. But it might not be true for the rest root bridges. >> >> OVMF's PciHostBridgeLib currently returns multiple root bridges >> and for root bridge #1, the starting bus number is obviously >> not 0 unless "etc/extra-pci-roots" doesn't exist or is 0 so there is >> only one root bridge. >> >> My question is in OVMF over Xen, does "etc/extra-pci-roots" exist? >> If it exists, device behind root bridge #1, #2... can *not* be found >> with the current implementation. >> > From my OVMF/Xen debug log: > [...] > QemuFwCfg interface not supported. > > I guess "etc/extra-pci-roots" won't exist in Xen though I can't > guarantee it due to my limited experience with Xen. Information layout like this in Xen is currently in a dire state. Buses other than bus 0 don't function, there is no MMCONFIG support and BARs only work because access to unpopulated ranges in the physical memory get forwarded to Qemu. There are several related projects planned which will go a long way to untangling this mess, but there is no quick fix. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [edk2] OVMF broken under Xen (in PCI initialisation) [not found] ` <734D49CCEBEEF84792F5B80ED585239D0DA29FD5@SHSMSX103.ccr.corp.intel.com> 2016-04-28 9:12 ` Gary Lin [not found] ` <20160428091209.GL3109@GaryWorkstation> @ 2016-04-28 10:35 ` Laszlo Ersek [not found] ` <5721E77C.7080701@redhat.com> 3 siblings, 0 replies; 25+ messages in thread From: Laszlo Ersek @ 2016-04-28 10:35 UTC (permalink / raw) To: Ni, Ruiyu, Gary Lin; +Cc: Kinney, Michael D, edk2-devel@lists.01.org, Xen Devel On 04/28/16 07:08, Ni, Ruiyu wrote: >>>> Do you know whether Xen passes the PCI device resource >>>> information to firmware? >> >> I don't think so, no. >> >> But, given that the previous PciHostBridgeDxe driver was working on Xen, >> can we perhaps emulate that behavior in >> "OvmfPkg/Library/PciHostBridgeLib" somehow? > > Let me explain the reason why previous PciHostBridgeDxe driver was > working on Xen: > The PciRootBridgeIo.Configuration() in new driver only create resource > descriptor when the resource status is allocated: > > if (ResAllocNode->Status != ResAllocated) { > continue; > } > > The same function in old driver doesn't check the Status field so it > unconditionally returns BUS descriptor with AddrRangeMin and > AddrRangeMax both equal 0. So that PciEnumeratorLight() > in PciBus driver can still search the devices from starting bus 0. > It just happened to work. > > I think the new driver's Configuration() implementation is correct > while the old driver's one is wrong. So I don't want to change to > wrong implementation to fix this issue. Makes sense, thank you for the explanation. > The issue can be resolved if we have a way to tell PciBus > PciEnumeratorLight() which bus number to start searching. > > It's almost true that starting bus number for root bridge #0 > is 0. But it might not be true for the rest root bridges. > > OVMF's PciHostBridgeLib currently returns multiple root bridges > and for root bridge #1, the starting bus number is obviously > not 0 unless "etc/extra-pci-roots" doesn't exist or is 0 so there is > only one root bridge. > > My question is in OVMF over Xen, does "etc/extra-pci-roots" exist? > If it exists, device behind root bridge #1, #2... can *not* be found > with the current implementation. "etc/extra-pci-roots" (more precisely, fw_cfg in general) is specific to QEMU. QemuFwCfgLib runs alright in Xen guests, but whenever you look for an fw_cfg file, it is not found -- which is good behavior. So, OVMF's PciHostBridgeLib produces exactly one PCI_ROOT_BRIDGE object when it runs on Xen. ExtraRootBridges is set to zero, the loop runs zero times, and the one InitRootBridge() call after the loop produces one PCI_ROOT_BRIDGE object, with the following parameters: - Bus.Base = 0 - Bus.Limit = PCI_MAX_BUS Thanks Laszlo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <5721E77C.7080701@redhat.com>]
* Re: [edk2] OVMF broken under Xen (in PCI initialisation) [not found] ` <5721E77C.7080701@redhat.com> @ 2016-05-05 8:03 ` Ni, Ruiyu [not found] ` <734D49CCEBEEF84792F5B80ED585239D0DA479DB@SHSMSX103.ccr.corp.intel.com> 1 sibling, 0 replies; 25+ messages in thread From: Ni, Ruiyu @ 2016-05-05 8:03 UTC (permalink / raw) To: Laszlo Ersek, Gary Lin Cc: Kinney, Michael D, edk2-devel@lists.01.org, Xen Devel Gary, Can you kindly teach me how to run OVMF under Xen? I worked out a draft fix and need to verify whether everything is fine. Regards, Ray >-----Original Message----- >From: Laszlo Ersek [mailto:lersek@redhat.com] >Sent: Thursday, April 28, 2016 6:36 PM >To: Ni, Ruiyu <ruiyu.ni@intel.com>; Gary Lin <glin@suse.com> >Cc: edk2-devel@lists.01.org <edk2-devel@ml01.01.org>; Xen Devel <xen-devel@lists.xen.org>; Kinney, Michael D ><michael.d.kinney@intel.com> >Subject: Re: [edk2] OVMF broken under Xen (in PCI initialisation) > >On 04/28/16 07:08, Ni, Ruiyu wrote: > > >>>>> Do you know whether Xen passes the PCI device resource >>>>> information to firmware? >>> >>> I don't think so, no. >>> >>> But, given that the previous PciHostBridgeDxe driver was working on Xen, >>> can we perhaps emulate that behavior in >>> "OvmfPkg/Library/PciHostBridgeLib" somehow? >> >> Let me explain the reason why previous PciHostBridgeDxe driver was >> working on Xen: >> The PciRootBridgeIo.Configuration() in new driver only create resource >> descriptor when the resource status is allocated: >> >> if (ResAllocNode->Status != ResAllocated) { >> continue; >> } >> >> The same function in old driver doesn't check the Status field so it >> unconditionally returns BUS descriptor with AddrRangeMin and >> AddrRangeMax both equal 0. So that PciEnumeratorLight() >> in PciBus driver can still search the devices from starting bus 0. >> It just happened to work. >> >> I think the new driver's Configuration() implementation is correct >> while the old driver's one is wrong. So I don't want to change to >> wrong implementation to fix this issue. > >Makes sense, thank you for the explanation. > >> The issue can be resolved if we have a way to tell PciBus >> PciEnumeratorLight() which bus number to start searching. >> >> It's almost true that starting bus number for root bridge #0 >> is 0. But it might not be true for the rest root bridges. >> >> OVMF's PciHostBridgeLib currently returns multiple root bridges >> and for root bridge #1, the starting bus number is obviously >> not 0 unless "etc/extra-pci-roots" doesn't exist or is 0 so there is >> only one root bridge. >> >> My question is in OVMF over Xen, does "etc/extra-pci-roots" exist? >> If it exists, device behind root bridge #1, #2... can *not* be found >> with the current implementation. > >"etc/extra-pci-roots" (more precisely, fw_cfg in general) is specific to >QEMU. QemuFwCfgLib runs alright in Xen guests, but whenever you look for >an fw_cfg file, it is not found -- which is good behavior. > >So, OVMF's PciHostBridgeLib produces exactly one PCI_ROOT_BRIDGE object >when it runs on Xen. ExtraRootBridges is set to zero, the loop runs zero >times, and the one InitRootBridge() call after the loop produces one >PCI_ROOT_BRIDGE object, with the following parameters: >- Bus.Base = 0 >- Bus.Limit = PCI_MAX_BUS > >Thanks >Laszlo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <734D49CCEBEEF84792F5B80ED585239D0DA479DB@SHSMSX103.ccr.corp.intel.com>]
* Re: [edk2] OVMF broken under Xen (in PCI initialisation) [not found] ` <734D49CCEBEEF84792F5B80ED585239D0DA479DB@SHSMSX103.ccr.corp.intel.com> @ 2016-05-05 9:12 ` Wei Liu 2016-05-05 9:22 ` Gary Lin 1 sibling, 0 replies; 25+ messages in thread From: Wei Liu @ 2016-05-05 9:12 UTC (permalink / raw) To: Ni, Ruiyu Cc: Wei Liu, edk2-devel@lists.01.org, Xen Devel, Anthony PERARD, Gary Lin, Kinney, Michael D, Laszlo Ersek On Thu, May 05, 2016 at 08:03:05AM +0000, Ni, Ruiyu wrote: > Gary, > Can you kindly teach me how to run OVMF under Xen? > > I worked out a draft fix and need to verify whether > everything is fine. > Currently you need to build Xen's hvmloader, which will embed a OVMF binary inside it. These are some rough steps: 1. git clone xen.git from xenbits.xen.org 2. cd xen.git, create a .config file, which contains lines: OVMF_UPSTREAM_URL = /path/to/your/ovmf/tree OVMF_UPSTREAM_REVISION = $OVMF_REVISION 3. run ./configure --enable-ovmf 4. make dist -- you will get everything built in dist directory Depending whether you have a working xen system or not, you might want to either 1. install the xen system you just built. or 1. get the hvmloader binary from dist/install/usr/local/lib/xen/boot 2. copy that to your working xen system Feel free to ask questions. As a side note, your ovmf will be cloned into tools/firmware/ directory, you can check if xen is really building the commit you want there. It's a bit cumbersome at the moment. Hopefully this will change in the next release -- Anthony has a series to let you provide a firmware binary directly. Wei. > Regards, > Ray > > >-----Original Message----- > >From: Laszlo Ersek [mailto:lersek@redhat.com] > >Sent: Thursday, April 28, 2016 6:36 PM > >To: Ni, Ruiyu <ruiyu.ni@intel.com>; Gary Lin <glin@suse.com> > >Cc: edk2-devel@lists.01.org <edk2-devel@ml01.01.org>; Xen Devel <xen-devel@lists.xen.org>; Kinney, Michael D > ><michael.d.kinney@intel.com> > >Subject: Re: [edk2] OVMF broken under Xen (in PCI initialisation) > > > >On 04/28/16 07:08, Ni, Ruiyu wrote: > > > > > >>>>> Do you know whether Xen passes the PCI device resource > >>>>> information to firmware? > >>> > >>> I don't think so, no. > >>> > >>> But, given that the previous PciHostBridgeDxe driver was working on Xen, > >>> can we perhaps emulate that behavior in > >>> "OvmfPkg/Library/PciHostBridgeLib" somehow? > >> > >> Let me explain the reason why previous PciHostBridgeDxe driver was > >> working on Xen: > >> The PciRootBridgeIo.Configuration() in new driver only create resource > >> descriptor when the resource status is allocated: > >> > >> if (ResAllocNode->Status != ResAllocated) { > >> continue; > >> } > >> > >> The same function in old driver doesn't check the Status field so it > >> unconditionally returns BUS descriptor with AddrRangeMin and > >> AddrRangeMax both equal 0. So that PciEnumeratorLight() > >> in PciBus driver can still search the devices from starting bus 0. > >> It just happened to work. > >> > >> I think the new driver's Configuration() implementation is correct > >> while the old driver's one is wrong. So I don't want to change to > >> wrong implementation to fix this issue. > > > >Makes sense, thank you for the explanation. > > > >> The issue can be resolved if we have a way to tell PciBus > >> PciEnumeratorLight() which bus number to start searching. > >> > >> It's almost true that starting bus number for root bridge #0 > >> is 0. But it might not be true for the rest root bridges. > >> > >> OVMF's PciHostBridgeLib currently returns multiple root bridges > >> and for root bridge #1, the starting bus number is obviously > >> not 0 unless "etc/extra-pci-roots" doesn't exist or is 0 so there is > >> only one root bridge. > >> > >> My question is in OVMF over Xen, does "etc/extra-pci-roots" exist? > >> If it exists, device behind root bridge #1, #2... can *not* be found > >> with the current implementation. > > > >"etc/extra-pci-roots" (more precisely, fw_cfg in general) is specific to > >QEMU. QemuFwCfgLib runs alright in Xen guests, but whenever you look for > >an fw_cfg file, it is not found -- which is good behavior. > > > >So, OVMF's PciHostBridgeLib produces exactly one PCI_ROOT_BRIDGE object > >when it runs on Xen. ExtraRootBridges is set to zero, the loop runs zero > >times, and the one InitRootBridge() call after the loop produces one > >PCI_ROOT_BRIDGE object, with the following parameters: > >- Bus.Base = 0 > >- Bus.Limit = PCI_MAX_BUS > > > >Thanks > >Laszlo > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [edk2] OVMF broken under Xen (in PCI initialisation) [not found] ` <734D49CCEBEEF84792F5B80ED585239D0DA479DB@SHSMSX103.ccr.corp.intel.com> 2016-05-05 9:12 ` Wei Liu @ 2016-05-05 9:22 ` Gary Lin 1 sibling, 0 replies; 25+ messages in thread From: Gary Lin @ 2016-05-05 9:22 UTC (permalink / raw) To: Ni, Ruiyu Cc: Kinney, Michael D, edk2-devel@lists.01.org, Laszlo Ersek, Xen Devel On Thu, May 05, 2016 at 08:03:05AM +0000, Ni, Ruiyu wrote: > Gary, > Can you kindly teach me how to run OVMF under Xen? > > I worked out a draft fix and need to verify whether > everything is fine. > Hi Ray, 1. Install the Xen host. I use openSUSE Leap 42.1 as the host system and it's available in https://software.opensuse.org/421/ Just download the iso file and burn the DVD or make a live USB as mentioned here: https://en.opensuse.org/Live_USB_stick BTW, I encountered some problem with my test machine (an old HP notebook) when booting the Xen kernel. Swithcing from UEFI to legacy mode works for me. 2. After installing the base system, add the Virtualization repo to get the latest xen packages. $ wget http://download.opensuse.org/repositories/Virtualization/openSUSE_Leap_42.1/Virtualization.repo $ sudo cp Virtualization.repo /etc/zypp/repos.d/ $ sudo zypper ref 3. Follow the steps to install Xen server with YaST: https://tr.opensuse.org/How_to_Install_a_Xen_VM_Server You don't need to create the grub2 entry since yast already takes care of it. Use 'rpm -qi xen-tools' to make sure xen-tools >= 4.7.0 is installed. 4. Reboot the system to the Xen kernel. You will see a Xen entry on the grub2 menu. Choose the entry to boot Domain0. 5. Now you have a xen server, the next is the config for HVM guest. Here is my config: builder = 'hvm' name = 'xen-test' vcpus = 2 memory = 1024 disk = ['/home/linux/VM/xen-test.qcow2,qcow2,xvda,w', 'file:/home/linux/iso/opensuse-42.1.iso,hdc:cdrom,r'] on_poweroff="destroy" on_reboot="destroy" on_crash="destroy" sdl=1 bios='ovmf' bios_override='/home/linux/git/edk2/Build/OvmfX64/DEBUG_GCC48/FV/OVMF.fd' device_model_args = ["-debugcon", "file:debug.log", "-global", "isa-debugcon.iobase=0x402"] Just create a config file such as xen-test.cfg and add the options. The qcow2 and iso are only necessary if you want to install a guest OS. Please modify the path of "bios_override" according to your setup. BTW, the parameters in "device_model_args" will direct the OVMF debug message to debug.log. It's useful for debugging. 6. Build your own OVMF. In case you need any package to build OVMF, try $ sudo zypper in <package name> to install the package or search the package with $ sudo zypper se <package name> 7. Start the HVM guest as root. # xl create xen-test.cfg 8. Destroy the HVM guest. The instance won't be destroyed automatically after closing the sdl window. You have to destroy the instance manually. # xl destroy <name in cfg> In my case, it's # xl destroy xen-test Let me know if you need more information to setup xen server/guest :) Thanks, Gary Lin > Regards, > Ray > > >-----Original Message----- > >From: Laszlo Ersek [mailto:lersek@redhat.com] > >Sent: Thursday, April 28, 2016 6:36 PM > >To: Ni, Ruiyu <ruiyu.ni@intel.com>; Gary Lin <glin@suse.com> > >Cc: edk2-devel@lists.01.org <edk2-devel@ml01.01.org>; Xen Devel <xen-devel@lists.xen.org>; Kinney, Michael D > ><michael.d.kinney@intel.com> > >Subject: Re: [edk2] OVMF broken under Xen (in PCI initialisation) > > > >On 04/28/16 07:08, Ni, Ruiyu wrote: > > > > > >>>>> Do you know whether Xen passes the PCI device resource > >>>>> information to firmware? > >>> > >>> I don't think so, no. > >>> > >>> But, given that the previous PciHostBridgeDxe driver was working on Xen, > >>> can we perhaps emulate that behavior in > >>> "OvmfPkg/Library/PciHostBridgeLib" somehow? > >> > >> Let me explain the reason why previous PciHostBridgeDxe driver was > >> working on Xen: > >> The PciRootBridgeIo.Configuration() in new driver only create resource > >> descriptor when the resource status is allocated: > >> > >> if (ResAllocNode->Status != ResAllocated) { > >> continue; > >> } > >> > >> The same function in old driver doesn't check the Status field so it > >> unconditionally returns BUS descriptor with AddrRangeMin and > >> AddrRangeMax both equal 0. So that PciEnumeratorLight() > >> in PciBus driver can still search the devices from starting bus 0. > >> It just happened to work. > >> > >> I think the new driver's Configuration() implementation is correct > >> while the old driver's one is wrong. So I don't want to change to > >> wrong implementation to fix this issue. > > > >Makes sense, thank you for the explanation. > > > >> The issue can be resolved if we have a way to tell PciBus > >> PciEnumeratorLight() which bus number to start searching. > >> > >> It's almost true that starting bus number for root bridge #0 > >> is 0. But it might not be true for the rest root bridges. > >> > >> OVMF's PciHostBridgeLib currently returns multiple root bridges > >> and for root bridge #1, the starting bus number is obviously > >> not 0 unless "etc/extra-pci-roots" doesn't exist or is 0 so there is > >> only one root bridge. > >> > >> My question is in OVMF over Xen, does "etc/extra-pci-roots" exist? > >> If it exists, device behind root bridge #1, #2... can *not* be found > >> with the current implementation. > > > >"etc/extra-pci-roots" (more precisely, fw_cfg in general) is specific to > >QEMU. QemuFwCfgLib runs alright in Xen guests, but whenever you look for > >an fw_cfg file, it is not found -- which is good behavior. > > > >So, OVMF's PciHostBridgeLib produces exactly one PCI_ROOT_BRIDGE object > >when it runs on Xen. ExtraRootBridges is set to zero, the loop runs zero > >times, and the one InitRootBridge() call after the loop produces one > >PCI_ROOT_BRIDGE object, with the following parameters: > >- Bus.Base = 0 > >- Bus.Limit = PCI_MAX_BUS > > > >Thanks > >Laszlo > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [edk2] OVMF broken under Xen (in PCI initialisation) [not found] ` <20160426073529.GC3109@GaryWorkstation> 2016-04-26 8:19 ` Ni, Ruiyu [not found] ` <734D49CCEBEEF84792F5B80ED585239D0DA25B98@SHSMSX103.ccr.corp.intel.com> @ 2016-04-26 9:31 ` Andrew Cooper 2016-04-26 10:03 ` Gary Lin 2 siblings, 1 reply; 25+ messages in thread From: Andrew Cooper @ 2016-04-26 9:31 UTC (permalink / raw) To: Gary Lin, Ni, Ruiyu; +Cc: Anthony PERARD, edk2-devel, Xen Devel > 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 :-( You can use gdbsx (from tools/debugger/gdbsx in the Xen tree) which acts like gdbserver. (It is very rough around the edges, but does function.) ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [edk2] OVMF broken under Xen (in PCI initialisation) 2016-04-26 9:31 ` Andrew Cooper @ 2016-04-26 10:03 ` Gary Lin 0 siblings, 0 replies; 25+ messages in thread From: Gary Lin @ 2016-04-26 10:03 UTC (permalink / raw) To: Andrew Cooper; +Cc: Ni, Ruiyu, Anthony PERARD, edk2-devel, Xen Devel On Tue, Apr 26, 2016 at 10:31:22AM +0100, Andrew Cooper wrote: > > > 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 :-( > > You can use gdbsx (from tools/debugger/gdbsx in the Xen tree) which acts > like gdbserver. (It is very rough around the edges, but does function.) > Thanks for the hint! Now I got the backtrace: Program received signal SIGINT, Interrupt. 0x000000003f539cd2 in CpuSleep () (gdb) bt #0 0x000000003f539cd2 in CpuSleep () #1 0x000000003f5359fc in IdleLoopEventCallback (Event=0x3eea8dd8, Context=0x0) at /home/linux/git/edk2/UefiCpuPkg/CpuDxe/CpuDxe.c:852 #2 0x000000003f66a9b2 in CoreDispatchEventNotifies (Priority=16) at /home/linux/git/edk2/MdeModulePkg/Core/Dxe/Event/Event.c:200 #3 0x000000003f66a007 in CoreRestoreTpl (NewTpl=4) at /home/linux/git/edk2/MdeModulePkg/Core/Dxe/Event/Tpl.c:131 #4 0x000000003f6581c3 in CoreReleaseLock (Lock=0x3f688d70) at /home/linux/git/edk2/MdeModulePkg/Core/Dxe/Library/Library.c:102 #5 0x000000003f66a78d in CoreReleaseEventLock () at /home/linux/git/edk2/MdeModulePkg/Core/Dxe/Event/Event.c:119 #6 0x000000003f66abf9 in CoreNotifySignalList (EventGroup=0x3f404ad0) at /home/linux/git/edk2/MdeModulePkg/Core/Dxe/Event/Event.c:276 #7 0x000000003f66b08d in CoreSignalEvent (UserEvent=0x3f404a98) at /home/linux/git/edk2/MdeModulePkg/Core/Dxe/Event/Event.c:564 #8 0x000000003f66b2c4 in CoreWaitForEvent (NumberOfEvents=1, UserEvents=0x3e3e2060, UserIndex=0x3f64c848) at /home/linux/git/edk2/MdeModulePkg/Core/Dxe/Event/Event.c:705 #9 0x000000003e052317 in FileInterfaceStdInRead (This=0x3e16b700, BufferSize=0x3f64ca00, Buffer=0x3e8d3018) at /home/linux/git/edk2/ShellPkg/Application/Shell/FileHandleWrappers.c:422 #10 0x000000003e062372 in FileHandleRead (FileHandle=0x3e16b700, BufferSize=0x3f64ca00, Buffer=0x3e8d3018) at /home/linux/git/edk2/MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.c:179 #11 0x000000003e04374e in DoShellPrompt () at /home/linux/git/edk2/ShellPkg/Application/Shell/Shell.c:1278 #12 0x000000003e041d0e in UefiMain (ImageHandle=0x3ea58b18, SystemTable=0x3f5d9018) at /home/linux/git/edk2/ShellPkg/Application/Shell/Shell.c:634 #13 0x000000003e040492 in ProcessModuleEntryPointList (ImageHandle=0x3ea58b18, SystemTable=0x3f5d9018) at /home/linux/git/edk2/Build/OvmfX64/DEBUG_GCC48/X64/ShellPkg/Application/Shell/Shell/DEBUG/AutoGen.c:834 #14 0x000000003e03f2b1 in _ModuleEntryPoint (ImageHandle=0x3ea58b18, SystemTable=0x3f5d9018) at /home/linux/git/edk2/MdePkg/Library/UefiApplicationEntryPoint/ApplicationEntryPoint.c:65 #15 0x000000003f653791 in CoreStartImage (ImageHandle=0x3ea58b18, ExitDataSize=0x3f64cd38, ExitData=0x3f64cd30) at /home/linux/git/edk2/MdeModulePkg/Core/Dxe/Image/Image.c:1661 #16 0x000000003f442fbc in BdsLibBootViaBootOption (Option=0x3ea63718, DevicePath=0x3ea58018, ExitDataSize=0x3f64cd38, ExitData=0x3f64cd30) at /home/linux/git/edk2/IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c:2436 #17 0x000000003f4130a3 in BdsBootDeviceSelect () at /home/linux/git/edk2/IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c:286 #18 0x000000003f413c1a in BdsEntry (This=0x3f45fe00) at /home/linux/git/edk2/IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c:659 #19 0x000000003f64e96a in DxeMain (HobStart=0x3f402018) at /home/linux/git/edk2/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c:518 #20 0x000000003f64d71d in ProcessModuleEntryPointList (HobStart=0x3b6ce000) at /home/linux/git/edk2/Build/OvmfX64/DEBUG_GCC48/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/AutoGen.c:414 #21 0x000000003f64d26d in _ModuleEntryPoint (HobStart=0x3b6ce000) at /home/linux/git/edk2/MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.c:54 #22 0x0000000000000000 in ?? () (gdb) The shell was waiting for the keystroke so it actually worked as expected. However, the shell UI didn't show in either serial console or the vncviewer. Gary Lin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2016-05-05 9:22 UTC | newest] Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <20160422144736.GD1885@perard.uk.xensource.com> 2016-04-25 11:43 ` [edk2] OVMF broken under Xen (in PCI initialisation) Laszlo Ersek [not found] ` <571E02C5.1000906@redhat.com> 2016-04-26 6:29 ` Gary Lin [not found] ` <20160426062914.GB3109@GaryWorkstation> 2016-04-26 6:45 ` Ni, Ruiyu 2016-04-26 6:43 ` Ni, Ruiyu [not found] ` <734D49CCEBEEF84792F5B80ED585239D0DA25884@SHSMSX103.ccr.corp.intel.com> 2016-04-26 7:35 ` Gary Lin [not found] ` <20160426073529.GC3109@GaryWorkstation> 2016-04-26 8:19 ` Ni, Ruiyu [not found] ` <734D49CCEBEEF84792F5B80ED585239D0DA25B98@SHSMSX103.ccr.corp.intel.com> 2016-04-26 8:40 ` Gary Lin [not found] ` <20160426084000.GD3109@GaryWorkstation> 2016-04-26 9:40 ` Ni, Ruiyu [not found] ` <734D49CCEBEEF84792F5B80ED585239D0DA25D38@SHSMSX103.ccr.corp.intel.com> 2016-04-27 4:29 ` Gary Lin [not found] ` <20160427042907.GH3109@GaryWorkstation> 2016-04-27 5:39 ` Ni, Ruiyu [not found] ` <734D49CCEBEEF84792F5B80ED585239D0DA27D1E@SHSMSX103.ccr.corp.intel.com> 2016-04-27 6:54 ` Gary Lin [not found] ` <20160427065428.GJ3109@GaryWorkstation> 2016-04-27 7:18 ` Ni, Ruiyu [not found] ` <734D49CCEBEEF84792F5B80ED585239D0DA27F59@SHSMSX103.ccr.corp.intel.com> 2016-04-27 8:26 ` Gary Lin [not found] ` <20160427082641.GK3109@GaryWorkstation> 2016-04-27 9:48 ` Ni, Ruiyu 2016-04-27 9:50 ` Ni, Ruiyu [not found] ` <734D49CCEBEEF84792F5B80ED585239D0DA291E5@SHSMSX103.ccr.corp.intel.com> 2016-04-27 10:43 ` Laszlo Ersek [not found] ` <572097E4.1070300@redhat.com> 2016-04-28 5:08 ` Ni, Ruiyu [not found] ` <734D49CCEBEEF84792F5B80ED585239D0DA29FD5@SHSMSX103.ccr.corp.intel.com> 2016-04-28 9:12 ` Gary Lin [not found] ` <20160428091209.GL3109@GaryWorkstation> 2016-04-28 9:44 ` Andrew Cooper 2016-04-28 10:35 ` Laszlo Ersek [not found] ` <5721E77C.7080701@redhat.com> 2016-05-05 8:03 ` Ni, Ruiyu [not found] ` <734D49CCEBEEF84792F5B80ED585239D0DA479DB@SHSMSX103.ccr.corp.intel.com> 2016-05-05 9:12 ` Wei Liu 2016-05-05 9:22 ` Gary Lin 2016-04-26 9:31 ` Andrew Cooper 2016-04-26 10:03 ` Gary Lin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).