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