All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jike Song <jike.song@intel.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: Neo Jia <cjia@nvidia.com>, Yang Zhang <yang.zhang.wz@gmail.com>,
	"igvt-g@lists.01.org" <igvt-g@ml01.01.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	qemu-devel <qemu-devel@nongnu.org>,
	Kirti Wankhede <kwankhede@nvidia.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	"Lv, Zhiyuan" <zhiyuan.lv@intel.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Qemu-devel] [iGVT-g] <summary> RE: VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...)
Date: Thu, 04 Feb 2016 23:04:35 +0800	[thread overview]
Message-ID: <56B36883.20205@intel.com> (raw)
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D15F79DE8F@SHSMSX103.ccr.corp.intel.com>

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

WARNING: multiple messages have this Message-ID (diff)
From: Jike Song <jike.song@intel.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: Yang Zhang <yang.zhang.wz@gmail.com>,
	"igvt-g@lists.01.org" <igvt-g@ml01.01.org>,
	Neo Jia <cjia@nvidia.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	qemu-devel <qemu-devel@nongnu.org>,
	Kirti Wankhede <kwankhede@nvidia.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	"Lv, Zhiyuan" <zhiyuan.lv@intel.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Qemu-devel] [iGVT-g] <summary> RE: VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...)
Date: Thu, 04 Feb 2016 23:04:35 +0800	[thread overview]
Message-ID: <56B36883.20205@intel.com> (raw)
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D15F79DE8F@SHSMSX103.ccr.corp.intel.com>

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

  reply	other threads:[~2016-02-04 15:05 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-03  8:04 <summary> RE: [iGVT-g] VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...) Tian, Kevin
2016-02-03  8:04 ` [Qemu-devel] " Tian, Kevin
2016-02-03  8:41 ` Neo Jia
2016-02-03  8:41   ` [Qemu-devel] " Neo Jia
2016-02-03 20:44 ` Alex Williamson
2016-02-03 20:44   ` [Qemu-devel] " Alex Williamson
2016-02-04  3:01   ` Tian, Kevin
2016-02-04  3:01     ` [Qemu-devel] " Tian, Kevin
2016-02-04  3:52     ` [iGVT-g] <summary> " Neo Jia
2016-02-04  3:52       ` [Qemu-devel] " Neo Jia
2016-02-04  4:16       ` Tian, Kevin
2016-02-04  4:16         ` [Qemu-devel] " Tian, Kevin
2016-02-04 15:04         ` Jike Song [this message]
2016-02-04 15:04           ` Jike Song
2016-02-05  2:01           ` Tian, Kevin
2016-02-05  2:01             ` Tian, Kevin
2016-02-16  6:40   ` <summary> RE: [iGVT-g] " Tian, Kevin
2016-02-16  6:40     ` [Qemu-devel] " Tian, Kevin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56B36883.20205@intel.com \
    --to=jike.song@intel.com \
    --cc=alex.williamson@redhat.com \
    --cc=cjia@nvidia.com \
    --cc=igvt-g@ml01.01.org \
    --cc=kevin.tian@intel.com \
    --cc=kraxel@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=kwankhede@nvidia.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=yang.zhang.wz@gmail.com \
    --cc=zhiyuan.lv@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.