On Wed, Oct 14, 2026 at 03:25:33PM -0400, Yuho Choi wrote: > On Tue, 13 Oct 2026 at 08:08, Zhenyu Wang <[email protected]> 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..
