All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Gary Lin <glin@suse.com>, "Ni, Ruiyu" <ruiyu.ni@intel.com>
Cc: "Kinney, Michael D" <michael.d.kinney@intel.com>,
	"edk2-devel@lists.01.org" <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)
Date: Thu, 28 Apr 2016 10:44:02 +0100	[thread overview]
Message-ID: <5721DB62.3020008@citrix.com> (raw)
In-Reply-To: <20160428091209.GL3109@GaryWorkstation>

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

  parent reply	other threads:[~2016-04-28  9:44 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5721DB62.3020008@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=edk2-devel@ml01.01.org \
    --cc=glin@suse.com \
    --cc=lersek@redhat.com \
    --cc=michael.d.kinney@intel.com \
    --cc=ruiyu.ni@intel.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.