On 12.07.2023 13:09, Volodymyr Babchuk wrote: > Jan Beulich <[email protected]> writes: > >> Up front remark: I'm sorry for some possibly unhelpful replies below. I, >> for one, am of the opinion that some of the issues you ask about are to >> be looked into by whoever wants / needs to rework the locking model. >> After all this (likely) is why nobody has dared to make an attempt before >> the need became apparent. > > I have no great need desire or need to rework the locking model. I was > perfectly fine with much narrower vpci_lock. As you remember, it is > Roger who suggested to extend this lock to the include the whole PCI > device. > > I already tried something like this as part of the another patch series: > "[RFC,01/10] xen: pci: add per-domain pci list lock" [1], with the same > result: it was considered very hard to do this properly, so I dropped > that effort. I am not so familiar with x86-specific code as a whole and > IOMMU drivers in particular to be 100% sure that I am doing correct > changes. Without support from x86 guys I can't do proper patches and > looks like x86 guys are not interested in this.
That's not the case, no. The problem is time: I don't have the time to take on this effort myself. I'm willing to help where necessary, within reasonable bounds. But I can't realistically do large parts of the analysis that is inevitably needed. (I'm also a little sick of doing code audits for other, unrelated reasons.) Hence that earlier "up front" remark. > So, this is dead end. > > Roger, in [2] I proposed another approach to fix ABBA in modify_bars(): > store copy of BARs in the domain structure. Taking into account that my > effort to introduce d->pci_lock basically failed (again), I am proposing > to return back to d->vpci_lock + BARs shadow copy in the domain > struct. What do you think? And you, Jan? I support Roger's earlier request, and I think that doing what you propose would move us further away from where we want to arrive at some point. I'm sorry that this is all pretty unpleasant. Jan > [1] > https://lore.kernel.org/all/[email protected]/ > [2] https://lore.kernel.org/all/[email protected]/ >
