[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [RFC + Queries] Flow of PCI passthrough in ARM



On 6 November 2014 21:37, Stefano Stabellini
<stefano.stabellini@xxxxxxxxxxxxx> wrote:
> On Thu, 6 Nov 2014, Julien Grall wrote:
>> Hi Manish,
>>
>> On 06/11/2014 15:55, manish jaggi wrote:
>> > On 6 November 2014 21:18, Stefano Stabellini
>> > <stefano.stabellini@xxxxxxxxxxxxx> wrote:
>> > > On Thu, 6 Nov 2014, manish jaggi wrote:
>> > > > On 20 October 2014 20:24, Stefano Stabellini
>> > > > <stefano.stabellini@xxxxxxxxxxxxx> wrote:
>> > > > > On Mon, 20 Oct 2014, manish jaggi wrote:
>> > > > > > On 8 October 2014 20:21, Konrad Rzeszutek Wilk
>> > > > > > <konrad.wilk@xxxxxxxxxx> wrote:
>> > > > > > > On Wed, Oct 08, 2014 at 07:17:48PM +0530, manish jaggi wrote:
>> > > > > > > > On 8 October 2014 19:15, Ian Campbell <Ian.Campbell@xxxxxxxxxx>
>> > > > > > > > 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.
>
> That's right. It is difficult to give even just an early feedback
> without the patch descriptions.
>
I assumed that the context is preserved in this mail thread. I shared
the flow in the first few mails and am sharing the code after a lot of
discussion in this thread.

Anyhow I will share the code as RFC in some time.
Thanks for the comments.

>
>> 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
>>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.