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: Wed, 18 Mar 2015 09:35:47 +0530 Message-ID: <5508F99B.2000005@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> <5507BB18.2020406@caviumnetworks.com> <5507E59C020000780006A901@mail.emea.novell.com> <550818D1.6040401@caviumnetworks.com> <55082C97020000780006AD14@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55082C97020000780006AD14@mail.emea.novell.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: Jan Beulich Cc: Prasun.kapoor@cavium.com, Ian Campbell , Stefano Stabellini , Vijaya Kumar , Julien Grall , xen-devel@lists.xen.org, "StefanoStabellini(Stefano.Stabellini@citrix.com)" List-Id: xen-devel@lists.xenproject.org On Tuesday 17 March 2015 06:01 PM, Jan Beulich wrote: >>>> On 17.03.15 at 13:06, wrote: >> On Tuesday 17 March 2015 12:58 PM, Jan Beulich wrote: >>>>>> On 17.03.15 at 06:26, wrote: >>>> 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 ? >>> I'm pretty sure (a) would even be refused by the maintainers, unless >>> there already is a notification being sent. As to (b) - kernel code could >>> keep track of which segment/bus pairs it informed Xen about, and >>> hence wouldn't even need to wait for an error to be returned from >>> the device-add request (which in your proposal would need to be re- >>> issued after the host-bridge-add). >> Have a query on the CFG space address to be passed as hypercall parameter. >> The of_pci_get_host_bridge_resource only parses the ranges property and >> not reg. >> reg property has the CFG space address, which is usually stored in >> private pci host controller driver structures. >> >> so pci_dev 's parent pci_bus would not have that info. >> One way is to add a method in struct pci_ops but not sure it will be >> accepted or not. > I'm afraid I don't understand what you're trying to tell me. Hi Jan, I missed this during initial discussion and found out while coding that CFG Space address of a pci host is stored in the reg property and the of_pci code dos not store reg in the resources only ranges are stored. So the pci_bus which is the rootbus created in the probe function of the pcie controller driver will have ranges values in resources but reg property value (CFG space address) in the private data. So from drivers/xen/pci.c we can find out the root bus (pci_bus) from the pci_dev (via BUS_NOTIFY) but cannot get the CFG space address. Now there are 2 ways a) Add a pci_ops to return the CFG space address b) Let the pci host controller driver invoke a function xen_invoke_hypercall () providing bus number and cfg_space address. xen_invoke_hypercall would be implemented in drivers/xen/pci.c and would issue PHYSDEVOP_pci_host_bridge_add hypercall > Jan > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel