Re: [PATCH v5 09/12] Retry fault before vmentry

[Avi Kivity]

 On 08/24/2010 12:33 PM, Gleb Natapov wrote:
> > > @@ -505,6 +506,37 @@ out_unlock:
> > >   	return 0;
> > >   }
> > >
> > > +static int FNAME(page_fault_other_cr3)(struct kvm_vcpu *vcpu, gpa_t cr3,
> > > +				       gva_t addr, u32 error_code)
> > > +{
> > > +	int r = 0;
> > > +	gpa_t curr_cr3 = vcpu->arch.cr3;
> > > +
> > > +	if (curr_cr3 != cr3) {
> > > +		/*
> > > +		 * We do page fault on behalf of a process that is sleeping
> > > +		 * because of async PF. PV guest takes reference to mm that cr3
> > > +		 * belongs too, so it has to be valid here.
> > > +		 */
> > > +		kvm_set_cr3(vcpu, cr3);
> > > +		if (kvm_mmu_reload(vcpu))
> > > +			goto switch_cr3;
> > > +	}
> > With nested virtualization, we need to switch cr0, cr4, and efer as well...
> On SVM or VMX or both?

Both.  Let's defer this patch since it's an optimization, this is really 
complicated.

> > > +
> > > +	r = FNAME(page_fault)(vcpu, addr, error_code, true);
> > > +
> > > +	if (kvm_check_request(KVM_REQ_MMU_SYNC, vcpu))
> > > +		kvm_mmu_sync_roots(vcpu);
> > Why is this needed?
> http://www.mail-archive.com/kvm@xxxxxxxxxxxxxxx/msg37827.html
>
>   KVM_REQ_MMU_SYNC request generated here must be processed before
>   switching to a different cr3 (otherwise vcpu_enter_guest will process it
>   with the wrong cr3 in place).

Ah, it should be part of the cr3 switch block above.

> > > +
> > > +switch_cr3:
> > > +	if (curr_cr3 != vcpu->arch.cr3) {
> > > +		kvm_set_cr3(vcpu, curr_cr3);
> > > +		kvm_mmu_reload(vcpu);
> > > +	}
> > > +
> > > +	return r;
> > > +}
> > This has the nasty effect of flushing the TLB on AMD.
> What is more expansive reenter the guest and handle one more fault, or
> flash TLB here?

No idea.  Probably the reentry.  On Intel the tlb is flushed anyway.

--
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/