> On 17 Jul 2020, at 15:19, Jan Beulich <[email protected]> wrote:
>
> On 17.07.2020 15:14, Bertrand Marquis wrote:
>>> On 17 Jul 2020, at 10:10, Jan Beulich <[email protected]> wrote:
>>> On 16.07.2020 19:10, Rahul Singh 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.
>>>
>>> I support Stefano's suggestion for this to be an optional thing, i.e.
>>> there to be no need for it when there are PCI devices assigned to the
>>> guest anyway. I also wonder about the pci_ prefix here - isn't
>>> vpci="ecam" as unambiguous?
>>
>> This could be a problem as we need to know that this is required for a guest
>> upfront so that PCI devices can be assigned after using xl.
>
> I'm afraid I don't understand: When there are no PCI device that get
> handed to a guest when it gets created, but it is supposed to be able
> to have some assigned while already running, then we agree the option
> is needed (afaict). When PCI devices get handed to the guest while it
> gets constructed, where's the problem to infer this option from the
> presence of PCI devices in the guest configuration?
If the user wants to use xl pci-attach to attach in runtime a device to a
guest, this guest must have a VPCI bus (even with no devices).
If we do not have the vpci parameter in the configuration this use case will
not work anymore.
@julien: in fact this can be considered as hotplug from guest point of view and
we do support this :-)
We will not support PCI hotplug for hardware hotplug definitely (ie adding in
runtime a new device on PCI).
Bertrand
>
> Jan
