qemu-devel.nongnu.org archive mirror
 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>, Jike Song <albcamus@gmail.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Kirti Wankhede <kwankhede@nvidia.com>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	"kraxel@redhat.com" <kraxel@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"Ruan, Shuai" <shuai.ruan@intel.com>,
	"Lv, Zhiyuan" <zhiyuan.lv@intel.com>
Subject: Re: [Qemu-devel] [RFC PATCH v3 3/3] VFIO Type1 IOMMU change: to support with iommu and without iommu
Date: Fri, 13 May 2016 14:22:37 +0800	[thread overview]
Message-ID: <573572AD.2010407@intel.com> (raw)
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D15F853FE9@SHSMSX101.ccr.corp.intel.com>

On 05/13/2016 10:41 AM, Tian, Kevin wrote:
>> From: Neo Jia [mailto:cjia@nvidia.com]
>> Sent: Friday, May 13, 2016 3:49 AM
>>
>>>
>>>> Perhaps one possibility would be to allow the vgpu driver to register
>>>> map and unmap callbacks.  The unmap callback might provide the
>>>> invalidation interface that we're so far missing.  The combination of
>>>> map and unmap callbacks might simplify the Intel approach of pinning the
>>>> entire VM memory space, ie. for each map callback do a translation
>>>> (pin) and dma_map_page, for each unmap do a dma_unmap_page and release
>>>> the translation.
>>>
>>> Yes adding map/unmap ops in pGPU drvier (I assume you are refering to
>>> gpu_device_ops as
>>> implemented in Kirti's patch) sounds a good idea, satisfying both: 1)
>>> keeping vGPU purely
>>> virtual; 2) dealing with the Linux DMA API to achive hardware IOMMU
>>> compatibility.
>>>
>>> PS, this has very little to do with pinning wholly or partially. Intel KVMGT has
>>> once been had the whole guest memory pinned, only because we used a spinlock,
>>> which can't sleep at runtime.  We have removed that spinlock in our another
>>> upstreaming effort, not here but for i915 driver, so probably no biggie.
>>>
>>
>> OK, then you guys don't need to pin everything. The next question will be if you
>> can send the pinning request from your mediated driver backend to request memory
>> pinning like we have demonstrated in the v3 patch, function vfio_pin_pages and
>> vfio_unpin_pages?
>>
> 
> Jike can you confirm this statement? My feeling is that we don't have such logic
> in our device model to figure out which pages need to be pinned on demand. So
> currently pin-everything is same requirement in both KVM and Xen side...

[Correct me in case of any neglect:)]

IMO the ultimate reason to pin a page, is for DMA. Accessing RAM from a GPU is
certainly a DMA operation. The DMA facility of most platforms, IGD and NVIDIA
GPU included, is not capable of faulting-handling-retrying.

As for vGPU solutions like Nvidia and Intel provide, the memory address region
used by Guest for GPU access, whenever Guest sets the mappings, it is
intercepted by Host, so it's safe to only pin the page before it get used by
Guest. This probably doesn't need device model to change :)


