Re: [PATCH v6 0/4] vfio/xe: Add driver variant for Xe VF migration

[Alex Williamson]

On Wed, 26 Nov 2025 15:46:43 +0100
Michał Winiarski <michal.winiarski@xxxxxxxxx> 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 <michal.winiarski@xxxxxxxxx> 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/20251120123647.3522082-1-michal.winiarski@xxxxxxxxx/
> 
> 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