From: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "Roger Pau Monné" <roger.pau@citrix.com>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v8 01/13] pci: introduce per-domain PCI rwlock
Date: Thu, 20 Jul 2023 23:37:22 +0000 [thread overview]
Message-ID: <87zg3qduj1.fsf@epam.com> (raw)
In-Reply-To: <b6375b17-7922-66ea-88fd-697fa759f96a@suse.com>
Hi Jan,
Jan Beulich <jbeulich@suse.com> writes:
> On 20.07.2023 02:32, Volodymyr Babchuk wrote:
>> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
>> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
>> @@ -476,8 +476,13 @@ static int cf_check reassign_device(
>>
>> if ( devfn == pdev->devfn && pdev->domain != target )
>> {
>> - list_move(&pdev->domain_list, &target->pdev_list);
>> - pdev->domain = target;
>> + write_lock(&pdev->domain->pci_lock);
>> + list_del(&pdev->domain_list);
>> + write_unlock(&pdev->domain->pci_lock);
>
> As mentioned on an earlier version, perhaps better (cheaper) to use
> "source" here? (Same in VT-d code then.)
Sorry, I saw you comment for the previous version, but missed to include
this change. It will be done in the next version.
>> @@ -747,6 +749,7 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn,
>> ret = 0;
>> if ( !pdev->domain )
>> {
>> + write_lock(&hardware_domain->pci_lock);
>> pdev->domain = hardware_domain;
>> list_add(&pdev->domain_list, &hardware_domain->pdev_list);
>>
>> @@ -760,6 +763,7 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn,
>> printk(XENLOG_ERR "Setup of vPCI failed: %d\n", ret);
>> list_del(&pdev->domain_list);
>> pdev->domain = NULL;
>> + write_unlock(&hardware_domain->pci_lock);
>> goto out;
>
> In addition to Roger's comments about locking scope: In a case like this
> one it would probably also be good to move the printk() out of the locked
> area. It can be slow, after all.
>
> Question is why you have this wide a locked area here in the first place:
> Don't you need to hold the lock just across the two list operations (but
> not in between)?
Strictly speaking yes, we need to hold lock only when operating on the
list. For now. Next patch will use the same lock to protect the VPCI
(de)alloction, so locked region will be extended anyways.
I think, I'll decrease locked area in this patch and increase in the
next one, it will be most logical.
>> @@ -887,26 +895,62 @@ static int deassign_device(struct domain *d, uint16_t seg, uint8_t bus,
>>
>> int pci_release_devices(struct domain *d)
>> {
>> - struct pci_dev *pdev, *tmp;
>> - u8 bus, devfn;
>> - int ret;
>> + int combined_ret;
>> + LIST_HEAD(failed_pdevs);
>>
>> pcidevs_lock();
>> - ret = arch_pci_clean_pirqs(d);
>> - if ( ret )
>> + write_lock(&d->pci_lock);
>> + combined_ret = arch_pci_clean_pirqs(d);
>> + if ( combined_ret )
>> {
>> pcidevs_unlock();
>> - return ret;
>> + write_unlock(&d->pci_lock);
>> + return combined_ret;
>> }
>> - list_for_each_entry_safe ( pdev, tmp, &d->pdev_list, domain_list )
>> +
>> + while ( !list_empty(&d->pdev_list) )
>> {
>> - bus = pdev->bus;
>> - devfn = pdev->devfn;
>> - ret = deassign_device(d, pdev->seg, bus, devfn) ?: ret;
>> + struct pci_dev *pdev = list_first_entry(&d->pdev_list,
>> + struct pci_dev,
>> + domain_list);
>> + uint16_t seg = pdev->seg;
>> + uint8_t bus = pdev->bus;
>> + uint8_t devfn = pdev->devfn;
>> + int ret;
>> +
>> + write_unlock(&d->pci_lock);
>> + ret = deassign_device(d, seg, bus, devfn);
>> + write_lock(&d->pci_lock);
>> + if ( ret )
>> + {
>> + bool still_present = false;
>> + const struct pci_dev *tmp;
>> +
>> + /*
>> + * We need to check if deassign_device() left our pdev in
>> + * domain's list. As we dropped the lock, we can't be sure
>> + * that list wasn't permutated in some random way, so we
>> + * need to traverse the whole list.
>> + */
>> + for_each_pdev ( d, tmp )
>> + {
>> + if ( tmp == pdev )
>> + {
>> + still_present = true;
>> + break;
>> + }
>> + }
>> + if ( still_present )
>> + list_move(&pdev->domain_list, &failed_pdevs);
>
> In order to retain original ordering on the resulting list, perhaps better
> list_move_tail()?
Yes, thanks.
--
WBR, Volodymyr
next prev parent reply other threads:[~2023-07-20 23:37 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-20 0:32 [PATCH v8 00/13] PCI devices passthrough on Arm, part 3 Volodymyr Babchuk
2023-07-20 0:32 ` [PATCH v8 04/13] vpci: add hooks for PCI device assign/de-assign Volodymyr Babchuk
2023-07-20 12:36 ` Roger Pau Monné
2023-07-26 1:38 ` Volodymyr Babchuk
2023-07-26 8:42 ` Roger Pau Monné
2023-07-24 9:41 ` Jan Beulich
2023-07-20 0:32 ` [PATCH v8 03/13] vpci: restrict unhandled read/write operations for guests Volodymyr Babchuk
2023-07-20 11:32 ` Roger Pau Monné
2023-07-20 0:32 ` [PATCH v8 01/13] pci: introduce per-domain PCI rwlock Volodymyr Babchuk
2023-07-20 9:45 ` Roger Pau Monné
2023-07-20 22:57 ` Volodymyr Babchuk
2023-07-20 15:40 ` Jan Beulich
2023-07-20 23:37 ` Volodymyr Babchuk [this message]
2023-07-20 0:32 ` [PATCH v8 02/13] vpci: use per-domain PCI lock to protect vpci structure Volodymyr Babchuk
2023-07-20 11:20 ` Roger Pau Monné
2023-07-20 13:27 ` Jan Beulich
2023-07-20 13:50 ` Roger Pau Monné
2023-07-24 0:07 ` Volodymyr Babchuk
2023-07-24 7:59 ` Roger Pau Monné
2023-07-20 15:53 ` Jan Beulich
2023-07-26 1:17 ` Volodymyr Babchuk
2023-07-26 6:39 ` Jan Beulich
2023-07-26 9:35 ` Roger Pau Monné
2023-07-27 0:56 ` Volodymyr Babchuk
2023-07-27 7:41 ` Jan Beulich
2023-07-27 10:31 ` Volodymyr Babchuk
2023-07-27 11:37 ` Jan Beulich
2023-07-27 15:13 ` Volodymyr Babchuk
2023-07-27 12:42 ` Roger Pau Monné
2023-07-27 12:56 ` Jan Beulich
2023-07-27 14:43 ` Roger Pau Monné
2023-07-28 0:21 ` Volodymyr Babchuk
2023-07-28 13:55 ` Roger Pau Monné
2023-07-20 16:03 ` Jan Beulich
2023-07-20 16:14 ` Roger Pau Monné
2023-07-21 6:02 ` Jan Beulich
2023-07-21 7:43 ` Roger Pau Monné
2023-07-21 8:48 ` Jan Beulich
2023-07-20 16:09 ` Jan Beulich
2023-07-20 0:32 ` [PATCH v8 05/13] vpci/header: implement guest BAR register handlers Volodymyr Babchuk
2023-07-20 16:01 ` Roger Pau Monné
2023-07-21 10:36 ` Rahul Singh
2023-07-21 10:50 ` Jan Beulich
2023-07-21 11:52 ` Roger Pau Monné
2023-07-20 0:32 ` [PATCH v8 06/13] rangeset: add RANGESETF_no_print flag Volodymyr Babchuk
2023-07-20 0:32 ` [PATCH v8 07/13] vpci/header: handle p2m range sets per BAR Volodymyr Babchuk
2023-07-21 11:49 ` Roger Pau Monné
2023-07-20 0:32 ` [PATCH v8 09/13] vpci/header: emulate PCI_COMMAND register for guests Volodymyr Babchuk
2023-07-21 13:32 ` Roger Pau Monné
2023-07-21 13:40 ` Roger Pau Monné
2023-07-24 11:06 ` Jan Beulich
2023-07-24 11:03 ` Jan Beulich
2023-07-20 0:32 ` [PATCH v8 10/13] vpci/header: reset the command register when adding devices Volodymyr Babchuk
2023-07-21 13:37 ` Roger Pau Monné
2023-07-20 0:32 ` [PATCH v8 08/13] vpci/header: program p2m with guest BAR view Volodymyr Babchuk
2023-07-21 13:05 ` Roger Pau Monné
2023-07-24 10:30 ` Jan Beulich
2023-07-24 10:43 ` Jan Beulich
2023-07-24 13:16 ` Roger Pau Monné
2023-07-24 13:31 ` Jan Beulich
2023-07-24 13:42 ` Roger Pau Monné
2023-07-20 0:32 ` [PATCH v8 11/13] vpci: add initial support for virtual PCI bus topology Volodymyr Babchuk
2023-07-20 6:50 ` Jan Beulich
2023-07-21 0:43 ` Volodymyr Babchuk
2023-07-21 13:53 ` Roger Pau Monné
2023-07-21 14:00 ` Roger Pau Monné
2023-07-26 21:35 ` Stewart Hildebrand
2023-07-20 0:32 ` [PATCH v8 12/13] xen/arm: translate virtual PCI bus topology for guests Volodymyr Babchuk
2023-07-20 6:54 ` Jan Beulich
2023-07-21 14:09 ` Roger Pau Monné
2023-07-24 8:02 ` Roger Pau Monné
2023-07-20 0:32 ` [PATCH v8 13/13] xen/arm: account IO handlers for emulated PCI MSI-X Volodymyr Babchuk
2023-07-20 0:41 ` [PATCH v8 00/13] PCI devices passthrough on Arm, part 3 Volodymyr Babchuk
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=87zg3qduj1.fsf@epam.com \
--to=volodymyr_babchuk@epam.com \
--cc=jbeulich@suse.com \
--cc=roger.pau@citrix.com \
--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.