Re: [Xen-devel] PCI Pass-through in Xen ARM - Draft 2.

[Manish Jaggi <mjaggi@xxxxxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

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