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 18:20:27 +0530 Message-ID: <55BB6F13.4080606@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> <55BB56E4.2030700@caviumnetworks.com> <1438341549.30740.63.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: <1438341549.30740.63.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 31/07/15 4:49 pm, Ian Campbell wrote: > On Fri, 2015-07-31 at 16:37 +0530, Manish Jaggi wrote: >> 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. > Only if you ignore the other option I proposed. > >> 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. > No. arch hooks in libxl_$ARCH.c (with nop implementations where necessary) > would be the way to approach this. However I still am not convinced this is > the approach we should be taking. > >>> 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. > IMHO the toolstack is the correct place for this code, at least for ARM > guests. The toolstack is, in general, responsible for all aspects of the > guest layout. I don't think delegating the PCI bus parts of that to the > dom0 kernel makes sense. Ok, i will implement the same from pciback to toolstack. I am not sure about the complexity but will give it a try. With this xen-pciback will not create the vdev-X entry at all. > > I'd not be surprised if the same turns out to be true for x86/PVH guests > too. > Ian. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel