Re: [PATCH v3 05/10] hvf: arm: Mark CPU as dirty on reset

[Alexander Graf]

On 03.12.20 14:02, Roman Bolshakov wrote:
> On Thu, Dec 03, 2020 at 11:55:17AM +0100, Alexander Graf wrote:
> > On 03.12.20 02:52, Roman Bolshakov wrote:
> > > On Wed, Dec 02, 2020 at 08:04:03PM +0100, Alexander Graf wrote:
> > > > When clearing internal state of a CPU, we should also make sure that HVF
> > > > knows about it and can push the new values down to vcpu state.
> > > I'm sorry if I'm asking something dumb. But isn't
> > > cpu_synchronize_all_post_reset() is supposed to push QEMU state into HVF
> > > (or any other accel) after reset?
> > >
> > > For x86 it used to work:
> > >
> > >     static void do_hvf_cpu_synchronize_post_reset(CPUState *cpu,
> > >                                                   run_on_cpu_data arg)
> > >     {
> > >         hvf_put_registers(cpu);
> > >         cpu->vcpu_dirty = false;
> > >     }
> >
> > Yes, it works because after the reset is done, there is no other register
> > modification happening. With the PSCI emulation code in QEMU, we still do
> > modify CPU state after reset though.
> Maybe I miss something but that doesn't seem correct. Why PSCI reset is
> split from machine reset?

Because with PSCI, you can online/offline individual CPUs, not just the 
full system.


> > Different question though: Why do we need the post_reset() call at all here
> > to push state?
> My understanding that post_reset is akin to a commit of the CPU state
> after all reset actions have been done to QEMU CPU Arch env state. i.e.
> arch/machine reset modifies env state and then the env is pushed to
> accel. cpu->vcpu_dirty is cleared because env is in-sync with vcpu.


I think that's only half the truth. What it semantically means is 
"QEMU's env structure is what holds the current state." Which basically 
translates to cpu->vcpu_dirty = true.

So all of these callbacks could literally just be that, no?


Alex