Hi folks: Thanks so much for the efforts. I prepared a branch which contains all our patches.The aim of the branch is for the VFIO maintainers to pull the whole bunch easily after the drm-intel-next got merged through drm (as one of the MMIO patches depends on a patch in drm-intel-next). I dropped patch 4 and patch 5 as they have been covered by Jani's patches. Some conflicts was solved. QA is going to test it today. You can find it here: git clone https://github.com/intel/gvt-linux -b for-christoph Thanks, Zhi. On 4/13/22 3:58 PM, Jani Nikula wrote: > On Wed, 13 Apr 2022, Christoph Hellwig <hch@xxxxxx> wrote: >> On Wed, Apr 13, 2022 at 01:47:05PM +0000, Wang, Zhi A wrote: >>>> the GVT code in the i915 is a bit of a mess right now due to strange >>>> abstractions and lots of indirect calls. This series refactors various >>>> bits to clean that up. The main user visible change is that almost all >>>> of the GVT code moves out of the main i915 driver and into the kvmgt >>>> module. >>> >>> Hi Christoph: >>> >>> Do you want me to merge the GVT-g patches in this series? Or you want them to get merged from your side? >> >> The two option here are drm tree via gvt and i915 trees or the vfio >> tree, neither of which really is my tree. >> >> We already have a fair bit of vfio changes at the tail end of the series, >> and Jason has some more that should sit on top of it, and I have some >> more that I haven't sent yet. >> >> So if we could get the MMIO table and Makefile cleanups into a topic >> branch that we could pull into the vfio tree and merge it through that >> that would seem easiest to me, assuming that is ok with the i915, drm >> and vfio maintainers. > > AFAICS the changes are mostly to gvt/, and at least I'm fine with the > minor changes to i915 (in this series and in my two patches) being > merged via whichever tree you all see fit. > > Acked-by: Jani Nikula <jani.nikula@xxxxxxxxx> > > Joonas, Tvrtko, Rodrigo, chime in now if you have any issues with that. > > > BR, > Jani. > >
