On 01/07/2010 06:52 PM, Joerg Roedel wrote:
On Thu, Jan 07, 2010 at 02:15:44PM +0200, Avi Kivity wrote:
If two conditions apply:
- no bits outside TS and EM differ between the host and guest cr0
- the fpu is active
then we can activate the selective cr0 write intercept and drop the
unconditional cr0 read and write intercept, and allow the guest to run
with the host fpu state. This reduces the heavyweight context switch
when npt is enabled.
- if (npt_enabled) {
- int mmu_reload = 0;
- if ((kvm_read_cr0_bits(vcpu, X86_CR0_PG) ^ svm->vmcb->save.cr0)
- & X86_CR0_PG) {
- svm_set_cr0(vcpu, svm->vmcb->save.cr0);
- mmu_reload = 1;
- }
+ if (!(svm->vmcb->control.intercept_cr_write& INTERCEPT_CR0_MASK))
vcpu->arch.cr0 = svm->vmcb->save.cr0;
+ if (npt_enabled)
vcpu->arch.cr3 = svm->vmcb->save.cr3;
- if (mmu_reload) {
- kvm_mmu_reset_context(vcpu);
- kvm_mmu_load(vcpu);
- }
- }
-
Hmm, I think removing this hack is a seperate issue. Should it be a
sepearte patch which enables cr0 intercept for npt and removes these
lines? It makes this change more clear in the logs.
Enabling cr0 intercept without enabling selective cr0 intercept will be
a massive performance regression, so performance-wise these two are tied
up. But I agree that it would make the patch easier to read, I'll try
to split it up.
--
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
