lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251126084023.705ebca1.alex@shazbot.org>
Date: Wed, 26 Nov 2025 08:40:23 -0700
From: Alex Williamson <alex@...zbot.org>
To: Michał Winiarski <michal.winiarski@...el.com>
Cc: Thomas Hellström <thomas.hellstrom@...ux.intel.com>,
 Matthew Brost <matthew.brost@...el.com>, Lucas De Marchi
 <lucas.demarchi@...el.com>, Rodrigo Vivi <rodrigo.vivi@...el.com>, Jason
 Gunthorpe <jgg@...pe.ca>, Yishai Hadas <yishaih@...dia.com>, Kevin Tian
 <kevin.tian@...el.com>, Shameer Kolothum <skolothumtho@...dia.com>,
 <intel-xe@...ts.freedesktop.org>, <linux-kernel@...r.kernel.org>,
 <kvm@...r.kernel.org>, Michal Wajdeczko <michal.wajdeczko@...el.com>,
 <dri-devel@...ts.freedesktop.org>, Jani Nikula
 <jani.nikula@...ux.intel.com>, Joonas Lahtinen
 <joonas.lahtinen@...ux.intel.com>, Tvrtko Ursulin <tursulin@...ulin.net>,
 David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, "Lukasz
 Laguna" <lukasz.laguna@...el.com>, Christoph Hellwig <hch@...radead.org>
Subject: Re: [PATCH v6 0/4] vfio/xe: Add driver variant for Xe VF migration

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