This is a little too good to be true. Were both runs with the same KVM_NUM_MMU_PAGES?
yes, both had the same elevated KVM_NUM_MMU_PAGES of 2048. The 'trunk' run should have been labeled as: 'cr3 tree with paravirt turned off'. That's not completely 'trunk' but close to it, and all other changes (like elimination of unnecessary TLB flushes) are fairly applied to both.
i also did a run with much less MMU cache pages of 256, and hackbench 1 stayed the same, while hackbench 5 numbers started fluctuating badly (i think that workload if trashing the MMU cache badly).
- u64 *pae_root;hmm. wouldn't it be simpler to have pae_root always point at the current root?
+ u64 *pae_root[KVM_CR3_CACHE_SIZE];
does that guarantee that it's available? I wanted to 'pin' the root itself this way, to make sure that if a guest switches to it via the cache, that it's truly available and a valid root. cr3 addresses are non-virtual so this is the only mechanism available to guarantee that the host-side memory truly contains a root pagetable.
+ vcpu->mmu.pae_root[j][i] = INVALID_PAGE;You keep the page directories pinned here. [...]
+ }
}
vcpu->mmu.root_hpa = INVALID_PAGE;
}
yes.
[...] This can be a problem if a guest frees a page directory, and then starts using it as a regular page. kvm sometimes chooses not to emulate a write to a guest page table, but instead to zap it, which is impossible when the page is freed. You need to either unpin the page when that happens, or add a hypercall to let kvm know when a page directory is freed.
the cache is zapped upon pagefaults anyway, so unpinning ought to be possible. Which one would you prefer?
+#define KVM_API_MAGIC 0x87654321<linux/kvm.h> is the vmm userspace interface. The guest/host interface should probably go somewhere else.
+
yeah. kvm_para.h?