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

["Ni, Ruiyu" <ruiyu.ni@xxxxxxxxx>]

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@xxxxxxxxxx]
>Sent: Thursday, April 28, 2016 6:36 PM
>To: Ni, Ruiyu <ruiyu.ni@xxxxxxxxx>; Gary Lin <glin@xxxxxxxx>
>Cc: edk2-devel@xxxxxxxxxxxx <edk2-devel@xxxxxxxxxxx>; Xen Devel 
><xen-devel@xxxxxxxxxxxxx>; Kinney, Michael D
><michael.d.kinney@xxxxxxxxx>
>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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel