From mboxrd@z Thu Jan 1 00:00:00 1970 From: Manish Jaggi Subject: Re: PCI Pass-through in Xen ARM - Draft 2. Date: Fri, 31 Jul 2015 16:37:16 +0530 Message-ID: <55BB56E4.2030700@caviumnetworks.com> References: <55903F12.7010908@caviumnetworks.com> <55911E66.2040009@citrix.com> <5598C6CD.2040207@caviumnetworks.com> <1436173886.25646.24.camel@citrix.com> <559A532F.50305@caviumnetworks.com> <1436178036.25646.28.camel@citrix.com> <55B89ED5.4040904@caviumnetworks.com> <1438250078.11600.272.camel@citrix.com> <55BA1DB5.7090102@caviumnetworks.com> <1438267154.11600.357.camel@citrix.com> <55BB27DF.2090509@caviumnetworks.com> <1438329920.30740.14.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: <1438329920.30740.14.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 , "Kumar, Vijaya" , "xen-devel@lists.xen.org" , Julien Grall , Stefano Stabellini , "Kulkarni, Ganapatrao" List-Id: xen-devel@lists.xenproject.org On Friday 31 July 2015 01:35 PM, Ian Campbell wrote: > On Fri, 2015-07-31 at 13:16 +0530, Manish Jaggi wrote: >>>> Secondly, the vdev-X entry is created async by dom0 watching on >>>> event. >>>> So how the tools could read back and call assign device again. >>> Perhaps by using a xenstore watch on that node to wait for the >>> assignment >>> from pciback to occur. >> As per the flow in the do_pci_add function, assign_device is called >> first and based on the success xenstore entry is created. >> Are you suggesting to change the sequence. > Perhaps that is what it would take, yes, or maybe some other refactoring > (e.g. splitting assign_device into two stages) might be the answer. The hypercall from xenpciback (what I implemented) is actually making the assign device in 2 stages. I think the point of contention is the second stage should be from toolstack. I think calling xc_assign_device after xenstore from the watch callback is the only option. One question is how to split the code for ARM and x86 as this is the common code. Would #ifdef CONFIG_ARM64 ok with maintainers. > > My current preference is for the suggestion below which is to let the > toolstack pick the vdevfn and have pciback honour it. That would duplicate code for dev-fn generation into toolstack from __xen_pcibk_add_pci_dev. >> We can discuss this more on #xenarm irc > Sorry I missed your ping yesterday, I had already gone home. > >>>>> Or you could change things such that vdevfn is always chosen by the >>>>> toolstack for ARM, not optionally like it is on x86. >>> For this one, the struct libxl_device_pci has a field "vdevfn", which >>> is >>> supposed to allow the user to specify a specific vdevfn. I'm not sure >>> how >>> that happens or fits together but libxl could undertake to set that on >>> ARM >>> in the case where the user hasn't done so, effectively taking control >>> of >>> the PCI bus assignment. >>> >>> Ian. >>> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xen.org >>> http://lists.xen.org/xen-devel > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel