[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 16:20, manish jaggi wrote:
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.
There is about 30 mails in this discussion. It's better if you give a
summary, it will avoid us to read again all the mails to find the
conclusion.
Anyhow I will share the code as RFC in some time.
Thanks,
Regards,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
