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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

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.

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