Re: [Xen-devel] PCI Pass-through / Config Space emulation for ARM64

[Manish Jaggi <mjaggi@xxxxxxxxxxxxxxxxxx>]

On 07/18/2018 03:27 PM, Manish Jaggi wrote:
> On 07/02/2018 07:51 PM, Roger Pau Monné wrote:
> > External Email
> >
> > On Mon, Jul 02, 2018 at 04:16:05PM +0530, Manish Jaggi wrote:
> > > Hi All,
> > >
> > > PCI-PT and PCI config space emulation have been in discussion for 
> > > quite a
> > > long time.
> > > We had started some work on this in past and in LEG-XEN but that 
> > > didnt go
> > > far and the group is closed.
> > >
> > > I believe that PCI-PT is a feature which would be suitable for not 
> > > only for
> > > servers but for embedded platforms as well.
> > >
> > > I would like know the interest in the developer community on this, 
> > > so that
> > > we can be
> > > able to complete this in the time frame of 4.12 release.
> > I'm not involved with the ARM side, but I think targeting
> > ARM pci-passthrough for 4.12 might be too optimistic. AFAICT ARM
> > doesn't yet have any kind of pci support, so you will have to:
> >
> >   - Get Xen to access the pci config space on ARM.
> >   - Implement trapping for pci config accesses for ARM guests.
> >   - Enable vpci and implement the arch specific hooks for MSI and MSI-X
> >     interrupt routing.
> >   - Audit the current vpci code and implement the missing features (and
> >     restrictions) so it can be used by unprivileged domains. vpci ATM
> >     is only used by PVH Dom0, and that's a trusted domain.
> >
> > That's in my opinion quite a lot of work, and I'm not sure a lot of
> > this can be done concurrently. Each step depends on the previous one
> > being functional (except for the last one that can be implemented on
> > x86 right now).
> ARM PCI Passthrough list of tasks
> -----------------------------------------
>
> This small document is the follow up of the past discussions on 
> mailing list
> Reference to earlier documents [1] and [2].
> Some of these tasks were started internals / while linaro-xen was active.
>
> Below is the list of features to be supported in order to have device
> passthrough working on xen. I have started on 1. Basic PCI support,
> I am merging my code with some code julien had written.
>
> Does this list looks ok? or If I missed something please feel free to add
>
> 1. Basic PCI support
> 1.1 Support in Xen
>     a. pci config space read write apis'
>     b. ert
typo
Read  b. ecam based hostbridge support
> (Xen would be touching host bridge directly)
>     c. implement PHYSDEVOP_pci_add_device hypercall
>     d. implement PHYSDEVOP_pci_mmcfg_reserved
>     e. Trap & Emulate PCI config space access's for Dom0
>         For Dom0 the access would be just forwarded to hostbridge 
> driver, no filter
>         This is done just to avoid xen and Dom0 both touching config 
> space.
> 1.2 Support in Linux
>     a. Dom0 finds PCI hostbridge in ACPI tables or in device tree
>     b. Dom0 registers the pci hostbridge with Xen
>         b.1 this PHYSDEVOP_pci_mmcfg_reserved hypercall is required for
>         agreement on seg number using config space address.
>
> Limitation: Only PCI ECAM based hostbridges would be supported.
>
> 2. SMMU Support for Dom0 devices
>     a. Generate IORT for Dom0 by hiding SMMU node
>     b. Add SMMU programming in the flow of PHYSDEVOP_pci_add_device 
> hypercall
>     c. Map ITS MSI Doorbell space in Dom0, mapping 1:1
>
> 3. Device Assignment to DomU
> 3.1 libxl
>         a. ACPI
>             - to provide IORT for DomU for ACPI
>             - add generic ecam device in MADT
>
>         b. DTS
>             - Add pci device node in guest dt for generic ecam
>
>         c. Mapping ITS Doorbell Space in DomU
>             - mapping not 1:1, this can be done through
>             a hypercall from libxl at the time of domain creation.
>
>         d. Mapping guest sbdf - host sbdf
>             - so that GIC-ITS MAPD command trapping should program proper
>             deviceID.
> 3.2 Xen
>     a. Trap and Emulate PCI config space for DomU (generic ecam)
>         - assigned PCI devices should be enumerated.
>
> 3.3 Linux
>         will not use pci frontend backend for config space access
>
> 4. Non-ECAM compliant pci-hostbridge support
> 4.1 Import Drivers from Linux into Xen
>    Advantages
>         - Back and forth between Dom0 and xen can be avoided
>     Tradeoffs
>         - Porting and maintenance effort.
>
>
>
> [1] 
> https://lists.xenproject.org/archives/html/xen-devel/2017-05/msg02520.html
> [2] 
> https://lists.xenproject.org/ardhaves/html/xen-devel/2016-12/msg00224.html
> > Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel