Re: [Xen-devel] [RFC] ARM PCI Passthrough design document

[Julien Grall <julien.grall@xxxxxxxxxx>]

Hi Roger,

On 30/05/17 08:40, Roger Pau Monné wrote:
> On Fri, May 26, 2017 at 06:14:09PM +0100, Julien Grall wrote:
> [...]
> > ## Who is in charge of the host bridge?
> >
> > There are numerous implementation of host bridges which exist on ARM. A part of
> > them requires a specific driver as they cannot be driven by a generic host 
> > bridge
> > driver. Porting those drivers may be complex due to dependencies on other
> > components.
> >
> > This would be seen as signal to leave the host bridge drivers in the hardware
> > domain. Because Xen would need to access the configuration space, all the access
> > would have to be forwarded to hardware domain which in turn will access the
> > hardware.
> IMHO this is much more complicated that what seems from the paragraph
> above. There is currently no way for Xen to forward PCI config space
> accesses to any other entity. The closer Xen has to this would be
> IOREQ servers possibly, but then you have to take into account that
> in order to forward PCI config spaces to Dom0 you *might* have to
> schedule the Dom0 (ie: context switch to it), perform the access and
> then context switch back to Xen and get the value. I don't think the
> PCI code is prepared for such asynchronous accesses at all.
I don't see any issue to schedule DOM0... it is configuration access 
space, not BAR access. It does not matter if it is slow. What matters 
here is to be able to use the host bridges and do PCI passthrough with Xen.
Also, the PCI code is currently x86 specific and not prepared for ARM. 
It does not mean we should not get the code in shape to support ARM ;).
> > In this design document, we are considering that the host bridge driver can
> > be ported in Xen. In the case it is not possible, a interface to forward
> > configuration space access would need to be defined. The interface details
> > is out of scope.
> I think that you have to state that the driver is ported to Xen or the
> bridge will not be supported. I don't think it's feasible to forward
> PCI config space access from Xen to Dom0 at all.
Rather than arguing on the code is not ready for that. I would have 
appreciated if you gave technical details on why it is not feasible.
I already gave quite a few times insights on why it might be difficult 
to port an host bridges in Xen.
        - How do you configure the clock? What if they are shared?
	- How about host bridges using indirect access (e.g cf8 like)? What you 
expose to DOM0?
        - ....

Such host bridges will end up to pull a lot of code in Xen and require 
more design than finding about a way to forward configuration space in 
Xen. Those boards exists and people are looking at using Xen + PCI 
passthrough. So saying they are not supported is not the right solution 
here.
Anyway, I mentioned it in the design document to open a discussion and 
not something I am going to focus for a first version of PCI pass-through.
Cheers,

--
Julien Grall

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