On Fri, Feb 25, 2022 at 11:57:05AM -0600, Alex Olson wrote: > I think there is an issue in the spin_lock handling of patch 2 for the > "msix_write" function as it results in the lock being taken a second time > while > held (hangs). > > The lock taken before checking "VMSIX_ADDR_IN_RANGE" isn't unlocked for the > non- > PBA case and a second lock is attempted just before the call to get_entry() > later in the same function. It looks like either the added lock should either > be moved inside the PBA case or the lock before get_entry() should be removed.
Sorry, was in a rush to send this before leaving yesterday and didn't refresh the commit before generating the patch, v2.1 should be fixed. Could you provide a 'Tested-by' if it work for you? > > On my server, upon loading the ioatdma driver, it now successfully attempts an > PBA write (which now doesn't crash the system), but I'm not sure I have a way > to > fully exercise it... Urg, that's weird, PBA should be read-only only according to the spec. Writes to PBA have undefined behavior. > > I also see a different (related) issue in which modify_bars is called on a > virtual function seemingly before the BAR addresses are initialized/known and > will start a different thread for that topic. SR-IOV is not supported on PVH dom0 yet, so that's not going to work. I've posted a series in 2018 to enable it, but sadly had no time to work on it anymore: https://lore.kernel.org/xen-devel/20180717094830.54806-1-roger....@citrix.com/ It's likely not going to apply cleanly, and there's a lot of comments to be fixed up there. Thanks, Roger.
