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

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





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

 


Rackspace

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