On Thu, 2 Jan 2025 10:04:02 -0700 Alex Williamson <alex.williamson@xxxxxxxxxx> wrote: > On Thu, 2 Jan 2025 11:39:23 -0500 > Peter Xu <peterx@xxxxxxxxxx> wrote: > > OTOH, a pure question here is whether we should check pfn+pgoff instead of > > pgoff alone. I have no idea how firmware would allocate BAR resources, > > especially on start address alignments. I assume that needs to be somehow > > relevant to the max size of the bar, probably the start address should > > always be aligned to that max bar size? If so, there should have no > > functional difference checking either pfn+pgoff or pgoff. It could be a > > matter of readability in that case, saying that the limitation is about pfn > > (of pgtable) rather than directly relevant to the offset of the bar. > > Yes, I'm working on the proper patch now that we have a root cause and > I'm changing this to test alignment of pfn+pgoff. The PCI BARs > themselves are required to have natural alignment, but the vma mapping > the BAR could be at an offset from the base of the BAR, which is > accounted for in our local vma_to_pfn() function. So I agree that > pfn+pgoff is the more complete fix, which I'll post soon, and hope that > Precific can re-verify the fix. Thanks, The proposed fix is now posted here: https://lore.kernel.org/all/20250102183416.1841878-1-alex.williamson@xxxxxxxxxx Please reply there with Tested-by and Reviewed-by as available. Thanks, Alex
