All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jike Song <jike.song@intel.com>
To: Xiao Guangrong <guangrong.xiao@linux.intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	gleb@kernel.org, mtosatti@redhat.com, kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org, kai.huang@linux.intel.com,
	Andrea Arcangeli <aarcange@redhat.com>,
	"Tian, Kevin" <kevin.tian@intel.com>
Subject: Re: [PATCH v3 00/11] KVM: x86: track guest page access
Date: Tue, 23 Feb 2016 11:02:25 +0800	[thread overview]
Message-ID: <56CBCBC1.8050902@intel.com> (raw)
In-Reply-To: <56CADD6D.2040603@linux.intel.com>

+Kevin

On 02/22/2016 06:05 PM, Xiao Guangrong wrote:
> 
> On 02/19/2016 08:00 PM, Paolo Bonzini wrote:
>>
>> I still have a doubt: how are you going to handle invalidation of GPU
>> shadow page tables if a device (emulated in QEMU or even vhost) does DMA
>> to the PPGTT?
> 
> I think Jike is the better one to answer this question, Jike, could you
> please clarify it? :)
> 

Sure :)

Actually in guest PPGTT is manipulated by CPU rather than GPU. The
PPGTT page table itself are plain memory, composed & modified by the
GPU driver, i.e. by CPU in Non-Root mode.

Given that, we write-protected guest PPGTT, when VM writes PPGTT, EPT
violation rather than DMA fault happens.

>> Generally, this was the reason to keep stuff out of KVM
>> and instead hook into the kernel mm subsystem (as with userfaultfd).
> 
> We considered it carefully but this way can not satisfy KVMGT's requirements.
> The reasons i explained in the old thread (https://lkml.org/lkml/2015/12/1/516)
> are:
> 
> "For the performance, shadow GPU is performance critical and requires
> frequently being switched, it is not good to handle it in userspace. And
> windows guest has many GPU tables and updates it frequently, that means,
> we need to write protect huge number of pages which are single page based,
> I am afraid userfaultfd can not handle this case efficiently.
> 
> For the functionality, userfaultfd can not fill the need of shadow page
> because:
> - the page is keeping readonly, userfaultfd can not fix the fault and let
>     the vcpu progress (write access causes writeable gup).
> 
> - the access need to be emulated, however, userfaultfd/kernel does not have
>     the ability to emulate the access as the access is trigged by guest, the
>     instruction info is stored in VMCS so that only KVM can emulate it.
> 
> - shadow page needs to be notified after the emulation is finished as it
>     should know the new data written to the page to update its page hierarchy.
>     (some hardwares lack the 'retry' ability so the shadow page table need to
>      reflect the table in guest at any time). "
> 
> Any idea?
> 

WARNING: multiple messages have this Message-ID (diff)
From: Jike Song <jike.song@intel.com>
To: Xiao Guangrong <guangrong.xiao@linux.intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	gleb@kernel.org, mtosatti@redhat.com, kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org, kai.huang@linux.intel.com,
	Andrea Arcangeli <aarcange@redhat.com>,
	"Tian, Kevin" <kevin.tian@intel.com>
Subject: Re: [PATCH v3 00/11] KVM: x86: track guest page access
Date: Tue, 23 Feb 2016 11:02:25 +0800	[thread overview]
Message-ID: <56CBCBC1.8050902@intel.com> (raw)
In-Reply-To: <56CADD6D.2040603@linux.intel.com>

+Kevin

On 02/22/2016 06:05 PM, Xiao Guangrong wrote:
> 
> On 02/19/2016 08:00 PM, Paolo Bonzini wrote:
>>
>> I still have a doubt: how are you going to handle invalidation of GPU
>> shadow page tables if a device (emulated in QEMU or even vhost) does DMA
>> to the PPGTT?
> 
> I think Jike is the better one to answer this question, Jike, could you
> please clarify it? :)
> 

Sure :)

Actually in guest PPGTT is manipulated by CPU rather than GPU. The
PPGTT page table itself are plain memory, composed & modified by the
GPU driver, i.e. by CPU in Non-Root mode.

Given that, we write-protected guest PPGTT, when VM writes PPGTT, EPT
violation rather than DMA fault happens.

