|
[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 15:49, Julien Grall <julien@xxxxxxx> wrote: > > > > On 17/07/2020 14:44, Bertrand Marquis wrote: >>> On 17 Jul 2020, at 15:29, Julien Grall <julien@xxxxxxx> wrote: >>> >>> >>> >>> On 17/07/2020 14:22, Bertrand Marquis wrote: >>>>>> # 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. >>>>> >>>>> Can't you deduce the requirement of such DT node based on the presence >>>>> of a 'pci=' option in the same config file? >>>>> >>>>> Also I wouldn't discard that in the future you might want to use >>>>> different emulators for different devices, so it might be helpful to >>>>> introduce something like: >>>>> >>>>> pci = [ '08:00.0,backend=vpci', '09:00.0,backend=xenpt', >>>>> '0a:00.0,backend=qemu', ... ] >>> >>> I like this idea :). >>> >>>>> >>>>> For the time being Arm will require backend=vpci for all the passed >>>>> through devices, but I wouldn't rule out this changing in the future. >>>> We need it for the case where no device is declared in the config file and >>>> the user >>>> wants to add devices using xl later. In this case we must have the DT node >>>> for it >>>> to work. >>> >>> Are you suggesting that you plan to implement PCI hotplug? >> No this is not in the current plan but we should not prevent this to be >> supported some day :-) > > I agree that we don't want to prevent extension. But I fail to see why this > would be an issue if we don't introduce the option "vcpi" today. I answered that in parallel while answering to Jan. This is needed to have no PCI device assigned when starting the guest and assign them later using xl pci-attach Bertrand > > Cheers, > > -- > Julien Grall
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |