From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 0/15] KVM: optimize for MMIO handled Date: Thu, 09 Jun 2011 10:39:07 +0300 Message-ID: <4DF0789B.2050401@redhat.com> References: <4DEE205E.8000601@cn.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , LKML , KVM To: Xiao Guangrong Return-path: In-Reply-To: <4DEE205E.8000601@cn.fujitsu.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 06/07/2011 03:58 PM, Xiao Guangrong wrote: > The idea of this patchset is from Avi: > | We could cache the result of a miss in an spte by using a reserved bit, and > | checking the page fault error code (or seeing if we get an ept violation or > | ept misconfiguration), so if we get repeated mmio on a page, we don't need to > | search the slot list/tree. > | (https://lkml.org/lkml/2011/2/22/221) > > The aim of this patchset is to support fast mmio emulate, it reduce searching > mmio gfn from memslots which is very expensive since we need to walk all slots > for mmio gfn, and the other advantage is: we can reduce guest page table walking > for soft mmu. > > Lockless walk shadow page table is introduced in this patchset, it is the light > way to check the page fault is the real mmio page fault or something is running > out of our mind. > > And, if shadow_notrap_nonpresent_pte is enabled(bypass_guest_pf=1), mmio page > fault and normal page fault is mixed(the reserved is set for all page fault), > it has little regression, if the box can generate lots of mmio access, for > example, the network server, it can disable shadow_notrap_nonpresent_pte and > enable mmio pf, after all, we can enable/disable mmio pf at the runtime. > Okay, this is pretty complicated. And things are already complicated. First, I think we should consider dropping bypass_guest_pf completely, just so we have less things to think about. Second, I don't like two paths for accessing shadow page tables, it makes the code much larger. I'm also not sure RCU is enough protection - we can unlink a page in the middle of a hierarchy, and on i386 this causes an invalid pointer to appear when we fetch the two halves. But I guess, if the cpu can do it, so can we. Maybe we can do something like again: fetch pointer to last level spte using RCU if failed: take lock build spte hierarchy drop lock goto again if sync: if mmio: do mmio return return walk guest table install spte if mmio: do mmio (sync is always false for tdp) -- error compiling committee.c: too many arguments to function