Re: [PATCH v5 13/26] KVM: arm/arm64: GICv4: Propagate affinity changes to the physical ITS

2017-11-08 Thread Marc Zyngier
On 07/11/17 21:01, Auger Eric wrote:
> Hi Marc,
> 
> On 27/10/2017 16:28, Marc Zyngier wrote:
>> When the guest issues an affinity change, we need to tell the physical
>> ITS that we're now targetting a new vcpu.  This is done by extracting
>> the current mapping, updating the target, and reapplying the mapping.
>>
>> Reviewed-by: Christoffer Dall 
>> Signed-off-by: Marc Zyngier 
>> ---
>>  virt/kvm/arm/vgic/vgic-its.c | 16 +++-
>>  1 file changed, 15 insertions(+), 1 deletion(-)
>>
>> diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c
>> index c9b1c0967426..42ffb9084bb7 100644
>> --- a/virt/kvm/arm/vgic/vgic-its.c
>> +++ b/virt/kvm/arm/vgic/vgic-its.c
>> @@ -337,11 +337,25 @@ static int vgic_copy_lpi_list(struct kvm_vcpu *vcpu, 
>> u32 **intid_ptr)
>>  
>>  static int update_affinity(struct vgic_irq *irq, struct kvm_vcpu *vcpu)
>>  {
>> +int ret = 0;
>> +
>>  spin_lock(>irq_lock);
>>  irq->target_vcpu = vcpu;
>>  spin_unlock(>irq_lock);
>>  
>> -return 0;
>> +if (irq->hw) {
>> +struct its_vlpi_map map;
>> +
>> +ret = its_get_vlpi(irq->host_irq, );
>> +if (ret)
>> +return ret;
>> +
>> +map.vpe = >arch.vgic_cpu.vgic_v3.its_vpe;
>> +
>> +ret = its_map_vlpi(irq->host_irq, );
> Do we check somewhere the virtual LPI ID does not exceed the capacity of
> the VPT. I fail to find that in the irq-gic-v3-its.c driver.

The worse case is that we end-up with a VMAPVI that silently fails, and
the guest doesn't gets its interrupts. The real issue here is that we
don't expose the size of the VPT allocation to the guest. I'll see how
to address this.

> Also in case the hw part fails, should we still have the irq->target_cpu
> set to the new value. In other words shouldn't we first do the hw block
> and upon success set the target_vcpu?

Sure. But given that we'll never use target_vcpu for anything either (we
keep the vlpi mapped), I'm not sure what this gets us...

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm


Re: [PATCH v5 13/26] KVM: arm/arm64: GICv4: Propagate affinity changes to the physical ITS

2017-11-07 Thread Auger Eric
Hi Marc,

On 27/10/2017 16:28, Marc Zyngier wrote:
> When the guest issues an affinity change, we need to tell the physical
> ITS that we're now targetting a new vcpu.  This is done by extracting
> the current mapping, updating the target, and reapplying the mapping.
> 
> Reviewed-by: Christoffer Dall 
> Signed-off-by: Marc Zyngier 
> ---
>  virt/kvm/arm/vgic/vgic-its.c | 16 +++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c
> index c9b1c0967426..42ffb9084bb7 100644
> --- a/virt/kvm/arm/vgic/vgic-its.c
> +++ b/virt/kvm/arm/vgic/vgic-its.c
> @@ -337,11 +337,25 @@ static int vgic_copy_lpi_list(struct kvm_vcpu *vcpu, 
> u32 **intid_ptr)
>  
>  static int update_affinity(struct vgic_irq *irq, struct kvm_vcpu *vcpu)
>  {
> + int ret = 0;
> +
>   spin_lock(>irq_lock);
>   irq->target_vcpu = vcpu;
>   spin_unlock(>irq_lock);
>  
> - return 0;
> + if (irq->hw) {
> + struct its_vlpi_map map;
> +
> + ret = its_get_vlpi(irq->host_irq, );
> + if (ret)
> + return ret;
> +
> + map.vpe = >arch.vgic_cpu.vgic_v3.its_vpe;
> +
> + ret = its_map_vlpi(irq->host_irq, );
Do we check somewhere the virtual LPI ID does not exceed the capacity of
the VPT. I fail to find that in the irq-gic-v3-its.c driver.

Also in case the hw part fails, should we still have the irq->target_cpu
set to the new value. In other words shouldn't we first do the hw block
and upon success set the target_vcpu?

Thanks

Eric
> + }
> +
> + return ret;
>  }
>  
>  /*
> 
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm


[PATCH v5 13/26] KVM: arm/arm64: GICv4: Propagate affinity changes to the physical ITS

2017-10-27 Thread Marc Zyngier
When the guest issues an affinity change, we need to tell the physical
ITS that we're now targetting a new vcpu.  This is done by extracting
the current mapping, updating the target, and reapplying the mapping.

Reviewed-by: Christoffer Dall 
Signed-off-by: Marc Zyngier 
---
 virt/kvm/arm/vgic/vgic-its.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c
index c9b1c0967426..42ffb9084bb7 100644
--- a/virt/kvm/arm/vgic/vgic-its.c
+++ b/virt/kvm/arm/vgic/vgic-its.c
@@ -337,11 +337,25 @@ static int vgic_copy_lpi_list(struct kvm_vcpu *vcpu, u32 
**intid_ptr)
 
 static int update_affinity(struct vgic_irq *irq, struct kvm_vcpu *vcpu)
 {
+   int ret = 0;
+
spin_lock(>irq_lock);
irq->target_vcpu = vcpu;
spin_unlock(>irq_lock);
 
-   return 0;
+   if (irq->hw) {
+   struct its_vlpi_map map;
+
+   ret = its_get_vlpi(irq->host_irq, );
+   if (ret)
+   return ret;
+
+   map.vpe = >arch.vgic_cpu.vgic_v3.its_vpe;
+
+   ret = its_map_vlpi(irq->host_irq, );
+   }
+
+   return ret;
 }
 
 /*
-- 
2.11.0

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm