Re: [PATCH 3/4] Nested SVM: Implement INVLPGA v2

From: Alexander Graf <agraf@suse.de>
To: Avi Kivity <avi@redhat.com>
Cc: kvm@vger.kernel.org, joerg.roedel@amd.com,
	Marcelo Tosatti <mtosatti@redhat.com>
Subject: Re: [PATCH 3/4] Nested SVM: Implement INVLPGA v2
Date: Tue, 19 May 2009 15:10:59 +0200	[thread overview]
Message-ID: <1818B7EE-E513-4DE3-A77A-EC65186E0044@suse.de> (raw)
In-Reply-To: <4A12AD0C.9030402@redhat.com>

On 19.05.2009, at 14:58, 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.

Right, the only situation I can imagine this isn't fulfilled is when  
INVLPGA isn't trapped in the 1st level guest, but issued in the 2nd  
level one. That should be rather rare though ;-).

Alex