| 
    
 [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v5] vpci: Add resizable bar support
 On 2025/1/21 18:29, Jan Beulich wrote:
> On 21.01.2025 10:29, Roger Pau Monné wrote:
>> On Tue, Jan 21, 2025 at 09:10:26AM +0000, Chen, Jiqian wrote:
>>> On 2025/1/21 16:46, Roger Pau Monné wrote:
>>>> On Tue, Jan 14, 2025 at 11:26:36AM +0800, Jiqian Chen wrote:
>>>>> +    ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL(0));
>>>>> +    nbars = MASK_EXTR(ctrl, PCI_REBAR_CTRL_NBAR_MASK);
>>>>> +    for ( unsigned int i = 0; i < nbars; i++ )
>>>>> +    {
>>>>> +        int rc;
>>>>> +        struct vpci_bar *bar;
>>>>> +        unsigned int index;
>>>>> +
>>>>> +        ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + 
>>>>> PCI_REBAR_CTRL(i));
>>>>> +        index = ctrl & PCI_REBAR_CTRL_BAR_IDX;
>>>>> +        if ( index >= PCI_HEADER_NORMAL_NR_BARS )
>>>>> +        {
>>>>> +            printk(XENLOG_ERR "%pd %pp: too big BAR number %u in 
>>>>> REBAR_CTRL\n",
>>>>> +                   pdev->domain, &pdev->sbdf, index);
>>>>> +            continue;
>>>>> +        }
>>>>> +
>>>>> +        bar = &pdev->vpci->header.bars[index];
>>>>> +        if ( bar->type != VPCI_BAR_MEM64_LO && bar->type != 
>>>>> VPCI_BAR_MEM32 )
>>>>> +        {
>>>>> +            printk(XENLOG_ERR "%pd %pp: BAR%u is not in memory space\n",
>>>>> +                   pdev->domain, &pdev->sbdf, index);
>>>>> +            continue;
>>>>> +        }
>>>>> +
>>>>> +        rc = vpci_add_register(pdev->vpci, vpci_hw_read32, 
>>>>> vpci_hw_write32,
>>>>> +                               rebar_offset + PCI_REBAR_CAP(i), 4, NULL);
>>>>> +        if ( rc )
>>>>> +        {
>>>>> +            /*
>>>>> +             * TODO: for failed pathes, need to hide ReBar capability
>>>>> +             * from hardware domain instead of returning an error.
>>>>> +             */
>>>>> +            printk(XENLOG_ERR "%pd %pp: fail to add reg of REBAR_CAP 
>>>>> rc=%d\n",
>>>>> +                   pdev->domain, &pdev->sbdf, rc);
>>>>> +            return rc;
>>>>> +        }
>>>>> +
>>>>> +        rc = vpci_add_register(pdev->vpci, vpci_hw_read32, 
>>>>> rebar_ctrl_write,
>>>>> +                               rebar_offset + PCI_REBAR_CTRL(i), 4, bar);
>>>>> +        if ( rc )
>>>>> +        {
>>>>> +            printk(XENLOG_ERR "%pd %pp: fail to add reg of REBAR_CTRL 
>>>>> rc=%d\n",
>>>>> +                   pdev->domain, &pdev->sbdf, rc);
>>>>> +            return rc;
>>>>
>>>> I think we said we wanted to attempt to continue here, rather than
>>>> returning an error and thus removing all vPCI handlers from the
>>>> device?
>>> I thought the result of your discussion with Jan was that I only needed to 
>>> change the above two error paths to be "continue".
>>> If these two also need to be changed, I will modify them in the next 
>>> version.
>>
>> Hm, let's wait for Jan to confirm, but even if handler cannot be setup
>> for some of the registers, it's better than just allowing dom0
>> unmediated access to the capability.
> 
> I remained silent on this because I accepted this middle ground as ...
> 
>> None of this is ideal, but it seems to be the option that gives dom0
>> most options to successfully boot.
> 
> ... perhaps the most reasonable compromise.
OK, I see.
I will change to "continue" in next version and send v6 soon.
Thank you.
> 
> Jan
-- 
Best regards,
Jiqian Chen.
 
  | 
  
![]()  | 
            
         Lists.xenproject.org is hosted with RackSpace, monitoring our  |