qemu-devel
[Top][All Lists]
Advanced

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

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


From: Roman Bolshakov
Subject: Re: [PATCH v3 05/10] hvf: arm: Mark CPU as dirty on reset
Date: Thu, 3 Dec 2020 16:02:33 +0300

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?

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

> We would just push it on the next run anyways, right?

That's correct (at least for x86 HVF).

> So if we don't set vcpu_dirty to false then, we wouldn't need this
> patch here I think.
>

That's right but the same post-reset approach is used for all accels,
including KVM. But I haven't found this for TCG.

Regards,
Roman



reply via email to

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