[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: RFC: PCI devices passthrough on Arm design proposal
On 7/17/20 2:26 PM, Julien Grall wrote: > > > On 17/07/2020 08:41, Oleksandr Andrushchenko wrote: >>>> We need to come up with something similar for dom0less too. It could be >>>> exactly the same thing (a list of BDFs as strings as a device tree >>>> property) or something else if we can come up with a better idea. >>> Fully agree. >>> Maybe a tree topology could allow more possibilities (like giving BAR >>> values) in the future. >>>> >>>>> # Emulated PCI device tree node in libxl: >>>>> >>>>> Libxl is creating a virtual PCI device tree node in the device tree to >>>>> enable the guest OS to discover the virtual PCI during guest boot. We >>>>> introduced the new config option [vpci="pci_ecam"] for guests. When this >>>>> config option is enabled in a guest configuration, a PCI device tree node >>>>> will be created in the guest device tree. >>>>> >>>>> A new area has been reserved in the arm guest physical map at which the >>>>> VPCI bus is declared in the device tree (reg and ranges parameters of the >>>>> node). A trap handler for the PCI ECAM access from guest has been >>>>> registered at the defined address and redirects requests to the VPCI >>>>> driver in Xen. >>>>> >>>>> Limitation: >>>>> * Only one PCI device tree node is supported as of now. >>>> I think vpci="pci_ecam" should be optional: if pci=[ "PCI_SPEC_STRING", >>>> ...] is specififed, then vpci="pci_ecam" is implied. >>>> >>>> vpci="pci_ecam" is only useful one day in the future when we want to be >>>> able to emulate other non-ecam host bridges. For now we could even skip >>>> it. >>> This would create a problem if xl is used to add a PCI device as we need >>> the PCI node to be in the DTB when the guest is created. >>> I agree this is not needed but removing it might create more complexity in >>> the code. >> >> I would suggest we have it from day 0 as there are plenty of HW available >> which is not ECAM. >> >> Having vpci allows other bridges to be supported > > So I can understand why you would want to have a driver for non-ECAM host PCI > controller. However, why would you want to emulate a non-ECAM PCI controller > to a guest? Indeed. No need to emulate non-ECAM > > Cheers, >
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |