On Mon, 15 Jul 2024 13:35:41 -0700
Axel Rasmussen <axelrasmussen@xxxxxxxxxx> wrote:
> I tried out Sasha's suggestion. Note that *just* taking
> aac6db75a9 ("vfio/pci: Use unmap_mapping_range()") is not sufficient, we also
> need b7c5e64fec ("vfio: Create vfio_fs_type with inode per device").
>
> But, the good news is both of those apply more or less cleanly to 6.6. And, at
> least under a very basic test which exercises VFIO memory mapping, things seem
> to work properly with that change.
>
> I would agree with Leah that these seem a bit big to be stable fixes. But, I'm
> encouraged by the fact that Sasha suggested taking them. If there are no big
> objections (Alex? :) ) I can send the backport patches this week.
>
If you were to take those, I think you'd also want:
d71a989cf5d9 ("vfio/pci: Insert full vma on mmap'd MMIO fault")
which helps avoid a potential regression in VM startup latency vs
faulting each page of the VMA. Ideally we'd have had huge_fault
working for pfnmaps before this conversion to avoid the latter commit.
I'm a bit confused by the lineage here though, 35e351780fa9 ("fork:
defer linking file vma until vma is fully initialized") entered v6.9
whereas these vfio changes all came in v6.10, so why does the v6.6
backport end up with dependencies on these newer commits? Is there
something that needs to be fixed in v6.9-stable as well?
Aside from the size of aac6db75a9 in particular, I'm not aware of any
outstanding issues that would otherwise dissuade backport to
v6.6-stable. Thanks,
Alex
