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

Re: [PATCH v6 03/13] vpci: move lock outside of struct vpci


  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@xxxxxxxx>
  • Date: Tue, 8 Feb 2022 13:52:14 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
  • 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=OV0yQiCeohm3WATHNMvSpLy+lOyiJ3teNWGSWymmVjg=; b=PQhC6rFPkU2pttXSQeHSfpEPXPNPzJOq/EfGFtzKR8VkMs9j2sE4MTBxSFPKgUt/Uqvk1RdyL3MMVsmFfYV7+4LOAWjcxNrzvu46PGv3xLbKvd9YXEXqHos9JlYimFAUPNjNCJNs37QPqCENRfCMYg5IbxEZaR2iAMvDSqY5d2yDEXk5NfBRTFn1BNlSgB5WjkIGEV7gQcuufcxLzWuT4F5VvH25695uaA0Q0A+KGDGn7NKcKNVZ7SzGrBdD7vg/V85gZiKf+D6Q6rpPTxeDev/I/Dd4Oof2MiyBpQaV4+Iw70a7EtkljaDbFO7nHaiMRiTsFlCeX/0nUMrTQPdNaQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Bh+l6lN2NlosGHdikCn2HRTZLKrPQ4DibVuiKO6IPdvLIe13klAibu0oOktOx/vQ5QJ2qFSukrGAqiBz7iQDyf3dUcyHIA/P6cxpyeieK2e5bzUNBQ4hwwIufhTlqT0IBSMpBzJDqpPtfl6eL5+gwdkv86zznI6YcFgHWpUVFf7b6eNNmXTUSIVDrvqdOUHCdnFQe44Rs8ekgKQHu1Ey5M1ygwr/CT2SGeRyTrlt9fNCuo9sjo+DR1CHQK1GoaN/FRkQ/3FjN9R6maZEm3ruOiXDtI5n8+sTOzr9tPc2+x8OBl77501cyFx9vlTXP0Zy3wiShsjWoBWjFRQUG7ILxg==
  • Cc: Jan Beulich <jbeulich@xxxxxxxx>, "julien@xxxxxxx" <julien@xxxxxxx>, "sstabellini@xxxxxxxxxx" <sstabellini@xxxxxxxxxx>, Oleksandr Tyshchenko <Oleksandr_Tyshchenko@xxxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Artem Mygaiev <Artem_Mygaiev@xxxxxxxx>, "andrew.cooper3@xxxxxxxxxx" <andrew.cooper3@xxxxxxxxxx>, "george.dunlap@xxxxxxxxxx" <george.dunlap@xxxxxxxxxx>, "paul@xxxxxxx" <paul@xxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Rahul Singh <rahul.singh@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Oleksandr Andrushchenko <Oleksandr_Andrushchenko@xxxxxxxx>
  • Delivery-date: Tue, 08 Feb 2022 13:52:26 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHYGZFc/MnzQOjwVEeBBUHLSW0md6yDBUkAgAASSACAAATYAIAAD/WAgAAKNgCAAAbfgIAABnuAgAAQvgCAAAMCAIAAAY4AgAADxICAABrnAIAABAgAgAR3CoCAABt5gIAAEpuAgAAE5ICAAASKAIAAAiiAgAAKNYCAAARNAIAAC1wAgAACRYCAAAGVgIAABJiAgAAB5wCAAPjsgIAANleAgAAGm4CAACiEAIAAA8eA
  • Thread-topic: [PATCH v6 03/13] vpci: move lock outside of struct vpci


On 08.02.22 15:38, Roger Pau Monné wrote:
> On Tue, Feb 08, 2022 at 11:13:41AM +0000, Oleksandr Andrushchenko wrote:
>>
>> On 08.02.22 12:50, Roger Pau Monné wrote:
>>> On Tue, Feb 08, 2022 at 07:35:34AM +0000, Oleksandr Andrushchenko wrote:
>>>> 5. You name it
>>>> ==============================================================
>>>>
>>>>    From all the above I would recommend we go with option 2 which seems to 
>>>> reliably
>>>> solve ABBA and does not bring cons of the other approaches.
>>> 6. per-domain rwlock + per-device vpci lock
>>>
>>> Introduce vpci_header_write_lock(start, {end, size}) helper: return
>>> whether a range requires the per-domain lock in write mode. This will
>>> only return true if the range overlaps with the BAR ROM or the command
>>> register.
>>>
>>> In vpci_{read,write}:
>>>
>>> if ( vpci_header_write_lock(...) )
>>>       /* Gain exclusive access to all of the domain pdevs vpci. */
>>>       write_lock(d->vpci);
>>> else
>>> {
>>>       read_lock(d->vpci);
>>>       spin_lock(vpci->lock);
>>> }
>>> ...
>>>
>>> The vpci assign/deassign functions would need to be modified to write
>>> lock the per-domain rwlock. The MSI-X table MMIO handler will also
>>> need to read lock the per domain vpci lock.
>> Ok, so it seems you are in favor of this implementation and I have
>> no objection as well. The only limitation we should be aware of is
>> that once a path has acquired the read lock it is not possible to do
>> any write path operations in there.
>> vpci_process_pending will acquire write lock though as it can
>> lead to vpci_remove_device on its error path.
>>
>> So, I am going to implement pdev->vpci->lock + d->vpci_lock
> I think it's the less uncertain option.
>
> As said, if you want to investigate whether you can successfully move
> the checking into vpci_process_pending that would also be fine with
> me, but I cannot assert it's going to be successful. OTOH I think the
> per-domain rwlock + per-device spinlock seems quite likely to solve
> our issues.
Ok, then I'll go with per-domain rwlock + per-device spinlock
and write lock in vpci_write for cmd + ROM. Of course other
places such as vpci_remove_device and vpci_process_pending
will use write lock
>
> Thanks, Roger.
>
Thank you,
Oleksandr

 


Rackspace

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