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, 3 Mar 2015 14:49:52 +0530 Message-ID: <54F57CB8.1040005@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> <1425296899.1886.43.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: <1425296899.1886.43.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 Cc: prasun.kapoor@cavium.com, Stefano Stabellini , Vijaya Kumar , Julien Grall , xen-devel@lists.xen.org, "StefanoStabellini(Stefano.Stabellini@citrix.com)" , Jan Beulich List-Id: xen-devel@lists.xenproject.org On Monday 02 March 2015 05:18 PM, Ian Campbell wrote: > On Fri, 2015-02-27 at 17:15 +0000, Stefano Stabellini wrote: >> On Fri, 27 Feb 2015, 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. >> Although I understand now that PHYSDEVOP_pci_mmcfg_reserved was >> intendend for passing down firmware information to Xen, as the >> information that we need is exactly the same, I think it would be >> acceptable to use the same hypercall on ARM too. > I strongly disagree, they have very different semantics and overloading > the existing interface would be both wrong and confusing. > > It'll also make things harder in the ACPI case where we want to use the > existing hypercall for its original purpose (to propagate MCFG > information to Xen). > >> I am not hard set on this and the new hypercall is also a viable option. >> However If we do introduce a new hypercall as Ian suggested, do we need >> to take into account the possibility that an host bridge might have >> multiple cfg memory ranges? > I don't believe so, a host bridge has a 1:1 relationship with CFG space. > > Ian. > I agree with this flow. It fits into what we have implemented at our end. > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel