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

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

[Laszlo Ersek]

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

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

[Gary Lin]

[-- 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

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

[Ni, Ruiyu]

[-- 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

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

[Ni, Ruiyu]

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

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

[Gary Lin]

[-- 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

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

[Ni, Ruiyu]

[-- 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

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

[Gary Lin]

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

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

[Ni, Ruiyu]

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

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

[Gary Lin]

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

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

[Ni, Ruiyu]

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

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

[Gary Lin]

[-- 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

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

[Ni, Ruiyu]

[-- 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

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

[Gary Lin]

[-- 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

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

[Ni, Ruiyu]

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

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

[Ni, Ruiyu]

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

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

[Laszlo Ersek]

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

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

[Ni, Ruiyu]

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

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

[Gary Lin]

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

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

[Andrew Cooper]

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

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

[Laszlo Ersek]

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

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

[Ni, Ruiyu]

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

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

[Wei Liu]

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

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

[Gary Lin]

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

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

[Andrew Cooper]

> 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

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

[Gary Lin]

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