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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
