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

Re: RFC: PCI devices passthrough on Arm design proposal


  • To: Julien Grall <julien@xxxxxxx>, Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • From: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@xxxxxxxx>
  • Date: Fri, 17 Jul 2020 11:41:53 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.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=8RIiAIK16zN+pwbDHiqilk8OyUtBGYsWq8/wR1DF/+Y=; b=Yjoq4qd7n0VMMVdt8Q5I+4gVezOnQMtebupv7+UN2U+914VYNBpWr2AbEC4eQsuSuu9RrdFSb4uIiyCfj6Yr4Ucjx11vkOTdck93kfdQEoVhxetOOB76rFaGyDxqo43u1rAslUipSZ5MG13vTkFPVHMhaqOymLqdJ1vGRiUA/j5YXaAJ9KoMeQ/llmvVgoXvI7/LJw7/C77FxlBAXhUSvkyU30UTa9ebgOlnhX2sL75F96J7FnQ8aW7LatnY0dO24hSYfrtkbwg6cjYAxZ6RQPYyCRPMZfPJCjtH2zTXuKiO164Z5d8u1LrYtbUXbxkrxuDegp5MRUPTKszRlORpkQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZIfWzTERBW5KHbenM2b0UOPO0Vj/A8w6GPXowLBSVuzsxxrarAtLlDYtjJ7XUzKZouF7GW2h8AcTKDr8UulMcj0I4jp6GQzgJRsuRi6hwgcoIZS9N9dB1h7xAgF7m6bz0emQs86DoC2Ul2wLQEat1LlHLwQuZGzkmSBKYwAHzYaP+F4CW3mkIqAyP1Rfy7C3pylvvKPwXpc6Y+6Py0U+Uq0GlUNQmMwrfTi4G+E5aiFEfu5mZFYEs5F3/InIcH7VhuB2hgH5fCHbC6uGzi0DjMLfCiuWRwZEY+A1yKLumRnO6mNSCY3J8UphvnIYIexnDRdra4Za730RLAVbXAv3cg==
  • Authentication-results: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=epam.com;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, nd <nd@xxxxxxx>, Rahul Singh <Rahul.Singh@xxxxxxx>, Julien Grall <julien.grall.oss@xxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Delivery-date: Fri, 17 Jul 2020 11:42:15 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHWXA26EtJZFfhoUEGdjsOmzYm6XqkLokCAgAAEKwA=
  • Thread-topic: RFC: PCI devices passthrough on Arm design proposal

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
>
> Cheers,
>

 


Rackspace

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