From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [RFC + Queries] Flow of PCI passthrough in ARM Date: Thu, 06 Nov 2014 16:02:30 +0000 Message-ID: <545B9B96.6080102@linaro.org> References: <20141008124657.GB13391@laptop.dumpdata.com> <1412775916.24894.15.camel@citrix.com> <20141008145107.GC18573@laptop.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: manish jaggi , Stefano Stabellini Cc: Ian Campbell , Vijay Kilari , Prasun Kapoor , manish.jaggi@caviumnetworks.com, Ryan Wilson , xen-devel , JBeulich@suse.com List-Id: xen-devel@lists.xenproject.org Hi Manish, On 06/11/2014 15:55, manish jaggi wrote: > On 6 November 2014 21:18, Stefano Stabellini > wrote: >> On Thu, 6 Nov 2014, manish jaggi wrote: >>> On 20 October 2014 20:24, Stefano Stabellini >>> wrote: >>>> On Mon, 20 Oct 2014, manish jaggi wrote: >>>>> On 8 October 2014 20:21, Konrad Rzeszutek Wilk wrote: >>>>>> On Wed, Oct 08, 2014 at 07:17:48PM +0530, manish jaggi wrote: >>>>>>> On 8 October 2014 19:15, Ian Campbell wrote: >>>>>>>> On Wed, 2014-10-08 at 19:07 +0530, manish jaggi wrote: >>>>>>>>> Thanks for replying. As detailed in this thread, I need to create a >>>>>>>>> hypercall that would send the following information to Xen at the time >>>>>>>>> of PCI attach >>>>>>>>> { sbdf , domU sbdf, domainId }. >>>>>>>>> I am not able to find a way to get the domU sbdf from dom0 at the time >>>>>>>>> of pci-attach. >>>>>>>> >>>>>>>> I think it would need to be done by the pciback driver in the dom0 >>>>>>>> kernel, which AFAIK is the thing which consistently knows both physical >>>>>>>> and virtual sbdf for a given assigned device. >>>>>>>> >>>>>>>> Ian. >>>>>>>> >>>>>>> Correct, can you point out which data structure holds the domU sbdf >>>>>>> corresponding to the actual sbdf in pciback. >>>>>> >>>>>> See 'xen_pcibk_export_device' or 'xen_pcibk_publish_pci_root' >>>>>> is that what you are referring to? >>>>> >>>>> Xen docs also mention about xen-pciback.passthrough=1. If I set this >>>>> in dom0 i see that the device is enumerated as the same sbdf in domU, >>>>> but >>>>> a) it is not shown in lspci >>>>> b) no front-back communication is done for reading devices configuration space >>>>> . >>>>> Is option useful / fully implemented for ARM ? >>>> >>>> I don't think this option is very useful. I wouldn't worry about it for >>>> now. >>> >>> Stefano / Ian / Konard / Julien, >>> >>> Attached is a first raw code FYI RFC Patches of PCI passthrough support on ARM. >>> - Linux Patch (3.18) >>> - Xen Patch (4.5 staging) >>> ---(Smmu changes not included, thats a separate patch altogether) >>> This patches show the logic, at places need of improvements in code >>> organization/quality. I wanted to share to get initial comments. >>> This is working with SRIOV as well. >>> >>> Please have a look and let me know your positive comments >> >> Please send as individual inline patches. not attachments. >> Please also add a proper description to each patch and an entry 0/N email >> with the high level explanation of your work. >> >> See http://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches > Stefano I just wanted to share the patches as reference to our > discussion on the approach. Please recall I had shared in this mail a > design flow. These are just an extension to it. I wanted to move this > discussion to a conclusion > There are not patches which I am submitting to xen git. > If you are ok with the approach I will formally send the patches post > 4.5 release. In this case you can send the patch series tagged "[RFC]" in the subject. It would better to start sending your patch series now, rather than post 4.5 release. So we can start to review it and maybe merge it as soon as 4.6 windows is opened. I gave a quick look to the patch you provided. It looks like it depends on GICv3 ITS and maybe some SMMU patches? (I doubt the current driver is working out-of-box). Please provide everything so we can try the patch series and have a better overview of the changes. Regards, -- Julien Grall