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 :)

> 
> 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.

-Christoffer
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Reply via email to