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: Fri, 20 Feb 2015 19:44:13 +0530 Message-ID: <54E74135.4040302@caviumnetworks.com> References: <54E71BDE.5020106@caviumnetworks.com> <54E7229C.7000301@linaro.org> <54E72452.3090801@caviumnetworks.com> <54E72688.9010005@linaro.org> <54E729F1.6000804@caviumnetworks.com> <54E73010.2050902@caviumnetworks.com> <1424439941.30924.243.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: <1424439941.30924.243.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, "Kumar, Vijaya" , Julien Grall , xen-devel@lists.xen.org, "Stefano Stabellini (Stefano.Stabellini@citrix.com)" , Jan Beulich List-Id: xen-devel@lists.xenproject.org On 20/02/15 7:15 pm, Ian Campbell wrote: > (Jan, curious if you have any thoughts on this, hopefully I've left > sufficient context for you to get what we are on about, the gist is we > need some way for dom0 and Xen to agree on how a PCI segment ID maps to > an actual PCI root controller, I think on x86 you either Just Know from > PC legacy or ACPI tells you?) > > On Fri, 2015-02-20 at 18:31 +0530, Manish Jaggi wrote: >> I have added ABI that segment no maps to the position on pci node in xen >> device tree. We had partially discussed about this during Linaro >> connect. What is your teams view on this, should this be ok or we >> introduce a property in device tree pci node {xen_segment_id = <1>} > The DT node ordering cannot be relied on this way, so we certainly need > something else. > > Ideally we should find a solution which doesn't require new properties. > > The best solution would be to find some existing property of the PCI > host controller which is well defined and unique to each host > controller. I had been thinking that the base address of the PCI CFG > space might be a good enough handle. > > The only question is whether the data type used for segment id in the > hypercall ABI is wide enough for this, and it seems to be u16 :-(. I'm > not sure if we are going to be able to make this pci_segment_t and have > it differ for ARM. > > Another option might be a new hypercall (assuming one doesn't already > exist) to register a PCI bus which would take e.g. the PCI CFG base > address and return a new u16 segment id to be used for all subsequent > PCI related calls. This would require the dom0 OS to hook its > pci_bus_add function, which might be doable (more doable than handling > xen_segment_id DT properties I think). This seems ok, i will try it out. > > I'm not sure if this ends up being different on ACPI, where perhaps > MMCONFIG or some other table actually gives us a segment ID for each PCI > bus. Ideally whatever solution we end up with would fit into this model. > > Ian. >