|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: RFC: PCI devices passthrough on Arm design proposal
> On 17 Jul 2020, at 13:41, Oleksandr Andrushchenko > <Oleksandr_Andrushchenko@xxxxxxxx> wrote: > > > 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 If someone wants to implement something else then ECAM in the future, there will be nothing preventing it to be done. But indeed I do not really see a need for that. Cheers Bertrand >> >> Cheers,
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |