[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: PCI devices passthrough on Arm design proposal
On 17.07.2020 15:50, Julien Grall wrote: > (Resending to the correct ML) > On 17/07/2020 14:23, Julien Grall wrote: >> On 16/07/2020 18:02, Rahul Singh wrote: >>> # Discovering PCI devices: >>> >>> PCI-PCIe enumeration is a process of detecting devices connected to >>> its host. It is the responsibility of the hardware domain or boot >>> firmware to do the PCI enumeration and configure the BAR, PCI >>> capabilities, and MSI/MSI-X configuration. >>> >>> PCI-PCIe enumeration in XEN is not feasible for the configuration part >>> as it would require a lot of code inside Xen which would require a lot >>> of maintenance. Added to this many platforms require some quirks in >>> that part of the PCI code which would greatly improve Xen complexity. >>> Once hardware domain enumerates the device then it will communicate to >>> XEN via the below hypercall. >>> >>> #define PHYSDEVOP_pci_device_add 25 >>> struct physdev_pci_device_add { >>> uint16_t seg; >>> uint8_t bus; >>> uint8_t devfn; >>> uint32_t flags; >>> struct { >>> uint8_t bus; >>> uint8_t devfn; >>> } physfn; >>> /* >>> * Optional parameters array. >>> * First element ([0]) is PXM domain associated with the device >>> (if * XEN_PCI_DEV_PXM is set) >>> */ >>> uint32_t optarr[XEN_FLEX_ARRAY_DIM]; >>> }; >>> >>> As the hypercall argument has the PCI segment number, XEN will access >>> the PCI config space based on this segment number and find the >>> host-bridge corresponding to this segment number. At this stage host >>> bridge is fully initialized so there will be no issue to access the >>> config space. >>> >>> XEN will add the PCI devices in the linked list maintain in XEN using >>> the function pci_add_device(). XEN will be aware of all the PCI >>> devices on the system and all the device will be added to the hardware >>> domain. >> I understand this what x86 does. However, may I ask why we would want it >> for Arm? Isn't it the normal thing to follow what there is, and instead provide reasons why a different approach is to be followed? Personally I'd much prefer if we didn't have two fundamentally different PCI implementations in the tree. Perhaps some of what Arm wants or needs can actually benefit x86 as well, but this requires sufficiently much code sharing then. Jan
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |