On 04/03/16 11:36, Christoffer Dall wrote:
> On Thu, Mar 03, 2016 at 03:58:08PM +0000, Marc Zyngier wrote:
>> On 02/03/16 23:08, Christoffer Dall wrote:
>>> On Wed, Feb 17, 2016 at 04:40:43PM +0000, Marc Zyngier wrote:
>>>> So far, we're always writing all possible LRs, setting the empty
>>>> ones with a zero value. This is obvious doing a low of work for
>>>
>>> s/low/lot/
>>>
>>>> nothing, and we're better off clearing those we've actually
>>>> dirtied on the exit path (it is very rare to inject more than one
>>>> interrupt at a time anyway).
>>>>
>>>> Signed-off-by: Marc Zyngier <marc.zyng...@arm.com>
>>>> ---
>>>>  arch/arm64/kvm/hyp/vgic-v2-sr.c | 10 +++++-----
>>>>  1 file changed, 5 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/arch/arm64/kvm/hyp/vgic-v2-sr.c 
>>>> b/arch/arm64/kvm/hyp/vgic-v2-sr.c
>>>> index 3dbbc6b..e53f131 100644
>>>> --- a/arch/arm64/kvm/hyp/vgic-v2-sr.c
>>>> +++ b/arch/arm64/kvm/hyp/vgic-v2-sr.c
>>>> @@ -101,6 +101,7 @@ static void __hyp_text save_lrs(struct kvm_vcpu *vcpu, 
>>>> void __iomem *base)
>>>>            }
>>>>  
>>>>            cpu_if->vgic_lr[i] = readl_relaxed(base + GICH_LR0 + (i * 4));
>>>> +          writel_relaxed(0, base + GICH_LR0 + (i * 4));
>>>>    }
>>>>  }
>>>>  
>>>> @@ -158,12 +159,11 @@ void __hyp_text __vgic_v2_restore_state(struct 
>>>> kvm_vcpu *vcpu)
>>>>            writel_relaxed(cpu_if->vgic_hcr, base + GICH_HCR);
>>>>            writel_relaxed(cpu_if->vgic_apr, base + GICH_APR);
>>>>            for (i = 0; i < nr_lr; i++) {
>>>> -                  u32 val = 0;
>>>> -
>>>> -                  if (live_lrs & (1UL << i))
>>>> -                          val = cpu_if->vgic_lr[i];
>>>> +                  if (!(live_lrs & (1UL << i)))
>>>> +                          continue;
>>>
>>> how can we be sure that the LRs are clear when we launch our first VM on
>>> a given physical CPU?  Don't we need to flush the LRs during VGIC init
>>> time?
>>>
>>>>  
>>>> -                  writel_relaxed(val, base + GICH_LR0 + (i * 4));
>>>> +                  writel_relaxed(cpu_if->vgic_lr[i],
>>>> +                                 base + GICH_LR0 + (i * 4));
>>>>            }
>>>>    }
>>>>  
>>>> -- 
>>>> 2.1.4
>>>>
>>>
>>> otherwie LGTM.
>>
>> So how about this, just before this patch (I'll obviously do something 
>> similar for GICv3):
>>
>> From d9a80c4c406450190a68abee302c7d9a0034c62a Mon Sep 17 00:00:00 2001
>> From: Marc Zyngier <marc.zyng...@arm.com>
>> Date: Thu, 3 Mar 2016 15:43:58 +0000
>> Subject: [PATCH] KVM: arm/arm64: vgic-v2: Reset LRs at boot time
>>
>> In order to let make the GICv2 code more lazy in the way it
>> accesses the LRs, it is necessary to start with a clean slate.
> 
> The first sentence need some love I think :)

Erm... yes. -ENOPARSE! ;-)

> 
>>
>> Let's reset the LRs on each CPU when the vgic is probed.
>>
>> Signed-off-by: Marc Zyngier <marc.zyng...@arm.com>
>> ---
>>  virt/kvm/arm/vgic-v2.c | 12 ++++++++++++
>>  1 file changed, 12 insertions(+)
>>
>> diff --git a/virt/kvm/arm/vgic-v2.c b/virt/kvm/arm/vgic-v2.c
>> index ff02f08..67ec334 100644
>> --- a/virt/kvm/arm/vgic-v2.c
>> +++ b/virt/kvm/arm/vgic-v2.c
>> @@ -176,6 +176,15 @@ static const struct vgic_ops vgic_v2_ops = {
>>  
>>  static struct vgic_params vgic_v2_params;
>>  
>> +static void vgic_cpu_init_lrs(void *params)
>> +{
>> +    struct vgic_params *vgic = params;
>> +    int i;
>> +
>> +    for (i = 0; i < vgic->nr_lr; i++)
>> +            writel_relaxed(0, vgic->vctrl_base + GICH_LR0 + (i * 4));
>> +}
>> +
>>  /**
>>   * vgic_v2_probe - probe for a GICv2 compatible interrupt controller in DT
>>   * @node:   pointer to the DT node
>> @@ -257,6 +266,9 @@ int vgic_v2_probe(struct device_node *vgic_node,
>>  
>>      vgic->type = VGIC_V2;
>>      vgic->max_gic_vcpus = VGIC_V2_MAX_CPUS;
>> +
>> +    on_each_cpu(vgic_cpu_init_lrs, vgic, 1);
>> +
>>      *ops = &vgic_v2_ops;
>>      *params = vgic;
>>      goto out;
>>
>>
>> Thanks,
>>
>>      M.
> 
> This looks good to me.  Only concern is that we're now accessing the
> control interface from EL1 for the first time (I think), but that should
> work just fine though.

We already access it for reading GICH_VTR, but that's actually fine, as
the access is actually controlled by the page tables. Not what the
architects had in mind, but hey... ;-)

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

Reply via email to