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

Re: RFC: PCI devices passthrough on Arm design proposal

  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
  • Date: Fri, 17 Jul 2020 15:23:57 +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=dQXfMS2KW1AADi+PJHjBZrW/DpIYPlu2qSbWsw15YUc=; b=avt25V3DMCtlznBUv3mEyYiAHOLLGo7fAjMT0MfLWoV/Cs20j+cLj+RgThsLHt+iDArgH+I6ZR9VOyGxViITrMsvrrp0qIgK0ikC3ccnQI4+OZtdQtgqQxSVLD6xms3ynY2AhyyhVC4+bC8JN0AUm1aNe+VxlDx8th+UhEF9NhX+tAZ56D2cJpbnqAeYNBPgT7HW7EaF+ev3ejL5wlkRMbMuDHKpN7qk8Et+gj4emT92naZ4LWhXoixyycdInw2hutUFj0sK2pcut2IlgJ4dupOPyQLkqZhoR26rqh+2n2pwoPj2oNtJ4IW0REuDTDEv+TF4+/5Whbwt3i3PaAjvHQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ERgZECdtXeE/ev1npsA0KXvLGHkT2vVVEOJefmth1OJdjNbAuujXCGkXAJBh/DAR64wab5jpo2UuRzgj3gRRcEr8cZhV1ZBZRC7T8owzppJ43HhLzx2RMv0Wa8ydlhN9+OcL4hvdZSMTV0fFy/CDHicBBhdjV1CY17x2klhf85cPn/X+UPMMZyZ96CNyp4i2nmJXtv+vYBRnbF5vqqu+6W01azkfRWibHaIu6fYPWUmfwuuHThItVswrKAUaXblEBTHIXhcT3NTqkiy0GGvd0s4BsksA7H2lxqLAcaS9MNwc7T+3tFjh/rdkyeFn7DhzXpyIjvVrpqDpW46BwkGMxg==
  • Authentication-results-original: citrix.com; dkim=none (message not signed) header.d=none;citrix.com; dmarc=none action=none header.from=arm.com;
  • Cc: Rahul Singh <Rahul.Singh@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, nd <nd@xxxxxxx>, Julien Grall <julien.grall.oss@xxxxxxxxx>
  • Delivery-date: Fri, 17 Jul 2020 15:24:10 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Original-authentication-results: citrix.com; dkim=none (message not signed) header.d=none;citrix.com; dmarc=none action=none header.from=arm.com;
  • Thread-topic: RFC: PCI devices passthrough on Arm design proposal

> On 17 Jul 2020, at 17:05, Roger Pau Monné <roger.pau@xxxxxxxxxx> wrote:
> On Fri, Jul 17, 2020 at 02:49:20PM +0000, Bertrand Marquis wrote:
>>> On 17 Jul 2020, at 16:41, Roger Pau Monné <roger.pau@xxxxxxxxxx> wrote:
>>> On Fri, Jul 17, 2020 at 02:34:55PM +0000, 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.
>>> Where will the ECAM region(s) appear on the guest physmap?
>>> Are you going to re-use the same locations as on the physical
>>> hardware, or will they appear somewhere else?
>> We will add some new definitions for the ECAM regions in the guest physmap 
>> declared in xen (include/asm-arm/config.h)
> I think I'm confused, but that file doesn't contain anything related
> to the guest physmap, that's the Xen virtual memory layout on Arm
> Does this somehow relate to the physical memory map exposed to guests
> on Arm?

Yes it does.
We will add new definitions there related to VPCI to reserve some areas for the 
VPCI ECAM and the IOMEM areas.


> Roger.



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