From mboxrd@z Thu Jan 1 00:00:00 1970 From: Manish Jaggi Subject: Re: RFC: [PATCH 1/3] Enhance platform support for PCI Date: Tue, 17 Mar 2015 10:56:48 +0530 Message-ID: <5507BB18.2020406@caviumnetworks.com> References: <1425048166.14641.217.camel@citrix.com> <1425050679.14641.233.camel@citrix.com> <54F0AAF80200007800064BE4@mail.emea.novell.com> <1425055836.14641.256.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1425055836.14641.256.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell , Jan Beulich Cc: Prasun.kapoor@cavium.com, Stefano Stabellini , Vijaya Kumar , Julien Grall , xen-devel@lists.xen.org, "StefanoStabellini(Stefano.Stabellini@citrix.com)" List-Id: xen-devel@lists.xenproject.org On Friday 27 February 2015 10:20 PM, Ian Campbell wrote: > On Fri, 2015-02-27 at 16:35 +0000, Jan Beulich wrote: >>>>> On 27.02.15 at 16:24, wrote: >>> On Fri, 2015-02-27 at 14:54 +0000, Stefano Stabellini wrote: >>>> MMCFG is a Linux config option, not to be confused with >>>> PHYSDEVOP_pci_mmcfg_reserved that is a Xen hypercall interface. I don't >>>> think that the way Linux (or FreeBSD) call PHYSDEVOP_pci_mmcfg_reserved >>>> is relevant. >>> My (possibly flawed) understanding was that pci_mmcfg_reserved was >>> intended to propagate the result of dom0 parsing some firmware table or >>> other to the hypevisor. >> That's not flawed at all. > I think that's a first in this thread ;-) > >>> In Linux dom0 we call it walking pci_mmcfg_list, which looking at >>> arch/x86/pci/mmconfig-shared.c pci_parse_mcfg is populated by walking >>> over a "struct acpi_table_mcfg" (there also appears to be a bunch of >>> processor family derived entries, which I guess are "quirks" of some >>> sort). >> Right - this parses ACPI tables (plus applies some knowledge about >> certain specific systems/chipsets/CPUs) and verifies that the space >> needed for the MMCFG region is properly reserved either in E820 or >> in the ACPI specified resources (only if so Linux decides to use >> MMCFG and consequently also tells Xen that it may use it). > Thanks. > > So I think what I wrote in <1424948710.14641.25.camel@citrix.com> > applies as is to Device Tree based ARM devices, including the need for > the PHYSDEVOP_pci_host_bridge_add call. > > On ACPI based devices we will have the MCFG table, and things follow > much as for x86: > > * Xen should parse MCFG to discover the PCI host-bridges > * Dom0 should do likewise and call PHYSDEVOP_pci_mmcfg_reserved in > the same way as Xen/x86 does. > > The SBSA, an ARM standard for "servers", mandates various things which > we can rely on here because ACPI on ARM requires an SBSA compliant > system. So things like odd quirks in PCI controllers or magic setup are > spec'd out of our zone of caring (into the firmware I suppose), hence > there is nothing like the DT_DEVICE_START stuff to register specific > drivers etc. > > The PHYSDEVOP_pci_host_bridge_add call is not AFAICT needed on ACPI ARM > systems (any more than it is on x86). We can decide whether to omit it > from dom0 or ignore it from Xen later on. > > (Manish, this is FYI, I don't expect you to implement ACPI support!) In drivers/xen/pci.c on notification BUS_NOTIFY_ADD_DEVICE dom0 issues a hypercall to inform xen that a new pci device has been added. If we were to inform xen about a new pci bus that is added there are 2 ways a) Issue the hypercall from drivers/pci/probe.c b) When a new device is found (BUS_NOTIFY_ADD_DEVICE) issue PHYSDEVOP_pci_device_add hypercall to xen, if xen does not finds that segment number (s_bdf), it will return an error SEG_NO_NOT_FOUND. After that the linux xen code could issue the PHYSDEVOP_pci_host_bridge_add hypercall. I think (b) can be done with minimal code changes. What do you think ? > Ian. > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel