> On 17 Jul 2020, at 13:41, Oleksandr Andrushchenko 
> <oleksandr_andrushche...@epam.com> 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,


Reply via email to