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

Re: [PATCH v6 2/3] xen/arm: Enable the existing x86 virtual PCI support for ARM.


  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Luca Fancellu <luca.fancellu@xxxxxxx>
  • Date: Fri, 15 Oct 2021 15:00:21 +0100
  • 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=FoPwl1Fpwipzy4xVQrWJajg9fFL6J9cj58tmr0JHQnM=; b=TYcvH6qOP91UJpPPpvyGciYVeA9IMzkr/CpY8mCW+p5pyeFmt1oX5HS37uxwFdL04bEsMsCNKUN0ZTnro3ugCtPmQvSQv8xTZ9WB4Z5Fpj/BVKitVQHYEM4OWH3VrCb+O+jQ9DQfYC3eoxl2fD6Mxms8sS6dd8SSrJinDZUwRc71/zuk3/hM275lYHY3qJLblPMSN4W025pfm/QCGhJdQlC6HgImsipjq8KKmDBvYvMiZM5PvcGznybuFtkLwdrKFiaz6NCaLV9UZzZwjhOeLtZvUH508kIYqK0EN5B8wnJphJiVNXy+w5YcIbJAae4DWGoqbMRQF9YnXS3scoM2ag==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eTytjeNInz7DhJg7usOmdiOqRA5rttB3DYOBXk2T3ePhXhYr/BTsr3/3pjjxL9vYSceX9rKgTkZHTQ0nLcNLJ+kaDt4DB0y/M+qoTqZjjo/TsboZP3Oc72KzDjzGhu70bHoT/MkgciPdkmf+FwxvrzWX+3va+WuwrbcyUAtQ1ItYTmoh3pkbMOXAiv5Rt/wbeOhrFIeq/YXhFGs6cNpYYjqY9O113s7QkUCjF4WpV6gC5mIQlfdGXyyDhcFNIuMapfmMqkhbg8TinQaelXhkPvfJTw0cnUleFomLrifLOsLUMgtJDM3HNOF02eH1fP+un0K59zaYlAVSdnmyjvgi8g==
  • Authentication-results-original: citrix.com; dkim=none (message not signed) header.d=none;citrix.com; dmarc=none action=none header.from=arm.com;
  • Cc: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Rahul Singh <Rahul.Singh@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Paul Durrant <paul@xxxxxxx>, Oleksandr Andrushchenko <Oleksandr_Andrushchenko@xxxxxxxx>
  • Delivery-date: Fri, 15 Oct 2021 14:07:52 +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;


> On 15 Oct 2021, at 14:47, Roger Pau Monné <roger.pau@xxxxxxxxxx> wrote:
> 
> On Fri, Oct 15, 2021 at 10:48:41AM +0000, Bertrand Marquis wrote:
>> Hi Jan,
>> 
>>> On 15 Oct 2021, at 11:41, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>> 
>>> On 15.10.2021 12:33, Bertrand Marquis wrote:
>>>>> On 15 Oct 2021, at 11:24, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>>>> On 15.10.2021 11:52, Bertrand Marquis wrote:
>>>>>>> On 15 Oct 2021, at 09:32, Roger Pau Monné <roger.pau@xxxxxxxxxx> wrote:
>>>>>>> On Thu, Oct 14, 2021 at 03:49:50PM +0100, Bertrand Marquis wrote:
>>>>>>>> @@ -752,6 +752,19 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn,
>>>>>>>> 
>>>>>>>>  check_pdev(pdev);
>>>>>>>> 
>>>>>>>> +#ifdef CONFIG_ARM
>>>>>>>> +    /*
>>>>>>>> +     * On ARM PCI devices discovery will be done by Dom0. Add vpci 
>>>>>>>> handler when
>>>>>>>> +     * Dom0 inform XEN to add the PCI devices in XEN.
>>>>>>>> +     */
>>>>>>>> +    ret = vpci_add_handlers(pdev);
>>>>>>>> +    if ( ret )
>>>>>>>> +    {
>>>>>>>> +        printk(XENLOG_ERR "Setup of vPCI failed: %d\n", ret);
>>>>>>>> +        goto out;
>>>>>>>> +    }
>>>>>>>> +#endif
>>>>>>> 
>>>>>>> I think vpci_add_handlers should be called after checking that
>>>>>>> pdev->domain is != NULL, so I would move this chunk a bit below.
>>>>>> 
>>>>>> On arm this would prevent the dom0less use case or to have the PCI
>>>>>> bus enumerated from an other domain.
>>>>>> @oleksandr: can you comment on this one, you might have a better
>>>>>> answer than me on this ?
>>>>> 
>>>>> Well, without Xen doing the enumeration, some other entity would need
>>>>> to do so, including the reporting to Xen. Obviously without a Dom0 it
>>>>> would be ambiguous which domain to assign the device to; perhaps it
>>>>> should be the caller in this case? That would make that caller domain
>>>>> a pseudo-hwdom though, as far as PCI is concerned, which may not be
>>>>> desirable according to my (limited) understanding of dom0less.
>>>> 
>>>> This is not really related to this patch but the plan is the following:
>>>> - enumeration would have to be done by the firmware or boot loader before
>>>> - xen will have some code to detect PCI devices
>>>> - dom0less can be used to assign PCI devices to guest
>>>> 
>>>> Anyway does not change the fact that this must be called when domain is
>>>> not NULL and I will fix that.
>>> 
>>> Since we now all seem to agree that the NULL would have been a problem,
>>> may I ask in how far any of this has actually been tested?
>> 
>> With the whole serie currently on gitlab we have extensively tested passing
>> through PCI devices on Arm in several configuration (number of device, MSI,
>> MSI-X) and check that PCI was still functional on x86.
>> 
>> With the patches pushed to Xen right now it was checked that:
>> - xen compiles properly on arm32, arm64 and x86
>> - xen compiles properly with VPCI activated (using a patch) on arm32 and 
>> arm64
>> - xen on x86 is functionnal (using basic test on QEMU)
>> - xen on arm64 is functionnal (with some extensive tests on different 
>> targets)
> 
> I thinks it's unlikely, but since I haven't checked myself, could you
> see if the vpci user-space test harness (tools/tests/vpci) still
> builds and functions properly?

Hi Roger,

Bertrand is going to send the v7, however I’m keen to do this test but 
unfortunately
I’ve never used it before and I don’t have an x86 environment, do you have any
resource that I can read or some guidance?

Cheers,
Luca

> 
> Thanks, Roger.
> 




 


Rackspace

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