Re: [Qemu-devel] [iGVT-g] <summary> RE: VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...)

[Tian, Kevin]

> From: Song, Jike
> Sent: Thursday, February 04, 2016 11:05 PM
> 
> On 02/04/2016 12:16 PM, Tian, Kevin wrote:
> >>>>> 5) Pin/unpin guest memory
> >>>>> --
> >>>>> IGD or any PCI passthru should have same requirement. So we should be
> >>>>> able to leverage existing code in VFIO. The only tricky thing (Jike may
> >>>>> elaborate after he is back), is that KVMGT requires to pin EPT entry 
> >>>>> too,
> >>>>> which requires some further change in KVM side. But I'm not sure whether
> >>>>> it still holds true after some design changes made in this thread. So 
> >>>>> I'll
> >>>>> leave to Jike to further comment.
> >>>>
> >>>> PCI assignment requires pinning all of guest memory, I would think that
> >>>> IGD would only need to pin selective memory, so is this simply stating
> >>>> that both have the need to pin memory, not that they'll do it to the
> >>>> same extent?
> >>>
> >>> For simplicity let's first pin all memory, while taking selective pinning 
> >>> as a
> >>> future enhancement.
> >>>
> >>> The tricky thing is that existing 'pin' action in VFIO doesn't actually 
> >>> pin
> >>> EPT entry too (only pin host page tables for Qemu process). There are
> >>> various places where EPT entries might be invalidated when guest is
> >>> running, while KVMGT requires EPT entries to be pinned too. Let's wait
> >>> for Jike to elaborate whether this part is still required today.
> >>
> >> Sorry, don't quite follow the logic here. The current VFIO TYPE1 IOMMU 
> >> (including API
> >> and underlying IOMMU implementation) will pin the guest physical memory and
> >> install those pages to the proper device domain. Yes, it is only for the 
> >> QEMU
> >> process as that is what the VM is running at.
> >>
> >> Do I miss something here?
> >
> > For Qemu there are two page tables involved: one is host page table as
> > you mentioned here for root mode, the other is EPT page table used
> > as the 2nd level translation when guest is running in non-root mode. I'm
> > not sure why KVMGT requires to pin EPT entry. Jike should know better
> > here.
> >
> 
> There may be some misunderstanding here - KVMGT doesn't need to pin EPT
> entries. Previously I mentioned spte pinning, only because that, at that
> time we wanted to query pfn for a given gfn by KVM MMU (rmap + spte). Now
> we have better way of this.
> 
> I promise this is not a problem :)
> 

Thanks Jike for confirmation. Then we can reuse existing pin mechanism
in VFIO which is much easier.

Thanks
Kevin