qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v7 03/12] target/arm: Swap PMU values before/aft


From: Aaron Lindsay
Subject: Re: [Qemu-devel] [PATCH v7 03/12] target/arm: Swap PMU values before/after migrations
Date: Fri, 16 Nov 2018 16:09:18 +0000

On Nov 16 14:53, Peter Maydell wrote:
> On 5 November 2018 at 18:51, Aaron Lindsay <address@hidden> wrote:
> > Because of the PMU's design, many register accesses have side effects
> > which are inter-related, meaning that the normal method of saving CP
> > registers can result in inconsistent state. These side-effects are
> > largely handled in pmu_op_start/finish functions which can be called
> > before and after the state is saved/restored. By doing this and adding
> > raw read/write functions for the affected registers, we avoid
> > migration-related inconsistencies.
> >
> > Signed-off-by: Aaron Lindsay <address@hidden>
> 
> > --- a/target/arm/machine.c
> > +++ b/target/arm/machine.c
> > @@ -604,6 +604,8 @@ static int cpu_pre_save(void *opaque)
> >  {
> >      ARMCPU *cpu = opaque;
> >
> > +    pmu_op_start(&cpu->env);
> > +
> >      if (kvm_enabled()) {
> >          if (!write_kvmstate_to_list(cpu)) {
> >              /* This should never fail */
> > @@ -625,6 +627,20 @@ static int cpu_pre_save(void *opaque)
> >      return 0;
> >  }
> >
> > +static int cpu_post_save(void *opaque)
> > +{
> > +    ARMCPU *cpu = opaque;
> > +    pmu_op_finish(&cpu->env);
> > +    return 0;
> > +}
> > +
> > +static int cpu_pre_load(void *opaque)
> > +{
> > +    ARMCPU *cpu = opaque;
> > +    pmu_op_start(&cpu->env);
> > +    return 0;
> > +}
> > +
> >  static int cpu_post_load(void *opaque, int version_id)
> >  {
> >      ARMCPU *cpu = opaque;
> > @@ -672,6 +688,8 @@ static int cpu_post_load(void *opaque, int version_id)
> >      hw_breakpoint_update_all(cpu);
> >      hw_watchpoint_update_all(cpu);
> >
> > +    pmu_op_finish(&cpu->env);
> > +
> >      return 0;
> >  }
> 
> This will end up calling pmu_op_start() and pmu_op_finish()
> even if the guest is running KVM and we're not using the
> TCG code. Is that what you intended?

The counters are still stored in their 'difference' format for KVM, so I
think this still makes sense. Or is there something I'm missing about
how this will interact with KVM? I'm much more familiar with TCG.

-Aaron



reply via email to

[Prev in Thread] Current Thread [Next in Thread]