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

[Manish Jaggi <mjaggi@xxxxxxxxxxxxxxxxxx>]

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
https://schd.ws/hosted_files/xendeveloperanddesignsummit2017/76/slides.pdf
> 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