On Mon, Oct 12, 2026 at 12:01:31AM -0400, Yuho Choi wrote: > Thanks for the review! > > On Fri, 9 Oct 2026 at 23:59, Zhenyu Wang <[email protected]> wrote: > > > > I don't think this is *real*, as code would simply destroy entry in > > that case, and there won't be on-the-fly dma operation on that, as > > guest mem setup is totally before execlist submission, if guest driver > > changed mapping by ignoring gvt emulated execlist status, that's just bad... > > 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... > > 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.. > > > So this change would always force 2M to split into 4K? why? > > No, only when a 4K entry for the same gfn is cached at the time of the > 2M request. With no entry or a 2M entry nothing changes, and a 4K > request now reuses an existing 2M entry instead of replacing it.
