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.
