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

Re: RFC: PCI devices passthrough on Arm design proposal


  • To: Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • From: Rahul Singh <Rahul.Singh@xxxxxxx>
  • Date: Tue, 21 Jul 2020 09:54:47 +0000
  • Accept-language: 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=zeo4narOoP4gCUzDyeyuRzuZ+8SpPZLGTzSvlzCpGmo=; b=WJSy+N7GDj4f753iOpYT7CherJlNN+5pH2trzSUb7AuyYPDvNIJjSR5g3lnA5hglWwt/kSAlUb/KuAvkD7Jh5cPtusHiK3aVIxGyJOcAMK6OL49zyMH+BOeTnMciwSAvJIcywjvhHyOK1wpBjtnuyK3BMyYQB+K94LMLh63RbukKFxO4LVUD640ufkXv/qpzRPC83EjS8wObqEdjACzzhmivICe4ZJiGzyUX+YOM9U2PnTFP28C/4z0X4CkqMzOlKcuvpKLAGcfeP9m8rsJA+PcLByg6Fbo2mcSyqTfq93Zx2BaLtlGGC6mz7PyJ53tEfik26AEFGHCYedFC45HCpg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EPraVo+dC7ih9zMWdZTwmC/xpzQ++0w7DHtVpoLWwXqFHmxQoLGpFG+Ws8gBUpUVSIVyvhz4Degtrk0w96aosY4nreMkICZVDO7pUk12Ya3CsP3ITf/oiiabuNqCkpgmfYuNKNdgm/JszhsMBXROiYFD/UU/mWVGMkBZ7MP5+NRyYspOKj64+cTyrBupUEW2r1g5opuCj7ITOaB98P/htX8So65yG/nLDQpGSmcO2I4uHkUrsB7Tcq4Dxw2nL/xfzGD1Ql3ssCsPwLfguwEsk3RB/SKS3SxPjUr8Gz9NAoQE4Uv91Heequ3BIB4w9naRNSQGq2l5HFO6YV/2xN23Og==
  • Authentication-results-original: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=arm.com;
  • Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>, Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, nd <nd@xxxxxxx>, Julien Grall <julien.grall.oss@xxxxxxxxx>
  • Delivery-date: Tue, 21 Jul 2020 09:55:03 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Original-authentication-results: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=arm.com;
  • Thread-index: AQHWW4kYTVU0hTDyYEitKlUuU5vZlKkKf2uAgAACLICAAOrEgIAAVPWAgAABeYCAAAssAIAAAcuAgAAIDQCABUqtgIAAsGEA
  • Thread-topic: RFC: PCI devices passthrough on Arm design proposal


> On 21 Jul 2020, at 12:23 am, Stefano Stabellini <sstabellini@xxxxxxxxxx> 
> wrote:
> 
> On Fri, 17 Jul 2020, Bertrand Marquis wrote:
>>> On 17 Jul 2020, at 16:06, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>> 
>>> 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.
>> 
>> I agree in this case the parameter could be optional and only required if 
>> not PCI device is assigned directly in the guest configuration.
> 
> Great!
> 
> Moreover, we might also be able to get rid of the vpci parameter in
> cases where are no devices assigned at boot time but still we want to
> create a vpci host bridge in domU anyway. In those cases we could use
> the following:
> 
>  pci = [];
> 
> otherwise, worse but it might be easier to implement in xl:
> 
>  pci = [""];

pci =[] ; is a great idea to avoid new config option to create a device tree 
node when there is no device assigned. We will check this and will update the 
design spec accodringly. 




 


Rackspace

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