--
Thanks,
Jike

  reply	other threads:[~2016-05-13  6:23 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-02 18:40 [Qemu-devel] [RFC PATCH v3 0/3] Add vGPU support Kirti Wankhede
2016-05-02 18:40 ` [Qemu-devel] [RFC PATCH v3 1/3] vGPU Core driver Kirti Wankhede
2016-05-03 22:43   ` Alex Williamson
2016-05-04  2:45     ` Tian, Kevin
2016-05-04 16:57       ` Alex Williamson
2016-05-05  8:58         ` Tian, Kevin
2016-05-04  2:58     ` Tian, Kevin
2016-05-12  8:22       ` Tian, Kevin
2016-05-04 13:31     ` Kirti Wankhede
2016-05-05  9:06       ` Tian, Kevin
2016-05-05 10:44         ` Kirti Wankhede
2016-05-05 12:07           ` Tian, Kevin
2016-05-05 12:57             ` Kirti Wankhede
2016-05-11  6:37               ` Tian, Kevin
2016-05-06 12:14         ` Jike Song
2016-05-06 16:16           ` Kirti Wankhede
2016-05-09 12:12             ` Jike Song
2016-05-02 18:40 ` [Qemu-devel] [RFC PATCH v3 2/3] VFIO driver for vGPU device Kirti Wankhede
2016-05-03 22:43   ` Alex Williamson
2016-05-04  3:23     ` Tian, Kevin
2016-05-04 17:06       ` Alex Williamson
2016-05-04 21:14         ` Neo Jia
2016-05-05  4:42           ` Kirti Wankhede
2016-05-05  9:24         ` Tian, Kevin
2016-05-05 20:27           ` Neo Jia
2016-05-11  6:45         ` Tian, Kevin
2016-05-11 20:10           ` Alex Williamson
2016-05-12  0:59             ` Tian, Kevin
2016-05-04 16:25     ` Kirti Wankhede
2016-05-02 18:40 ` [Qemu-devel] [RFC PATCH v3 3/3] VFIO Type1 IOMMU change: to support with iommu and without iommu Kirti Wankhede
2016-05-03 10:40   ` Jike Song
2016-05-03 22:43   ` Alex Williamson
2016-05-04  3:39     ` Tian, Kevin
2016-05-05  6:55     ` Jike Song
2016-05-05  9:27       ` Tian, Kevin
2016-05-10  7:52         ` Jike Song
2016-05-10 16:02           ` Neo Jia
2016-05-11  9:15             ` Jike Song
2016-05-11 22:06               ` Alex Williamson
2016-05-12  4:11                 ` Jike Song
2016-05-12 19:49                   ` Neo Jia
2016-05-13  2:41                     ` Tian, Kevin
2016-05-13  6:22                       ` Jike Song [this message]
2016-05-13  6:43                         ` Neo Jia
2016-05-13  7:30                           ` Jike Song
2016-05-13  7:42                             ` Neo Jia
2016-05-13  7:45                               ` Tian, Kevin
2016-05-13  8:31                                 ` Neo Jia
2016-05-13  9:23                                   ` Jike Song
2016-05-13 15:50                                     ` Neo Jia
2016-05-16  6:57                                       ` Jike Song
2016-05-13  6:08                     ` Jike Song
2016-05-13  6:41                       ` Neo Jia
2016-05-13  7:13                         ` Tian, Kevin
2016-05-13  7:38                           ` Neo Jia
2016-05-13  8:02                             ` Tian, Kevin
2016-05-13  8:41                               ` Neo Jia
2016-05-12  8:00                 ` Tian, Kevin
2016-05-12 19:05                   ` Alex Williamson
2016-05-12 20:12                     ` Neo Jia
2016-05-13  9:46                       ` Jike Song
2016-05-13 15:48                         ` Neo Jia
2016-05-16  2:27                           ` Jike Song
2016-05-13  3:55                     ` Tian, Kevin
2016-05-13 16:16                       ` Alex Williamson
2016-05-13  7:10                     ` Dong Jia
2016-05-13  7:24                       ` Neo Jia
2016-05-13  8:39                         ` Dong Jia
2016-05-13  9:05                           ` Neo Jia
2016-05-19  7:28                             ` Dong Jia
2016-05-20  3:21                               ` Tian, Kevin
2016-06-06  6:59                                 ` Dong Jia
2016-06-07  2:47                                   ` Tian, Kevin
2016-06-07  7:04                                     ` Dong Jia
2016-05-05  7:51     ` Kirti Wankhede
2016-05-04  1:05 ` [Qemu-devel] [RFC PATCH v3 0/3] Add vGPU support Tian, Kevin
2016-05-04  6:17   ` Neo Jia
2016-05-04 17:07     ` Alex Williamson

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=573572AD.2010407@intel.com \
    --to=jike.song@intel.com \
    --cc=albcamus@gmail.com \
    --cc=alex.williamson@redhat.com \
    --cc=cjia@nvidia.com \
    --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=shuai.ruan@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).