All of lore.kernel.org
 help / color / mirror / Atom feed
From: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
To: "Roger Pau Monné" <roger.pau@citrix.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Stewart Hildebrand <stewart.hildebrand@amd.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
	Paul Durrant <paul@xen.org>, Kevin Tian <kevin.tian@intel.com>
Subject: Re: [PATCH v9 01/16] pci: introduce per-domain PCI rwlock
Date: Mon, 25 Sep 2023 22:44:32 +0000	[thread overview]
Message-ID: <878r8teuup.fsf@epam.com> (raw)
In-Reply-To: <ZQmro968jYGOb5sY@MacBookPdeRoger>


Hello Roger,

Roger Pau Monné <roger.pau@citrix.com> writes:

> On Tue, Aug 29, 2023 at 11:19:42PM +0000, Volodymyr Babchuk wrote:
>> Add per-domain d->pci_lock that protects access to
>> d->pdev_list. Purpose of this lock is to give guarantees to VPCI code
>> that underlying pdev will not disappear under feet. This is a rw-lock,
>> but this patch adds only write_lock()s. There will be read_lock()
>> users in the next patches.
>> 
>> This lock should be taken in write mode every time d->pdev_list is
>> altered. This covers both accesses to d->pdev_list and accesses to
>> pdev->domain_list fields.
>
> Why do you mention pdev->domain_list here?  I don't think the lock
> covers accesses to pdev->domain_list, unless that domain_list field
> happens to be part of the linked list in d->pdev_list.  I find it kind
> of odd to mention here.

You are correct. I was referring very specific case in reassign_device()
IOMMU functions. It seemed important for me when I wrote this. But you
are correct, no need to mention pdev->domain_list explicitly.

