On Wed, 13 Apr 2022, Christoph Hellwig hch@lst.de 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@intel.com
Joonas, Tvrtko, Rodrigo, chime in now if you have any issues with that.
BR, Jani.
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@lst.de 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@intel.com
Joonas, Tvrtko, Rodrigo, chime in now if you have any issues with that.
BR, Jani.
On Wed, Apr 13, 2022 at 11:13:06PM +0000, Wang, Zhi A wrote:
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
There are alot of extra commits on there - is it possible to base this straight on rc1 not on some kind of existing DRM tree?
Why did you choose drm/i915/fbc: Call intel_fbc_activate() directly from frontbuffer flush as a base?
Jason
On 4/13/22 11:20 PM, Jason Gunthorpe wrote:
On Wed, Apr 13, 2022 at 11:13:06PM +0000, Wang, Zhi A wrote:
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
There are alot of extra commits on there - is it possible to base this straight on rc1 not on some kind of existing DRM tree?
Why did you choose drm/i915/fbc: Call intel_fbc_activate() directly from frontbuffer flush as a base?
Jason
Hi Jason:
I updated the branch. You can check if those are what you are expecting. :)
Thanks, Zhi.
On Thu, Apr 14, 2022 at 12:20:42PM +0000, Wang, Zhi A wrote:
On 4/13/22 11:20 PM, Jason Gunthorpe wrote:
On Wed, Apr 13, 2022 at 11:13:06PM +0000, Wang, Zhi A wrote:
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
There are alot of extra commits on there - is it possible to base this straight on rc1 not on some kind of existing DRM tree?
Why did you choose drm/i915/fbc: Call intel_fbc_activate() directly from frontbuffer flush as a base?
Jason
Hi Jason:
I updated the branch. You can check if those are what you are expecting. :)
This is better, except for the first commit:
[DON'T PULL] drm/i915/dmc: split out dmc registers to a separate file THIS PATCH WILL GO THROUGH DRM-INTEL-NEXT TO UPSTREAM
Clean up the massive i915_reg.h a bit with this isolated set of registers.
v2: Remove stale comment (Lucas)
Clean the commit message and send that as a proper PR to drm-intel-next, then everything else is OK.
Jason
On 4/14/22 1:34 PM, Jason Gunthorpe wrote:
On Thu, Apr 14, 2022 at 12:20:42PM +0000, Wang, Zhi A wrote:
On 4/13/22 11:20 PM, Jason Gunthorpe wrote:
On Wed, Apr 13, 2022 at 11:13:06PM +0000, Wang, Zhi A wrote:
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
There are alot of extra commits on there - is it possible to base this straight on rc1 not on some kind of existing DRM tree?
Why did you choose drm/i915/fbc: Call intel_fbc_activate() directly from frontbuffer flush as a base?
Jason
Hi Jason:
This one belongs to i915, which has already been queued in drm-intel-next, but not yet reached to the top. When it is landed in -rc, I will rebase this branch on it, then we can drop this patch in this branch.
I updated the branch. You can check if those are what you are expecting. :)
This is better, except for the first commit:
[DON'T PULL] drm/i915/dmc: split out dmc registers to a separate file THIS PATCH WILL GO THROUGH DRM-INTEL-NEXT TO UPSTREAM
Clean up the massive i915_reg.h a bit with this isolated set of registers.
v2: Remove stale comment (Lucas)
Clean the commit message and send that as a proper PR to drm-intel-next, then everything else is OK.
Jason
On Thu, Apr 14, 2022 at 01:39:11PM +0000, Wang, Zhi A wrote:
On 4/14/22 1:34 PM, Jason Gunthorpe wrote:
On Thu, Apr 14, 2022 at 12:20:42PM +0000, Wang, Zhi A wrote:
On 4/13/22 11:20 PM, Jason Gunthorpe wrote:
On Wed, Apr 13, 2022 at 11:13:06PM +0000, Wang, Zhi A wrote:
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
There are alot of extra commits on there - is it possible to base this straight on rc1 not on some kind of existing DRM tree?
Why did you choose drm/i915/fbc: Call intel_fbc_activate() directly from frontbuffer flush as a base?
Jason
Hi Jason:
This one belongs to i915, which has already been queued in drm-intel-next, but not yet reached to the top. When it is landed in -rc, I will rebase this branch on it, then we can drop this patch in this branch.
A commit called 'split out dmc registers' with no Fixes: will be sent to a rc?
Jason
On Thu, 14 Apr 2022, Jason Gunthorpe jgg@nvidia.com wrote:
On Thu, Apr 14, 2022 at 01:39:11PM +0000, Wang, Zhi A wrote:
This one belongs to i915, which has already been queued in drm-intel-next, but not yet reached to the top. When it is landed in -rc, I will rebase this branch on it, then we can drop this patch in this branch.
A commit called 'split out dmc registers' with no Fixes: will be sent to a rc?
Won't. It's in drm-intel-next (and drm-next), headed to v5.19.
BR, Jani.
On Thu, 14 Apr 2022, Jason Gunthorpe jgg@nvidia.com wrote:
On Thu, Apr 14, 2022 at 12:20:42PM +0000, Wang, Zhi A wrote:
On 4/13/22 11:20 PM, Jason Gunthorpe wrote:
On Wed, Apr 13, 2022 at 11:13:06PM +0000, Wang, Zhi A wrote:
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
There are alot of extra commits on there - is it possible to base this straight on rc1 not on some kind of existing DRM tree?
Why did you choose drm/i915/fbc: Call intel_fbc_activate() directly from frontbuffer flush as a base?
Jason
Hi Jason:
I updated the branch. You can check if those are what you are expecting. :)
This is better, except for the first commit:
[DON'T PULL] drm/i915/dmc: split out dmc registers to a separate file THIS PATCH WILL GO THROUGH DRM-INTEL-NEXT TO UPSTREAM
Clean up the massive i915_reg.h a bit with this isolated set of registers.
v2: Remove stale comment (Lucas)
Clean the commit message and send that as a proper PR to drm-intel-next, then everything else is OK.
It's already in drm-intel-next, I guess the problem is basing the branch on something that doesn't have it. I'd probably just base everything cleanly on -rc1, and whoever does the merge between the two will need to account for the missing include in the result. It's just adding one line in the right place.
BR, Jani.
On Thu, Apr 14, 2022 at 04:40:11PM +0300, Jani Nikula wrote:
git clone https://github.com/intel/gvt-linux -b for-christoph
There are alot of extra commits on there - is it possible to base this straight on rc1 not on some kind of existing DRM tree?
Why did you choose drm/i915/fbc: Call intel_fbc_activate() directly from frontbuffer flush as a base?
Jason
Hi Jason:
I updated the branch. You can check if those are what you are expecting. :)
This is better, except for the first commit:
[DON'T PULL] drm/i915/dmc: split out dmc registers to a separate file THIS PATCH WILL GO THROUGH DRM-INTEL-NEXT TO UPSTREAM
Clean up the massive i915_reg.h a bit with this isolated set of registers.
v2: Remove stale comment (Lucas)
Clean the commit message and send that as a proper PR to drm-intel-next, then everything else is OK.
It's already in drm-intel-next, I guess the problem is basing the branch on something that doesn't have it. I'd probably just base everything cleanly on -rc1, and whoever does the merge between the two will need to account for the missing include in the result. It's just adding one line in the right place.
That makes sense to me, especially if you can do the merge fixup internally in DRM.
So drop the '[DONT PULL]' commit and send a PR to the next DRM tree - when that is confirmed send the same PR to vfio,
Thanks, Jason
On 4/14/22 1:43 PM, Jason Gunthorpe wrote:
On Thu, Apr 14, 2022 at 04:40:11PM +0300, Jani Nikula wrote:
git clone https://github.com/intel/gvt-linux -b for-christoph
There are alot of extra commits on there - is it possible to base this straight on rc1 not on some kind of existing DRM tree?
Why did you choose drm/i915/fbc: Call intel_fbc_activate() directly from frontbuffer flush as a base?
Jason
Hi Jason:
I updated the branch. You can check if those are what you are expecting. :)
This is better, except for the first commit:
[DON'T PULL] drm/i915/dmc: split out dmc registers to a separate file THIS PATCH WILL GO THROUGH DRM-INTEL-NEXT TO UPSTREAM
Clean up the massive i915_reg.h a bit with this isolated set of registers.
v2: Remove stale comment (Lucas)
Clean the commit message and send that as a proper PR to drm-intel-next, then everything else is OK.
It's already in drm-intel-next, I guess the problem is basing the branch on something that doesn't have it. I'd probably just base everything cleanly on -rc1, and whoever does the merge between the two will need to account for the missing include in the result. It's just adding one line in the right place.
That makes sense to me, especially if you can do the merge fixup internally in DRM.
So drop the '[DONT PULL]' commit and send a PR to the next DRM tree - when that is confirmed send the same PR to vfio,
I updated the branch again, but I am confused. What is the purpose of sending the PR to next DRM tree? I suppose all the patches will go through VFIO? If I understand correctly?
Thanks, Jason
On Thu, Apr 14, 2022 at 02:25:36PM +0000, Wang, Zhi A wrote:
So drop the '[DONT PULL]' commit and send a PR to the next DRM tree - when that is confirmed send the same PR to vfio,
I updated the branch again, but I am confused. What is the purpose of sending the PR to next DRM tree? I suppose all the patches will go through VFIO? If I understand correctly?
pull requests can flow through more than one tree concurrently. The purpose of the topic branch is to allow all the commits to be in all the trees they need to be in at once.
So you should send this branch as a PR to the next logical upstream tree gvt patches normally go through, in the usual way that you send PRs. Especially in this case where there is a small merge conflict internal to DRM to resolve. I'm assuming this is the drm-intel-next tree?
Once DRM is internally happy then VFIO can merge it as well. You can view VFIO as the secondary path to Linus, DRM as primary. Alex will mention in his pull request that VFIO has a 'shared branch with DRM for gvt'.
Jason
dri-devel@lists.freedesktop.org
-
Jani Nikula -
Jason Gunthorpe -
Wang, Zhi A