Re: RFC: PCI devices passthrough on Arm design proposal

[Jan Beulich <jbeulich@xxxxxxxx>]

On 17.07.2020 15:59, Bertrand Marquis wrote:
> 
> 
>> On 17 Jul 2020, at 15:19, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>
>> On 17.07.2020 15:14, Bertrand Marquis wrote:
>>>> On 17 Jul 2020, at 10:10, Jan Beulich <jbeulich@xxxxxxxx> 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.

That's what everyone looks to agree with. Yet why is the parameter needed
when there _are_ PCI devices anyway? That's the "optional" that Stefano
was suggesting, aiui.

Jan