On Tue, May 19, 2009 at 03:58:52PM +0300, Avi Kivity wrote:
> Alexander Graf wrote:
>> SVM adds another way to do INVLPG by ASID which Hyper-V makes use of,
>> so let's implement it!
>>
>> For now we just do the same thing invlpg does, as asid switching
>> means we flush the mmu anyways. That might change one day though.
>>
>> v2 makes invlpga do the same as invlpg, not flush the whole mmu
>>
>> +static int invlpga_interception(struct vcpu_svm *svm, struct kvm_run
>> *kvm_run)
>> +{
>> + struct kvm_vcpu *vcpu = &svm->vcpu;
>> + nsvm_printk("INVLPGA\n");
>> +
>> + /* Let's treat INVLPGA the same as INVLPG */
>> + kvm_mmu_invlpg(vcpu, vcpu->arch.regs[VCPU_REGS_RAX]);
>> +
>> + svm->next_rip = kvm_rip_read(&svm->vcpu) + 3;
>> + skip_emulated_instruction(&svm->vcpu);
>> + return 1;
>> +}
>>
>
> I think that for ASID!=0 you can actually do nothing. The guest entry
> is a cr3 switch, so we'll both get a tlb flush and a resync on any
> modified ptes.
>
> For ASID==0 you can do the invlpg thing.
>
> Marcelo?
kvm_mmu_invlpg is cheap, better just invalidate the entry. If hyper-v
uses invlpga to invalidate TLB entries which it has updated pte's in
memory for, and you skip the invalidation now and somehow later use an
unsync spte, you're toast.
--
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
