All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stewart Hildebrand <stewart.hildebrand@amd.com>
To: "Chen, Jiqian" <Jiqian.Chen@amd.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"Jan Beulich" <jbeulich@suse.com>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>, "Wei Liu" <wl@xen.org>,
	"George Dunlap" <george.dunlap@citrix.com>,
	"Julien Grall" <julien@xen.org>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Anthony PERARD" <anthony.perard@citrix.com>,
	"Juergen Gross" <jgross@suse.com>,
	"Huang, Ray" <Ray.Huang@amd.com>
Subject: Re: [RFC XEN PATCH v4 1/5] xen/vpci: Clear all vpci status of device
Date: Wed, 10 Jan 2024 09:09:06 -0500	[thread overview]
Message-ID: <0bbb2260-3fde-4b0f-949d-01ffd03029ce@amd.com> (raw)
In-Reply-To: <BL1PR12MB58494843C4BCE9A522A0E674E7692@BL1PR12MB5849.namprd12.prod.outlook.com>

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,
> 


  reply	other threads:[~2024-01-10 14:09 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-05  7:09 [RFC XEN PATCH v4 0/5] Support device passthrough when dom0 is PVH on Xen Jiqian Chen
2024-01-05  7:09 ` [RFC XEN PATCH v4 1/5] xen/vpci: Clear all vpci status of device Jiqian Chen
2024-01-09 15:24   ` Stewart Hildebrand
2024-01-10  6:24     ` Chen, Jiqian
2024-01-10 14:09       ` Stewart Hildebrand [this message]
2024-01-11  2:36         ` Chen, Jiqian
2024-01-05  7:09 ` [RFC XEN PATCH v4 2/5] x86/pvh: Allow (un)map_pirq when caller isn't DOMID_SELF Jiqian Chen
2024-01-06  0:46   ` Stefano Stabellini
2024-01-08  8:47     ` Jan Beulich
2024-01-08  9:15       ` Chen, Jiqian
2024-01-08  9:25         ` Jan Beulich
2024-01-09  7:58           ` Chen, Jiqian
2024-01-05  7:09 ` [RFC XEN PATCH v4 3/5] x86/pvh: Add PHYSDEVOP_setup_gsi for PVH dom0 Jiqian Chen
2024-01-06  0:54   ` Stefano Stabellini
2024-01-08  8:50     ` Jan Beulich
2024-01-09  8:01       ` Chen, Jiqian
2024-01-05  7:09 ` [RFC XEN PATCH v4 4/5] domctl: Use gsi to grant/revoke irq permission Jiqian Chen
2024-01-06  1:08   ` Stefano Stabellini
2024-01-06  1:12     ` Stefano Stabellini
2024-01-08  3:43     ` Chen, Jiqian
2024-01-08  8:55     ` Jan Beulich
2024-01-08 15:05       ` Roger Pau Monné
2024-01-09  8:18         ` Chen, Jiqian
2024-01-09  9:38           ` Jan Beulich
2024-01-09 10:16             ` Chen, Jiqian
2024-01-09 10:40               ` Roger Pau Monné
2024-01-09 10:46               ` Jan Beulich
2024-01-10  8:49                 ` Chen, Jiqian
2024-01-10 20:09   ` Stewart Hildebrand
2024-01-11  2:39     ` Chen, Jiqian
2024-01-05  7:09 ` [RFC XEN PATCH v4 5/5] libxl: Use gsi instead of irq for mapping pirq Jiqian Chen
2024-01-05  7:36   ` Jan Beulich
2024-01-05  7:59     ` Chen, Jiqian
2024-01-06  1:11   ` Stefano Stabellini
2024-01-08  6:02     ` Chen, Jiqian

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0bbb2260-3fde-4b0f-949d-01ffd03029ce@amd.com \
    --to=stewart.hildebrand@amd.com \
    --cc=Jiqian.Chen@amd.com \
    --cc=Ray.Huang@amd.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=anthony.perard@citrix.com \
    --cc=george.dunlap@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=jgross@suse.com \
    --cc=julien@xen.org \
    --cc=roger.pau@citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.