[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>
  • From: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
  • Date: Fri, 17 Jul 2020 14:01:10 +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=Jd4/aGJDD35zQ9lqOJnGsuQzghd404qhES6bmDZNbso=; b=AoqVoLvwhzFTfbC4SlhoIKvfsnNDALIEg/FNN16Ljr6Tg6EEybl2N8BSV0JXe3wBeukCXRaDKOZr2JOUQP7G6RWTLtIFKYry0xYyaPqEHT+h26ENNZCwnTkFUtEtumr0z+/pVtognJSh3azKv7A5K5fjEYxXGNOPIU/nWRIqkgcptDqjvoM11JNOjiJ/F8OkhvaGiB6TLkAWnQIut3o9axELGq3G6A7DKXGfAWjSPbqNVYxaLVwOftb3PjFBMjSA8hrXxhfzwzQONnYLiJ2ufPxE9NVX2KxWzRf9dpSyPHuPlM/UrWiNywFDmC62rBz0O1jLd5kAO/L6PfBro4It2g==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RqmBcRvehMDdVFh76iDZ5lHz/cemaMmeONnIGKJDxpG/ymRWcIcGB8N6MQ45P63xqGN3ueENxfsoDlt3VPa1m1hwsu18IzakXgW5g7Df7D4yFJrL7fHSGBuJMnekLdJNRR/dZ0fe9wtuYGmOZcZUYIjf16ySjIFzgkYaQsoOoBBV9r8wngiHRMyAM41Ylmwf9gyYqngoW8Okn5AiEzjGWw2D5YyJPLtDWpNYBDdBmetgFMqVIJ97cde5XZ4WB1+V/eHbTuf4a1xxpleQIvdJd9HaDFxPebJlCROiJecrcP9IV2uNA6l715+T7YLNJ20yekPwLi8KWy4iKXJg6GaWcw==
  • Authentication-results-original: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=arm.com;
  • Cc: Rahul Singh <Rahul.Singh@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, nd <nd@xxxxxxx>, Julien Grall <julien.grall.oss@xxxxxxxxx>
  • Delivery-date: Fri, 17 Jul 2020 14:01:27 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Original-authentication-results: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=arm.com;
  • Thread-topic: RFC: PCI devices passthrough on Arm design proposal

> On 17 Jul 2020, at 15:49, Julien Grall <julien@xxxxxxx> wrote:
> On 17/07/2020 14:44, Bertrand Marquis wrote:
>>> On 17 Jul 2020, at 15:29, Julien Grall <julien@xxxxxxx> wrote:
>>> On 17/07/2020 14:22, Bertrand Marquis 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.
>>>>>> 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.
>>>>> Can't you deduce the requirement of such DT node based on the presence
>>>>> of a 'pci=' option in the same config file?
>>>>> Also I wouldn't discard that in the future you might want to use
>>>>> different emulators for different devices, so it might be helpful to
>>>>> introduce something like:
>>>>> pci = [ '08:00.0,backend=vpci', '09:00.0,backend=xenpt', 
>>>>> '0a:00.0,backend=qemu', ... ]
>>> I like this idea :).
>>>>> For the time being Arm will require backend=vpci for all the passed
>>>>> through devices, but I wouldn't rule out this changing in the future.
>>>> We need it for the case where no device is declared in the config file and 
>>>> the user
>>>> wants to add devices using xl later. In this case we must have the DT node 
>>>> for it
>>>> to work.
>>> Are you suggesting that you plan to implement PCI hotplug?
>> No this is not in the current plan but we should not prevent this to be 
>> supported some day :-)
> I agree that we don't want to prevent extension. But I fail to see why this 
> would be an issue if we don't introduce the option "vcpi" today.

I answered that in parallel while answering to Jan.
This is needed to have no PCI device assigned when starting the guest and 
assign them later using xl pci-attach


> Cheers,
> -- 
> Julien Grall



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