>> Generally, this was the reason to keep stuff out of KVM
>> and instead hook into the kernel mm subsystem (as with userfaultfd).
> 
> We considered it carefully but this way can not satisfy KVMGT's requirements.
> The reasons i explained in the old thread (https://lkml.org/lkml/2015/12/1/516)
> are:
> 
> "For the performance, shadow GPU is performance critical and requires
> frequently being switched, it is not good to handle it in userspace. And
> windows guest has many GPU tables and updates it frequently, that means,
> we need to write protect huge number of pages which are single page based,
> I am afraid userfaultfd can not handle this case efficiently.
> 
> For the functionality, userfaultfd can not fill the need of shadow page
> because:
> - the page is keeping readonly, userfaultfd can not fix the fault and let
>     the vcpu progress (write access causes writeable gup).
> 
> - the access need to be emulated, however, userfaultfd/kernel does not have
>     the ability to emulate the access as the access is trigged by guest, the
>     instruction info is stored in VMCS so that only KVM can emulate it.
> 
> - shadow page needs to be notified after the emulation is finished as it
>     should know the new data written to the page to update its page hierarchy.
>     (some hardwares lack the 'retry' ability so the shadow page table need to
>      reflect the table in guest at any time). "
> 
> Any idea?
> 

--
Thanks,
Jike

  reply	other threads:[~2016-02-23  3:02 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-14 11:31 [PATCH v3 00/11] KVM: x86: track guest page access Xiao Guangrong
2016-02-14 11:31 ` [PATCH v3 01/11] KVM: MMU: rename has_wrprotected_page to mmu_gfn_lpage_is_disallowed Xiao Guangrong
2016-02-19 11:08   ` Paolo Bonzini
2016-02-14 11:31 ` [PATCH v3 02/11] KVM: MMU: introduce kvm_mmu_gfn_{allow,disallow}_lpage Xiao Guangrong
2016-02-19 11:09   ` Paolo Bonzini
2016-02-14 11:31 ` [PATCH v3 03/11] KVM: MMU: introduce kvm_mmu_slot_gfn_write_protect Xiao Guangrong
2016-02-19 11:18   ` Paolo Bonzini
2016-02-14 11:31 ` [PATCH v3 04/11] KVM: page track: add the framework of guest page tracking Xiao Guangrong
2016-02-19 11:24   ` Paolo Bonzini
2016-02-23  3:57     ` Xiao Guangrong
2016-02-14 11:31 ` [PATCH v3 05/11] KVM: page track: introduce kvm_page_track_{add,remove}_page Xiao Guangrong
2016-02-19 11:37   ` Paolo Bonzini
2016-02-23  4:18     ` Xiao Guangrong
2016-02-23 14:15       ` Paolo Bonzini
2016-02-19 11:37   ` Paolo Bonzini
2016-02-23  4:18     ` Xiao Guangrong
2016-02-14 11:31 ` [PATCH v3 06/11] KVM: MMU: let page fault handler be aware tracked page Xiao Guangrong
2016-02-19 11:45   ` Paolo Bonzini
2016-02-23  4:19     ` Xiao Guangrong
2016-02-14 11:31 ` [PATCH v3 07/11] KVM: page track: add notifier support Xiao Guangrong
2016-02-19 11:51   ` Paolo Bonzini
2016-02-23  4:34     ` Xiao Guangrong
2016-02-23 14:16       ` Paolo Bonzini
2016-02-14 11:31 ` [PATCH v3 08/11] KVM: MMU: use page track for non-leaf shadow pages Xiao Guangrong
2016-02-14 11:31 ` [PATCH v3 09/11] KVM: MMU: simplify mmu_need_write_protect Xiao Guangrong
2016-02-14 11:31 ` [PATCH v3 10/11] KVM: MMU: clear write-flooding on the fast path of tracked page Xiao Guangrong
2016-02-19 11:55   ` Paolo Bonzini
2016-02-23  4:36     ` Xiao Guangrong
2016-02-14 11:31 ` [PATCH v3 11/11] KVM: MMU: apply page track notifier Xiao Guangrong
2016-02-19 11:56   ` Paolo Bonzini
2016-02-23  4:40     ` Xiao Guangrong
2016-02-23 14:17       ` Paolo Bonzini
2016-02-19 12:00 ` [PATCH v3 00/11] KVM: x86: track guest page access Paolo Bonzini
2016-02-22 10:05   ` Xiao Guangrong
2016-02-23  3:02     ` Jike Song [this message]
2016-02-23  3:02       ` Jike Song
2016-02-23  5:44       ` Tian, Kevin
2016-02-23 12:13         ` Paolo Bonzini
2016-02-23 10:01       ` Paolo Bonzini
2016-02-23 11:50         ` Jike Song

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=56CBCBC1.8050902@intel.com \
    --to=jike.song@intel.com \
    --cc=aarcange@redhat.com \
    --cc=gleb@kernel.org \
    --cc=guangrong.xiao@linux.intel.com \
    --cc=kai.huang@linux.intel.com \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=pbonzini@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 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.