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

Re: [PATCH v2 1/1] vpci: Add resizable bar support


  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>
  • From: "Chen, Jiqian" <Jiqian.Chen@xxxxxxx>
  • Date: Wed, 11 Dec 2024 07:57:29 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=xAH43cGBL4j2MZBBksdqGyVk+alJRkttCFpKKRpYgjI=; b=bGv18+DJvnFQBXBxoBm0KLgqhForZbhK0sx/GBPAknLKIFVWF1EJMgphJHuzJLBvJ603P9kKTuhCt22tq3oKIqtk0fP92pF8aGx8WKKk5l3KQB7njupgmQ3Gouf/KiKdCz1TGgK7Y6VP/ZXGjd5K3QPDxTLjnfj4Kq4I39nlv6BXJ70suH9tj3v0jlbW53qRJifTTseui1n/Vi8JNvozsp7CdxNVH2OZ2aWkqGpD6ui5e1sqfOdctqTrTrr1r86UcwBhxg3zdbOFLLCBwUIpC498UGVws1l4n3efzk+8LgDfNCwsg7/LvQbiyGDY6mBiYxRJ/QgEn6Uyp3vi4sEhwg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=p0BvR4MdCjvNmqPvsSpBfrwpPpx61dwWUNvwwk0phDpgEYEGx+32Bq7eC/l04fRxCKzJe0wdRJbubh9IQFeKxyc4udeaQBYHO3FUFrTSvpmwUCjt3s5G8P9Knco01em5C6bBoOiQn+D0THeyqPLVu72rHWqOx0GGRv/0Zix/w0VP2hjmzxivD1VTlEwEZpen/2Yh2g5fkfu7RTED5skTUvxzAapaIxVPI8CfWQ2h6ukUPjLFuaU0QKI4YJ6P7B/wkiQywYxLDbMLTQvdUa+02pwu4xOhlnYg31URXIEQTQlVWLvsmD8fG3bqLYfAsoFVwqU6mhfd6tzNk42TQBmPlQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com;
  • Cc: "Chen, Jiqian" <Jiqian.Chen@xxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, "Huang, Ray" <Ray.Huang@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 11 Dec 2024 07:57:42 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHbRIDgGHZ3ofHO0UuqqXvn+EZCabLd/CGAgAGXh4D//4qBgIAAiieA//+hwICAABlHgIAB3TaA
  • Thread-topic: [PATCH v2 1/1] vpci: Add resizable bar support

On 2024/12/10 19:25, Roger Pau Monné wrote:
> On Tue, Dec 10, 2024 at 10:54:43AM +0100, Jan Beulich wrote:
>> On 10.12.2024 08:57, Chen, Jiqian wrote:
>>> On 2024/12/10 15:17, Jan Beulich wrote:
>>>> On 10.12.2024 08:07, Chen, Jiqian wrote:
>>>>> On 2024/12/9 21:59, Jan Beulich wrote:
>>>>>> On 02.12.2024 07:09, Jiqian Chen wrote:
>>>>>>> +        if ( rc )
>>>>>>> +        {
>>>>>>> +            printk("%pp: add register for PCI_REBAR_CAP failed 
>>>>>>> (rc=%d)\n",
>>>>>>> +                   &pdev->sbdf, rc);
>>>>>>> +            break;
>>>>>>> +        }
>>>>>>> +
>>>>>>> +        rc = vpci_add_register(pdev->vpci, vpci_hw_read32, 
>>>>>>> rebar_ctrl_write,
>>>>>>> +                               rebar_offset + PCI_REBAR_CTRL, 4,
>>>>>>> +                               pdev->vpci->header.bars);
>>>>>>> +        if ( rc )
>>>>>>> +        {
>>>>>>> +            printk("%pp: add register for PCI_REBAR_CTRL failed %d\n",
>>>>>>> +                   &pdev->sbdf, rc);
>>>>>>> +            break;
>>>>>>
>>>>>> Is it correct to keep the other handler installed? After all ...
>>>>> Will change to "return rc;" here and above in next version.
>>>>
>>>> I'm not convinced this is what we want, as per ...
>>>>
>>>>>>> +        }
>>>>>>> +    }
>>>>>>> +
>>>>>>> +    return 0;
>>>>>>
>>>>>> ... you - imo sensibly - aren't communicating the error back up (to allow
>>>>>> the device to be used without BAR resizing.
>>>>
>>>> ... what I said here.
>>> Sorry, I didn’t understand.
>>> Do you mean it is not enough to return error code once a handler failed to 
>>> be installed, I need to remove the already installed handlers?
>>
>> No, if you return an error here, nothing else needs doing. However, I
>> question that returning an error here is good or even necessary. In
>> the event of an error, the device ought to still be usable, just
>> without the BAR-resizing capability.
> 
> So you suggest that the capability should be hidden in that case?  We
> have logic to hide capabilities, just not used for the hardware
> domain.  It would need some extra wiring to be capable of hiding
> failed capabilities.
Can you give me a guidance on how to hide a failed capability?
What codes are current logic to hide capabilities?
Then maybe I can add a patch to implement it.

> 
> Regards, Roger.

-- 
Best regards,
Jiqian Chen.

 


Rackspace

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