[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [RFC + Queries] Flow of PCI passthrough in ARM
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. 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
|
