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

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

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 
driver. Porting those drivers may be complex due to dependencies on other

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

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.


Julien Grall

Xen-devel mailing list



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