On 02.12.2023 02:27, 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. 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 latter must be acquired first.
Shouldn't an abridged version of this also be put ... > --- a/xen/include/xen/sched.h > +++ b/xen/include/xen/sched.h > @@ -461,6 +461,7 @@ struct domain > > #ifdef CONFIG_HAS_PCI > struct list_head pdev_list; > + rwlock_t pci_lock; > #endif ... here, for easy future reference? As locking is going to become more complicated, documenting lock nesting rules in code is imo pretty important. Jan
