On Wed, 26 Nov 2025 15:46:43 +0100 Michał Winiarski <[email protected]> wrote:
> On Wed, Nov 26, 2025 at 12:38:34PM +0100, Thomas Hellström wrote: > > On Tue, 2025-11-25 at 17:20 -0800, Matthew Brost wrote: > > > On Tue, Nov 25, 2025 at 01:13:15PM -0700, Alex Williamson wrote: > > > > On Tue, 25 Nov 2025 00:08:37 +0100 > > > > Michał Winiarski <[email protected]> wrote: > > > > > > > > > Hi, > > > > > > > > > > We're now at v6, thanks for all the review feedback. > > > > > > > > > > First 24 patches are now already merged through drm-tip tree, and > > > > > I hope > > > > > we can get the remaining ones through the VFIO tree. > > > > > > > > Are all those dependencies in a topic branch somewhere? Otherwise > > > > to > > > > go in through vfio would mean we need to rebase our next branch > > > > after > > > > drm is merged. LPC is happening during this merge window, so we > > > > may > > > > not be able to achieve that leniency in ordering. Is the better > > > > approach to get acks on the variant driver and funnel the whole > > > > thing > > > > through the drm tree? Thanks, > > > > > > +1 on merging through drm if VFIO maintainers are ok with this. I've > > > done this for various drm external changes in the past with > > > maintainers > > > acks. > > > > > > Matt > > > > @Michal Winiarski > > > > Are these patches depending on any other VFIO changes that are queued > > for 6.19? > > No, there's a series that I'm working on in parallel: > https://lore.kernel.org/lkml/[email protected]/ > > Which will potentially change the VFIO driver that's part of this > series. > But I believe that this could go through fixes, after we have all the > pieces in place as part of 6.19-rc release. 6.19-rc or 6.19+1, depends on to what extent we decide the other variant drivers have this same problem. This driver has worked around it in the traditional way though and I don't think it needs to be delayed for a universal helper. > > If not and with proper VFIO acks, I could ask Dave / Sima to allow this > > for drm-xe-next-fixes pull. Then I also would need a strong > > justification for it being in 6.19 rather in 7.0. > > > > Otherwise we'd need to have the VFIO changes it depends on in a topic > > branch, or target this for 7.0 and hold off the merge until we can > > backmerge 6.9-rc1. > > Unless Alex has a different opinion, I think the justification would be > that this is just a matter of logistics - merging through DRM would just > be a simpler process than merging through VFIO. End result would be the > same. Yes, the result is the same, logistics of waiting for the drm-next merge, rebasing, and sending a 2nd vfio pull request is the overhead. The easier route through drm still depends on getting full acks on this and whether drm will take it. Thanks, Alex
