[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.

> 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.

Roger.

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.