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

Re: [Xen-devel] Notes from PCI Passthrough design discussion at Xen Summit

Hi Punit,

On 7/19/2017 8:11 PM, Punit Agrawal wrote:
I took some notes for the PCI Passthrough design discussion at Xen
Summit. Due to the wide range of topics covered, the notes got sparser
towards the end of the session. I've tried to attribute names against
comments but have very likely got things mixed up. Apologies in advance.
Was curious if any discussions happened on the RC Emu (config space emulation) as per slide 18
Although the session was well attended, some of the more active
discussions involved - Julien Grall, Stefano Stabillini, Roger Pau
Monné, Jan Beulich, Vikram Sethi. I'm sure I am missing some folks here.

Please do point out any mistakes I've made for the audience's benefit.

* Discovery of PCI hostbridges
   - Dom0 will be responsible for scanning the ECAM for devices and
     register them with Xen. This approach is chosen due to variety of
     non-standard PCI controllers on ARM platforms and the desire to
     not duplicate driver code between Linux and Xen.
   - Jan, Roger: Bus scan needs to happer before device discovery
     otherwise a small window where Xen doesn't know which host bridge
     the device is registered on (as it'll likely only refer to the
     segment number).
   - Roger: Registering config space with Xen before device discovery
     will allow the hypervisor to set access traps for certain
     functionality as appropriate.
   - Jan: Xen and Dom0 have to agree on the PCI segment number mapping
     to host bridges. This is so that for future calls, Dom0 and
     hypervisor can communicate using sBDF without ambiguity.
   - Julien: Dom0 will register config space address and segment
     number. mcfg_add will be used to pass the segment to Xen.
   - PCI segment - it's purely a software construct so identify
     different host bridges.
   - Some discussion on whether boot devices need to be on
     Segment 0. Technically, MCFG is only required to describe Segment
     0 - other host bridges can be described in AML.

* Configuration accesses for non-ecam compliant host bridge
   - Julien proposed these to be forwarded to Dom0 for handling.
   - Audience: What kind of non-compliance are we talking about? If
     they are simple, can they be implemented in Xen in a few lines of
   - A few different types
     - restrictions on access size, e.g., only certain sizes supported
     - register multiplexing via a window; similar to legacy x86 PCI
       access mechanism
     - ECAM compliant but with special casing for different devices

* Support on 32bit platforms
   - Is there enough address space to map ECAM into Dom0. Maximum ECAM
     size is 256MB.

* PCI ACS support
   - Vikram: Xen needs to be aware of the PCI device topology to
     correctly setup device groups for passthrough
   - Jan: Roger: IIRC, Xen is already aware of the device topology
     thought it doesn't use ACS to work out which devices need to be
     passed to guest as a group.
   - Stefano: There was support in xend (previous Xen toolstack) but the
     functionality has not yet been ported to libxl.

* Implementation milestones
   - Julien provided a summary of breakdown
     - M0 - design document, currently under discussion on xen-devel
     - M1 - PCI support in Xen
       - Xen aware of PCI devices (via Dom0 registration)
     - M2 - Guest PCIe passthrough
       - Julien: Some complexity in dealing with Legacy interrupts as they can 
be shared.
       - Roger: MSIs mandatory for PCIe. So legacy interrupts can be
         tackled at a later stage.
     - M3 - testing
       - fuzzing. Jan: If implemented it'll be better than what x86
         currently have.

Xen-devel mailing list



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