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

[Punit Agrawal <punit.agrawal@xxxxxxx>]

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.

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
    code?
  - 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
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel