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

Re: [RFC XEN PATCH v4 1/5] xen/vpci: Clear all vpci status of device


  • To: "Chen, Jiqian" <Jiqian.Chen@xxxxxxx>
  • From: Stewart Hildebrand <stewart.hildebrand@xxxxxxx>
  • Date: Wed, 10 Jan 2024 09:09:06 -0500
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0)
  • 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=AA9/pnc0GnX2BrERDELIxm/XSzXhaAGbxx3jRIpi6J0=; b=E3K8+FGLHNLYr07wl0krLpryhV31oluZO/UnFNwGRE4whRGQLx0/V7bIGq3hIcE2qMS2Oxmw82xuGGIRzUvg9Q8AgNPCjJOvVrfiet5u1UHiIndJGbSxZKro5LzsYJ0EvK5ykP62QzSPbGFALGWxnzj0XJUkJsZixbGf8GGN5mOrXeRoBMcUPK69ALjyaCb00C0C/MAhJB9cX300i4oSdtDSJSVAd+uQlx4WtIl2xq3emTLEZRYTXmKrjaJx+CPMebIe5i1Nzh5bkTszvGFFerPaE1i9Aa6Xv+HKjGMWThUNbIYfbMhEGQJSB2YgQngeinMjHJ+QbeY2kLMM4pRJow==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QculUaKTvkthz5jpvAnKEIFP1mCRvEKdBgLEC7o1TzBNE2z4ri0ckonTNazYHfEQkTUWnfeNy8fI3KiS1e4emaxnDCWjmYe11HctOT8OcHCxH+ZmF1AqbYN5DplK38cWF6NAxns8Lowlb6xopd/oobIFzCbFiawUiIiXmIL9jnGbp78WPIriTzZPy1gOpO/B5C3GwqriD7IRRWStkSUczNcwXDTP/eAr5oyE4sn1b7WFVpccYaV2OpSYnMXi9QkLcMhpfRvQeRp9ycoWaN+kQAVt9O0YM4FUpFJkUadEjg6n6tkdgrilT0PnyXwxeOXt4BYlrgWBtupcsHA8k04TFA==
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "Jan Beulich" <jbeulich@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, "Huang, Ray" <Ray.Huang@xxxxxxx>
  • Delivery-date: Wed, 10 Jan 2024 14:09:17 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 1/10/24 01:24, Chen, Jiqian wrote:
> On 2024/1/9 23:24, Stewart Hildebrand wrote:
>> On 1/5/24 02:09, Jiqian Chen wrote:
>>> diff --git a/xen/drivers/pci/physdev.c b/xen/drivers/pci/physdev.c
>>> index 42db3e6d133c..552ccbf747cb 100644
>>> --- a/xen/drivers/pci/physdev.c
>>> +++ b/xen/drivers/pci/physdev.c
>>> @@ -67,6 +68,39 @@ ret_t pci_physdev_op(int cmd, 
>>> XEN_GUEST_HANDLE_PARAM(void) arg)
>>>          break;
>>>      }
>>>  
>>> +    case PHYSDEVOP_pci_device_state_reset: {
>>> +        struct physdev_pci_device dev;
>>> +        struct pci_dev *pdev;
>>> +        pci_sbdf_t sbdf;
>>> +
>>> +        if ( !is_pci_passthrough_enabled() )
>>> +            return -EOPNOTSUPP;
>>> +
>>> +        ret = -EFAULT;
>>> +        if ( copy_from_guest(&dev, arg, 1) != 0 )
>>> +            break;
>>> +        sbdf = PCI_SBDF(dev.seg, dev.bus, dev.devfn);
>>> +
>>> +        ret = xsm_resource_setup_pci(XSM_PRIV, sbdf.sbdf);
>>> +        if ( ret )
>>> +            break;
>>> +
>>> +        pcidevs_lock();
>>> +        pdev = pci_get_pdev(NULL, sbdf);
>>> +        if ( !pdev )
>>> +        {
>>> +            pcidevs_unlock();
>>> +            ret = -ENODEV;
>>> +            break;
>>> +        }
>>> +
>>
>>         write_lock(&pdev->domain->pci_lock);
>>
>>> +        ret = vpci_reset_device_state(pdev);
>>
>>         write_unlock(&pdev->domain->pci_lock);
> vpci_reset_device_state only reset the vpci state of pdev without deleting 
> pdev from domain, and here has held pcidevs_lock, it has no need to lock 
> pci_lock?

Strictly speaking, it is not enforced yet. However, an upcoming change [1] will 
expand the scope of d->pci_lock to include protecting the pdev->vpci structure 
to an extent, so it will be required once that change is committed. In my 
opinion there is no harm in adding the additional lock now. If you prefer to 
wait I would not object, but in this case I would at least ask for a TODO 
comment to help remind us to address it later.

[1] https://lists.xenproject.org/archives/html/xen-devel/2024-01/msg00446.html

> 
>>
>>> +        pcidevs_unlock();
>>> +        if ( ret )
>>> +            printk(XENLOG_ERR "%pp: failed to reset PCI device state\n", 
>>> &sbdf);
>>> +        break;
>>> +    }
>>> +
>>>      default:
>>>          ret = -ENOSYS;
>>>          break;
>>> diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
>>> index 72ef277c4f8e..3c64cb10ccbb 100644
>>> --- a/xen/drivers/vpci/vpci.c
>>> +++ b/xen/drivers/vpci/vpci.c
>>> @@ -107,6 +107,15 @@ int vpci_add_handlers(struct pci_dev *pdev)
>>>  
>>>      return rc;
>>>  }
>>> +
>>> +int vpci_reset_device_state(struct pci_dev *pdev)
>>> +{
>>> +    ASSERT(pcidevs_locked());
>>
>>     ASSERT(rw_is_write_locked(&pdev->domain->pci_lock));
>>
>>> +
>>> +    vpci_remove_device(pdev);
>>> +    return vpci_add_handlers(pdev);
>>> +}
>>> +
>>>  #endif /* __XEN__ */
>>>  
>>>  static int vpci_register_cmp(const struct vpci_register *r1,
> 



 


Rackspace

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