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
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
