[PATCH 1/2] KVM: arm/arm64: vgic-v3: De-optimize VMCR save/restore when emulating a GICv2

Marc Zyngier marc.zyngier at arm.com
Wed Apr 19 06:31:57 EDT 2017


On 19/04/17 11:08, Christoffer Dall wrote:
> On Mon, Apr 10, 2017 at 10:19:43AM +0100, Marc Zyngier wrote:
>> When emulating a GICv2-on-GICv3, special care must be taken to only
>> save/restore VMCR_EL2 when ICC_SRE_EL1.SRE is cleared. Otherwise,
>> all Group-0 interrupts end-up being delivered as FIQ, which is
>> probably not what the guest expects, as demonstrated here with
>> an unhappy EFI:
>>
>> 	FIQ Exception at 0x000000013BD21CC4
>>
>> This means that we cannot perform the load/put trick when dealing
>> with VMCR_EL2 (because the host has SRE set), and we have to deal
>> with it in the world-switch.
>>
>> Fortunately, this is not the most common case (modern guests should
>> be able to deal with GICv3 directly), and the performance is not worse
>> than what it was before the VMCR optimization.
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  virt/kvm/arm/hyp/vgic-v3-sr.c |  8 ++++++--
>>  virt/kvm/arm/vgic/vgic.c      | 26 ++++++++++++++++++++------
>>  2 files changed, 26 insertions(+), 8 deletions(-)
>>
>> diff --git a/virt/kvm/arm/hyp/vgic-v3-sr.c b/virt/kvm/arm/hyp/vgic-v3-sr.c
>> index 3d0b1ddb6929..91922c1eddc8 100644
>> --- a/virt/kvm/arm/hyp/vgic-v3-sr.c
>> +++ b/virt/kvm/arm/hyp/vgic-v3-sr.c
>> @@ -128,8 +128,10 @@ void __hyp_text __vgic_v3_save_state(struct kvm_vcpu *vcpu)
>>  	 * Make sure stores to the GIC via the memory mapped interface
>>  	 * are now visible to the system register interface.
>>  	 */
>> -	if (!cpu_if->vgic_sre)
>> +	if (!cpu_if->vgic_sre) {
>>  		dsb(st);
>> +		cpu_if->vgic_vmcr = read_gicreg(ICH_VMCR_EL2);
>> +	}
>>  
>>  	if (used_lrs) {
>>  		int i;
>> @@ -205,11 +207,13 @@ void __hyp_text __vgic_v3_restore_state(struct kvm_vcpu *vcpu)
>>  	 * delivered as a FIQ to the guest, with potentially fatal
>>  	 * consequences. So we must make sure that ICC_SRE_EL1 has
>>  	 * been actually programmed with the value we want before
>> -	 * starting to mess with the rest of the GIC.
>> +	 * starting to mess with the rest of the GIC, and VMCR_EL2 in
>> +	 * particular.
>>  	 */
>>  	if (!cpu_if->vgic_sre) {
>>  		write_gicreg(0, ICC_SRE_EL1);
>>  		isb();
>> +		write_gicreg(cpu_if->vgic_vmcr, ICH_VMCR_EL2);
>>  	}
>>  
>>  	val = read_gicreg(ICH_VTR_EL2);
>> diff --git a/virt/kvm/arm/vgic/vgic.c b/virt/kvm/arm/vgic/vgic.c
>> index 3d0979c30721..32205f2ba6ff 100644
>> --- a/virt/kvm/arm/vgic/vgic.c
>> +++ b/virt/kvm/arm/vgic/vgic.c
>> @@ -667,10 +667,20 @@ void kvm_vgic_load(struct kvm_vcpu *vcpu)
>>  	if (unlikely(!vgic_initialized(vcpu->kvm)))
>>  		return;
>>  
>> -	if (kvm_vgic_global_state.type == VGIC_V2)
>> +	if (kvm_vgic_global_state.type == VGIC_V2) {
>>  		vgic_v2_load(vcpu);
>> -	else
>> -		vgic_v3_load(vcpu);
>> +	} else {
>> +		struct vgic_v3_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v3;
>> +
>> +		/*
>> +		 * If dealing with a GICv2 emulation on GICv3,
>> +		 * VMCR_EL2.VFIQen is dependent on ICC_SRE_EL1.SRE,
>> +		 * and we have to perform the VMCR_EL2 save/restore in
>> +		 * the world switch.
>> +		 */
>> +		if (likely(cpu_if->vgic_sre))
>> +			vgic_v3_load(vcpu);
> 
> I wonder if this conditional should really be inside vgic_v3_load
> instead?

That's a good point. It will keep the wart out of the main vgic code and
make it an "implementation detail".

> 
>> +	}
>>  }
>>  
>>  void kvm_vgic_put(struct kvm_vcpu *vcpu)
>> @@ -678,10 +688,14 @@ void kvm_vgic_put(struct kvm_vcpu *vcpu)
>>  	if (unlikely(!vgic_initialized(vcpu->kvm)))
>>  		return;
>>  
>> -	if (kvm_vgic_global_state.type == VGIC_V2)
>> +	if (kvm_vgic_global_state.type == VGIC_V2) {
>>  		vgic_v2_put(vcpu);
>> -	else
>> -		vgic_v3_put(vcpu);
>> +	} else {
>> +		struct vgic_v3_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v3;
>> +
>> +		if (likely(cpu_if->vgic_sre))
>> +			vgic_v3_put(vcpu);
> 
> And same here?
> 
>> +	}
>>  }
>>  
>>  int kvm_vgic_vcpu_pending_irq(struct kvm_vcpu *vcpu)
>> -- 
>> 2.11.0
>>
> 
> Otherwise looks good.

Thanks. I'll respin this patch shortly.

	M.
-- 
Jazz is not dead. It just smells funny...



More information about the linux-arm-kernel mailing list