Hi Chris, thanks for the reply! Without this patch, we have to do pattern scan to identify if the page is still being used as a PT page. :( It's complicated. Originally, all the guest shadow PPGTT pages will be set to write-protected by HV. When guest makes a change in its page table, it will be trapped by HV. For example: Guest updates a PTE entry in a PTE PT page, then HV will be notified and populate the shadow PPGTT page table accordingly. Now let's say a PTE PT is empty (all mappings are pointing to scratch page) and will be freed in the newer kernel. If guest freed the PT page first, this page could be used by anyone while HV is still treating this page as PT page, then things goes wrong here. HV has to identify the page is not being used as PT page anymore at this time. While if the guest updated the upper level PT entry first, HV will know the PTE PT page will not be used as a page table page, and stop track that page at this time. Then following accesses to that page will not be trapped by HV and surely HV will not see unrecognized PT entry writing (this page may be used by other guy at this time.) Thanks, Zhi. > -----Original Message----- > From: Chris Wilson [mailto:chris@xxxxxxxxxxxxxxxxxx] > Sent: Tuesday, November 22, 2016 10:38 PM > To: Wang, Zhi A > Cc: intel-gfx@xxxxxxxxxxxxxxxxxxxxx; Winiarski, Michal; Thierry, Michel; Joonas > Lahtinen; Zhenyu Wang; Lv, Zhiyuan > Subject: Re: [PATCH] drm/i915: Move the release of PT page to the upper caller > > On Tue, Nov 22, 2016 at 09:29:40PM +0800, Zhi Wang wrote: > > Hi guys: > > Would you mind to have a quick review on this patch? :P The linux > > guest under GVT-g couldn't boot up without this patch in the newer > > kernel. > > > > Thanks, > > Zhi. > > > > On 11/21/16 19:44, Zhi Wang wrote: > > >a PT page will be released if it doesn't contain any meaningful > > >mappings during PPGTT page table shrinking. The PT entry in the upper > > >level will be set to a scratch entry. > > > > > >Normally this works nicely, but in virtualization world, the PPGTT > > >page table is tracked by hypervisor. Releasing the PT page before > > >modifying the upper level PT entry would cause extra efforts. > > > > > >As the tracked page has been returned to OS before losing track from > > >hypervisor, it could be written in any pattern. Hypervisor has to > > >recognize if a page is still being used as a PT page by validating > > >these writing patterns. It's complicated. Better let the guest modify > > >the PT entry in upper level PT first, then release the PT page. > > > > > >Cc: Michał Winiarski <michal.winiarski@xxxxxxxxx> > > >Cc: Michel Thierry <michel.thierry@xxxxxxxxx> > > >Cc: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx> > > >Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > >Cc: Zhenyu Wang <zhenyuw@xxxxxxxxxxxxxxx> > > >Cc: Zhiyuan Lv <zhiyuan.lv@xxxxxxxxx> > > >Signed-off-by: Zhi Wang <zhi.a.wang@xxxxxxxxx> > > The original didn't make it to me, so I just assumed a list issue. > > For the record, I'd like to have some more detail on just when the hv is doing > the page scanning. It makes it sound like you are actively scanning an idle > range. > > Reviewed-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
