On Thu, Jan 02, 2025 at 11:38:32AM -0700, Alex Williamson wrote: > 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, #regzbot fix: 09dfc8a5f2ce ("vfio/pci: Fallback huge faults for unaligned pfn") 09dfc8a5f2ce appeared in v6.13-rc7.
