[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |