[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC: PCI devices passthrough on Arm design proposal

  • To: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@xxxxxxxx>
  • From: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
  • Date: Fri, 17 Jul 2020 13:21:47 +0000
  • Accept-language: en-GB, en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+4HPXVczpd//tOGvgos9oXwkWTw2F29F1hkpbXCE9uo=; b=jfu4zUTA/hGtyA6aGz7hWhP/ZF0D7vhMf5gL8qXNTIbmw8eAJlGCyjIJiEnIhhel6Zl+5JyM97j0tkvoDrr0C6cbX/tEyJWIbdnb5hMOQ8AqI+Iev3sXUyYHcLPvVb3wjY2Hx4qzMcge5m4iAA4WYStR2KcLG2T6czejkOkGNg/QU2iofF+bOeEXIeEzcsFcM7dU82D6DAMNiWmksZIQWyKmJ9gDvb+ZYw8o4IBlKbiaKVrVv2Wf+8FhMwjxf71UEPrYT3bbXE3fsMNRrMtjsIjgPORGPUTBwKZsFGktVWk8lZCh8ORX+2s372oSpYJUOkluFjN7E+6XSOxpxcVfnA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=b6rDlskKZyyWWsWOWMsQo172apwC8LGcbZnkr2bduWp42N2oJyDjm4Ijad4IPfbni1cI9WZCmqwtfb6DBPhJJS3XIfH84b62oFnkU+sIuVpfQ08PsSMuRmlF3JAqf6LyKWvNXkwkH0FZY06/oqzm7m3WMjAOA8/rEl51mBITNBmU2AaZ2fRX4v8nmUld8jZjf9yHJnmDo/+ssOyIvrD0OzIdV6se4Yr4vZ3IavprjPU8ZXWV0A7PJJWo76QZKETdLdrF53j9x96IgDCKXMs6KxA35aJOuMlR7XON/dquICx+o2skTJnvIPW614px/sfPt5FNMy0SaeTrThETB6WT9A==
  • Authentication-results-original: epam.com; dkim=none (message not signed) header.d=none;epam.com; dmarc=none action=none header.from=arm.com;
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Julien Grall <julien.grall.oss@xxxxxxxxx>, Rahul Singh <Rahul.Singh@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, nd <nd@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Delivery-date: Fri, 17 Jul 2020 13:22:01 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Original-authentication-results: epam.com; dkim=none (message not signed) header.d=none;epam.com; dmarc=none action=none header.from=arm.com;
  • Thread-topic: 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,



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.