>
>> All write accesses also should be protected
>> by pcidevs_lock() as well. Idea is that any user that wants read
>> access to the list or to the devices stored in the list should use
>> either this new d->pci_lock or old pcidevs_lock(). Usage of any of
>> this two locks will ensure only that pdev of interest will not
>> disappear from under feet and that the pdev still will be assigned to
>> the same domain. Of course, any new users should use pcidevs_lock()
>> when it is appropriate (e.g. when accessing any other state that is
>> protected by the said lock). In case both the newly introduced
>> per-domain rwlock and the pcidevs lock is taken, the later must be
>> acquired first.
>> 
>> Any write access to pdev->domain_list should be protected by both
>> pcidevs_lock() and d->pci_lock in the write mode.
>> 
>> Suggested-by: Roger Pau Monné <roger.pau@citrix.com>
>> Suggested-by: Jan Beulich <jbeulich@suse.com>
>> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
>> 
>> ---
>> 
>> Changes in v9:
>>  - returned back "pdev->domain = target;" in AMD IOMMU code
>>  - used "source" instead of pdev->domain in IOMMU functions
>>  - added comment about lock ordering in the commit message
>>  - reduced locked regions
>>  - minor changes non-functional changes in various places
>> 
>> Changes in v8:
>>  - New patch
>> 
>> Changes in v8 vs RFC:
>>  - Removed all read_locks after discussion with Roger in #xendevel
>>  - pci_release_devices() now returns the first error code
>>  - extended commit message
>>  - added missing lock in pci_remove_device()
>>  - extended locked region in pci_add_device() to protect list_del() calls
>> ---
>>  xen/common/domain.c                         |  1 +
>>  xen/drivers/passthrough/amd/pci_amd_iommu.c |  9 ++-
>>  xen/drivers/passthrough/pci.c               | 71 +++++++++++++++++----
>>  xen/drivers/passthrough/vtd/iommu.c         |  9 ++-
>>  xen/include/xen/sched.h                     |  1 +
>>  5 files changed, 78 insertions(+), 13 deletions(-)
>> 
>> diff --git a/xen/common/domain.c b/xen/common/domain.c
>> index 304aa04fa6..9b04a20160 100644
>> --- a/xen/common/domain.c
>> +++ b/xen/common/domain.c
>> @@ -651,6 +651,7 @@ struct domain *domain_create(domid_t domid,
>>  
>>  #ifdef CONFIG_HAS_PCI
>>      INIT_LIST_HEAD(&d->pdev_list);
>> +    rwlock_init(&d->pci_lock);
>>  #endif
>>  
>>      /* All error paths can depend on the above setup. */
>> diff --git a/xen/drivers/passthrough/amd/pci_amd_iommu.c b/xen/drivers/passthrough/amd/pci_amd_iommu.c
>> index bea70db4b7..d219bd9453 100644
>> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
>> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
>> @@ -476,7 +476,14 @@ static int cf_check reassign_device(
>>  
>>      if ( devfn == pdev->devfn && pdev->domain != target )
>>      {
>> -        list_move(&pdev->domain_list, &target->pdev_list);
>> +        write_lock(&source->pci_lock);
>> +        list_del(&pdev->domain_list);
>> +        write_unlock(&source->pci_lock);
>> +
>> +        write_lock(&target->pci_lock);
>> +        list_add(&pdev->domain_list, &target->pdev_list);
>> +        write_unlock(&target->pci_lock);
>> +
>>          pdev->domain = target;
>
> While I don't think this is strictly an issue right now, it would be
> better to set pdev->domain before the device is added to domain_list.
> A pattern like:
>
> read_lock(d->pci_lock);
> for_each_pdev(d, pdev)
>     foo(pdev->domain);
> read_unlock(d->pci_lock);
>
> Wouldn't work currently if the pdev is added to domain_list before the
> pdev->domain field is updated to reflect the new owner.

Agree. I moved `pdev->domain = target` so it sits between list_del() and
list_add() calls


-- 
WBR, Volodymyr

  reply	other threads:[~2023-09-25 22:45 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-29 23:19 [PATCH v9 00/16] PCI devices passthrough on Arm, part 3 Volodymyr Babchuk
2023-08-29 23:19 ` [PATCH v9 02/16] vpci: use per-domain PCI lock to protect vpci structure Volodymyr Babchuk
2023-09-19 15:39   ` Roger Pau Monné
2023-09-19 15:55     ` Jan Beulich
2023-09-20  8:12       ` Roger Pau Monné
2023-09-19 16:20     ` Stewart Hildebrand
2023-09-20  8:09       ` Roger Pau Monné
2023-09-20 13:56         ` Stewart Hildebrand
2023-09-21  7:42           ` Jan Beulich
2023-09-21  9:00             ` Roger Pau Monné
2023-09-20 19:16     ` Stewart Hildebrand
2023-09-21  9:41       ` Roger Pau Monné
2023-09-25 23:03     ` Volodymyr Babchuk
2023-08-29 23:19 ` [PATCH v9 03/16] vpci: restrict unhandled read/write operations for guests Volodymyr Babchuk
2023-08-29 23:19 ` [PATCH v9 01/16] pci: introduce per-domain PCI rwlock Volodymyr Babchuk
2023-09-19 14:09   ` Roger Pau Monné
2023-09-25 22:44     ` Volodymyr Babchuk [this message]
2023-08-29 23:19 ` [PATCH v9 05/16] vpci/header: rework exit path in init_bars Volodymyr Babchuk
2023-09-20  8:49   ` Roger Pau Monné
2023-08-29 23:19 ` [PATCH v9 06/16] vpci/header: implement guest BAR register handlers Volodymyr Babchuk
2023-09-01  5:25   ` Stewart Hildebrand
2023-09-20  9:49   ` Roger Pau Monné
2023-09-20 14:18     ` Stewart Hildebrand
2023-08-29 23:19 ` [PATCH v9 04/16] vpci: add hooks for PCI device assign/de-assign Volodymyr Babchuk
2023-09-12  9:37   ` Jan Beulich
2023-09-12 23:41     ` Volodymyr Babchuk
2023-09-13  5:58       ` Jan Beulich
2023-09-13 23:53         ` Volodymyr Babchuk
2023-09-20  8:41           ` Roger Pau Monné
2023-09-20  8:39   ` Roger Pau Monné
2023-08-29 23:19 ` [PATCH v9 07/16] rangeset: add RANGESETF_no_print flag Volodymyr Babchuk
2023-08-29 23:19 ` [PATCH v9 08/16] vpci/header: handle p2m range sets per BAR Volodymyr Babchuk
2023-09-20 11:35   ` Roger Pau Monné
2023-09-27 18:18   ` Stewart Hildebrand
2023-08-29 23:19 ` [PATCH v9 09/16] vpci/header: program p2m with guest BAR view Volodymyr Babchuk
2023-09-21 10:34   ` Roger Pau Monné
2023-08-29 23:19 ` [PATCH v9 10/16] vpci/header: emulate PCI_COMMAND register for guests Volodymyr Babchuk
2023-09-01  5:23   ` Stewart Hildebrand
2023-09-21 13:18   ` Roger Pau Monné
2023-08-29 23:19 ` [PATCH v9 11/16] vpci/header: reset the command register when adding devices Volodymyr Babchuk
2023-09-21 13:30   ` Roger Pau Monné
2023-08-29 23:19 ` [PATCH v9 14/16] xen/arm: account IO handlers for emulated PCI MSI-X Volodymyr Babchuk
2023-08-29 23:19 ` [PATCH v9 13/16] xen/arm: translate virtual PCI bus topology for guests Volodymyr Babchuk
2023-09-22  8:32   ` Roger Pau Monné
2023-08-29 23:19 ` [PATCH v9 12/16] vpci: add initial support for virtual PCI bus topology Volodymyr Babchuk
2023-08-30  7:37   ` Jan Beulich
2023-08-31 21:12     ` Volodymyr Babchuk
2023-09-21 16:03   ` Roger Pau Monné
2023-08-29 23:19 ` [PATCH v9 16/16] xen/arm: vpci: permit access to guest vpci space Volodymyr Babchuk
2023-09-26  0:12   ` Stewart Hildebrand
2023-08-29 23:19 ` [PATCH v9 15/16] xen/arm: vpci: check guest range Volodymyr Babchuk
2023-09-22  8:44   ` Roger Pau Monné
2023-09-25 21:49     ` Stewart Hildebrand
2023-09-26  8:07       ` Roger Pau Monné
2023-09-26 15:27         ` Stewart Hildebrand
2023-09-26 15:48           ` Roger Pau Monné
2023-09-27 18:03             ` Stewart Hildebrand
2023-09-28  8:28               ` Roger Pau Monné
2023-09-28 18:28                 ` Stewart Hildebrand
2023-10-02 11:49                   ` Roger Pau Monné

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=878r8teuup.fsf@epam.com \
    --to=volodymyr_babchuk@epam.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=george.dunlap@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=julien@xen.org \
    --cc=kevin.tian@intel.com \
    --cc=paul@xen.org \
    --cc=roger.pau@citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=stewart.hildebrand@amd.com \
    --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.