Re: [PATCH v1] drm/i915/gvt: Don't replace a DMA mapping that is still in use

[Zhenyu Wang <zhenyuw.linux@gmail.com>]

On Wed, Oct 14, 2026 at 03:25:33PM -0400, Yuho Choi wrote:
> On Tue, 13 Oct 2026 at 08:08, Zhenyu Wang <zhenyuw.linux@gmail.com> wrote:
> >
> > > You know this code much better than I do, and I can't test it without
> > > GVT-g hardware, so I may well be missing something.
> >
> > I can understand that but I think for any non-trivial change or
> > for sensitive part, testing is a must...
> 
> Understood. I'll hold this patch until I can test it on GVT-g hardware.
> 
> > > The case I had in mind is the guest mapping the same page at both sizes
> > > and keeping both, e.g. 2M in the PPGTT of one context and 4K in the GGTT
> > > or in another context's PPGTT. If the second request replaces the entry,
> > > the first shadow entry seems to keep the old DMA address, as
> > > shadow_ppgtt_mm() reuses a PPGTT that is already shadowed. Is that ruled
> > > out somewhere? Please let me know if so.
> >
> > Shadow ppgtt is created by a PV interface, so each context would have
> > separate shadow ppgtt or shadow mm. GVT handles guest page's dma
> > mapping per-vgpu as for per-VM. But GVT handles context submission in
> > order, shadow ppgtt is populated for each submission. I think even in
> > your example that possible one page mapped in different context as 4K
> > or 2M, it would be remapped as size doesn't match for each submission,
> > so no invalide dma address access.
> >
> > I doubt if i915 could possibly have such case in reality..
> 
> It does seem to happen: 7366aeb77cd8 was written after the same gfn was
> requested at both 4K and 2M during an OpenCL conformance test.

ok..so that was actually a fix to remap guest page when populate
shadow ppgtt, it's a little hacky but as for gvt procedure, it works.
Your change might also work but have a penalty to an extra 2M split
with extra dma mapping effort..