linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Xiao Guangrong <guangrong.xiao@linux.intel.com>
To: Paolo Bonzini <pbonzini@redhat.com>, Neo Jia <cjia@nvidia.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	"Kirti Wankhede" <kwankhede@nvidia.com>,
	"Andrea Arcangeli" <aarcange@redhat.com>,
	"Radim Krčmář" <rkrcmar@redhat.com>
Subject: Re: [PATCH 0/2] KVM: MMU: support VMAs that got remap_pfn_range-ed
Date: Thu, 7 Jul 2016 10:36:44 +0800	[thread overview]
Message-ID: <577DC03C.1000602@linux.intel.com> (raw)
In-Reply-To: <6c882628-57bd-b309-5156-519a1405ecec@redhat.com>



On 07/06/2016 07:48 PM, Paolo Bonzini wrote:
>
>
> On 06/07/2016 06:02, Xiao Guangrong wrote:
>>>>
>>>>>
>>>>> May I ask you what the exact issue you have with this interface for
>>>>> Intel to support
>>>>> your own GPU virtualization?
>>>>
>>>> Intel's vGPU can work with this framework. We really appreciate your
>>>> / nvidia's
>>>> contribution.
>>>
>>> Then, I don't think we should embargo Paolo's patch.
>>
>> This patchset is specific for the framework design, i.e, mapping memory when
>> fault happens rather than mmap(), and this design is exact what we are
>> discussing for nearly two days.
>
> I disagree, this patch fixes a bug because what Neo is doing is legal.
> It may not be the design that will be committed, but the bug they found
> in KVM is real.
>

I just worried if we really need fault-on-demand for device memory, i.e,
if device memory overcommit is safe enough.

It lacks a graceful way to recover the workload if the resource is really
overloaded. Unlike with normal memory, host kernel and guest kernel can not
do anything except killing the VM under this case. So the VM get crashed
due to device emulation, that is not safe as the device can be accessed in
userspace even with unprivileged user, it is vulnerable in data center.

  reply	other threads:[~2016-07-07  2:42 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-30 13:01 [PATCH 0/2] KVM: MMU: support VMAs that got remap_pfn_range-ed Paolo Bonzini
2016-06-30 13:01 ` [PATCH 1/2] KVM: MMU: prepare to support mapping of VM_IO and VM_PFNMAP frames Paolo Bonzini
2016-06-30 13:01 ` [PATCH 2/2] KVM: MMU: try to fix up page faults before giving up Paolo Bonzini
2016-06-30 21:59 ` [PATCH 0/2] KVM: MMU: support VMAs that got remap_pfn_range-ed Neo Jia
2016-07-04  6:39 ` Xiao Guangrong
2016-07-04  7:03   ` Neo Jia
2016-07-04  7:37     ` Xiao Guangrong
2016-07-04  7:48       ` Paolo Bonzini
2016-07-04  7:59         ` Xiao Guangrong
2016-07-04  8:14           ` Paolo Bonzini
2016-07-04  8:21             ` Xiao Guangrong
2016-07-04  8:48               ` Paolo Bonzini
2016-07-04  7:53       ` Neo Jia
2016-07-04  8:19         ` Xiao Guangrong
2016-07-04  8:41           ` Neo Jia
2016-07-04  8:45             ` Xiao Guangrong
2016-07-04  8:54               ` Xiao Guangrong
2016-07-04  9:16               ` Neo Jia
2016-07-04 10:16                 ` Xiao Guangrong
2016-07-04 15:33                   ` Neo Jia
2016-07-05  1:19                     ` Xiao Guangrong
2016-07-05  1:35                       ` Neo Jia
2016-07-05  4:02                         ` Xiao Guangrong
2016-07-05  5:16                           ` Neo Jia
2016-07-05  6:26                             ` Xiao Guangrong
2016-07-05  7:30                               ` Neo Jia
2016-07-05  9:02                                 ` Xiao Guangrong
2016-07-05 15:07                                   ` Neo Jia
2016-07-06  2:22                                     ` Xiao Guangrong
2016-07-06  4:01                                       ` Neo Jia
2016-07-04  7:38   ` Paolo Bonzini
2016-07-04  7:40     ` Xiao Guangrong
2016-07-05  5:41 ` Neo Jia
2016-07-05 12:18   ` Paolo Bonzini
2016-07-05 14:02     ` Neo Jia
2016-07-06  2:00     ` Xiao Guangrong
2016-07-06  2:18       ` Neo Jia
2016-07-06  2:35         ` Xiao Guangrong
2016-07-06  2:57           ` Neo Jia
2016-07-06  4:02             ` Xiao Guangrong
2016-07-06 11:48               ` Paolo Bonzini
2016-07-07  2:36                 ` Xiao Guangrong [this message]
2016-07-06  6:05       ` Paolo Bonzini
2016-07-06 15:50         ` 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=577DC03C.1000602@linux.intel.com \
    --to=guangrong.xiao@linux.intel.com \
    --cc=aarcange@redhat.com \
    --cc=cjia@nvidia.com \
    --cc=kvm@vger.kernel.org \
    --cc=kwankhede@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@redhat.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).