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

[Yuho Choi]

Thanks for the review!

On Fri, 9 Oct 2026 at 23:59, Zhenyu Wang <zhenyuw.linux@xxxxxxxxx> 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.

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.

> 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.