Re: #PF & shadow

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

Dong, Eddie wrote:
> 	I am looking into the efficiency of shadow code and get
> interesting sight: Increasing KVM_NUM_MMU_PAGES doesn't help performance
> which is quit stranger, and the #PF is realitively higher than other
> virtualization solution.
> 	If any of you have any sight, please let me know.
> thanks, eddie
>   

I know of the following issues in the mmu; of course there are likely more:

1. eviction is based on a FIFO policy instead of an approximation of an
LRU.
2. the heuristics of when to unshadow a page (kvm_mmu_pre_write) have
not been tuned.  This can have two effects:
     - a page is unshadowed prematurely, causing many shadow faults later on
     - a page is not unshadowed soon enough, causing too many emulations
(a page should be unshadowed if the guest page is no longer a page
table, or if it is batch updated as in fork())
3. when we emulate a write, we zero out the shadow entry, but we could
instead translate the guest pte and install it in the shadow page. 
That's the purpose of kvm_mmu_post_post_write() which is currently
empty.  This could reduce the cost of a guest minor fault from three
vmexits to two (one for the guest fault, one for the pte update).  I
started implementing this but got distracted.
4. not strictly mmu: after an mmio read, we re-enter the guest and get a
vmexit directly.  Instead we should enter the emulator immediately after
an mmio read.  I implemented that
(b0092d187cfa19dfcada3b85d728af5ae27989dc), but backed it out soon after
due to a regression it introduced with nonpae guests.  I'll look into
redoing it.



-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/