[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.


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

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.