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

Re: [PATCH v2 05/11] xen/arm: Mark device as PCI while creating one


  • To: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@xxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 28 Sep 2021 10:26:19 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.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; bh=5JiDH8eAcYjgcrjsbsX7whOu9DhoYFpXwJVQ+CN319M=; b=m9UPtk+t5csGbLCvCIggmCep/TuaKihR3EqtgzOYj+lmAyV6fVffiC8H7bTVWBoF2/ICY7/afb7TbIjM2u4TjTPEYvUv4yhNE6LvqhK2hIOEGw39vJwT0D1jHO+TwX2NsDSlu1GtyColOC7fmh2XYSZS7WKwm1rbzcKkMHStVTLbTtW7yCI7NAgCdJ+Tf1ynYRSuLjchp6X1GlucWH/2zg0Z80SOWVvhjM3E1IuodFPJIZYqNMSRcDVMB0FEPcjDgPqGV+mq5SRn+YGRWfHnp+P6IZW+rKCbIUeKCjUKDR993KVQlLnFya6lj0a2883Id7/y3GJOjLoW4Gr++7Fi7A==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jToAnn84MYsk4ofZvTOET8GsnnO7f2oqczKArtve3rmKjilsURHiefeAjKDJ20r8kHQI8FqKIumd+AmvEQ0NAMPeTVxepOjDUe3gm/oNTqH8dF4hAKbs87b0M1mOLLKYLjJuXea1gmPPXvwfaNTpsm0P2ROhVhx7bOqky9RAlJqlp+Z3UV/PmnMidGzDmFiMpK6JlPSjK05LyAap1++WSCcaNh0SQjMSitd95Jhnm9DtBF9JBX3QpIUSK/l9uMk0IXPxsplSfGEEY+YTTXHNWeSOuYpJ4i3ZDTABO77dTHdBCFjP8BLw9h9xVFGd373tCzGtZJb36A2SAZyrO0Icmg==
  • Authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=suse.com;
  • Cc: "julien@xxxxxxx" <julien@xxxxxxx>, "sstabellini@xxxxxxxxxx" <sstabellini@xxxxxxxxxx>, Oleksandr Tyshchenko <Oleksandr_Tyshchenko@xxxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Artem Mygaiev <Artem_Mygaiev@xxxxxxxx>, "roger.pau@xxxxxxxxxx" <roger.pau@xxxxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Rahul Singh <rahul.singh@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 28 Sep 2021 08:26:28 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 28.09.2021 10:09, Oleksandr Andrushchenko wrote:
> 
> On 27.09.21 13:26, Jan Beulich wrote:
>> On 27.09.2021 12:04, Oleksandr Andrushchenko wrote:
>>> On 27.09.21 13:00, Jan Beulich wrote:
>>>> On 27.09.2021 11:35, Oleksandr Andrushchenko wrote:
>>>>> On 27.09.21 12:19, Jan Beulich wrote:
>>>>>> On 27.09.2021 10:45, Oleksandr Andrushchenko wrote:
>>>>>>> On 27.09.21 10:45, Jan Beulich wrote:
>>>>>>>> On 23.09.2021 14:54, Oleksandr Andrushchenko wrote:
>>>>>>>>> --- a/xen/drivers/passthrough/pci.c
>>>>>>>>> +++ b/xen/drivers/passthrough/pci.c
>>>>>>>>> @@ -328,6 +328,9 @@ static struct pci_dev *alloc_pdev(struct pci_seg 
>>>>>>>>> *pseg, u8 bus, u8 devfn)
>>>>>>>>>          *((u8*) &pdev->bus) = bus;
>>>>>>>>>          *((u8*) &pdev->devfn) = devfn;
>>>>>>>>>          pdev->domain = NULL;
>>>>>>>>> +#ifdef CONFIG_ARM
>>>>>>>>> +    pci_to_dev(pdev)->type = DEV_PCI;
>>>>>>>>> +#endif
>>>>>>>> I have to admit that I'm not happy about new CONFIG_<arch> conditionals
>>>>>>>> here. I'd prefer to see this done by a new arch helper, unless there 
>>>>>>>> are
>>>>>>>> obstacles I'm overlooking.
>>>>>>> Do you mean something like arch_pci_alloc_pdev(dev)?
>>>>>> I'd recommend against "alloc" in its name; "new" instead maybe?
>>>>> I am fine with arch_pci_new_pdev, but arch prefix points to the fact that
>>>>> this is just an architecture specific part of the pdev allocation rather 
>>>>> than
>>>>> actual pdev allocation itself, so with this respect arch_pci_alloc_pdev 
>>>>> seems
>>>>> more natural to me.
>>>> The bulk of the function is about populating the just allocated struct.
>>>> There's no arch-specific part of the allocation (so far, leaving aside
>>>> MSI-X), you only want and arch-specific part of the initialization. I
>>>> would agree with "alloc" in the name if further allocation was to
>>>> happen there.
>>> Hm, then arch_pci_init_pdev sounds more reasonable
>> Fine with me.
> 
> Do we want this to be void or returning an error code? If error code is 
> needed,
> then we would also need a roll-back function, e.g. arch_pci_free_pdev or
> arch_pci_release_pdev or arch_pci_fini_pdev or something, so it can be used in
> case of error or in free_pdev function.

I'd start with void and make it return an error (and deal with necessary
cleanup) only once a need arises.

Jan




 


Rackspace

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