[Top][All Lists]

[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: Alexander Graf
Subject: Re: [PATCH v3 05/10] hvf: arm: Mark CPU as dirty on reset
Date: Thu, 3 Dec 2020 15:13:04 +0100
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:84.0) Gecko/20100101 Thunderbird/84.0

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


reply via email to

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