From: Roman Bolshakov <r.bolshakov@yadro.com>
To: Alexander Graf <agraf@csgraf.de>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Eduardo Habkost <ehabkost@redhat.com>,
Richard Henderson <richard.henderson@linaro.org>,
qemu-devel@nongnu.org, Cameron Esfahani <dirty@apple.com>,
qemu-arm@nongnu.org, Frank Yang <lfy@google.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Peter Collingbourne <pcc@google.com>
Subject: Re: [PATCH v3 05/10] hvf: arm: Mark CPU as dirty on reset
Date: Thu, 3 Dec 2020 16:02:33 +0300 [thread overview]
Message-ID: <20201203130233.GA14685@SPB-NB-133.local> (raw)
In-Reply-To: <55e5dac5-6508-da7f-3f29-05ee225b13da@csgraf.de>
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
next prev parent reply other threads:[~2020-12-03 13:04 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-02 19:03 [PATCH v3 00/10] hvf: Implement Apple Silicon Support Alexander Graf
2020-12-02 19:03 ` [PATCH v3 01/10] hvf: Add hypervisor entitlement to output binaries Alexander Graf
2020-12-02 23:32 ` Roman Bolshakov
2020-12-02 19:04 ` [PATCH v3 02/10] hvf: Move common code out Alexander Graf
2020-12-03 0:20 ` Roman Bolshakov
2020-12-02 19:04 ` [PATCH v3 03/10] hvf: Introduce hvf vcpu struct Alexander Graf
2020-12-03 0:41 ` Roman Bolshakov
2020-12-02 19:04 ` [PATCH v3 04/10] arm: Set PSCI to 0.2 for HVF Alexander Graf
2020-12-03 1:03 ` Roman Bolshakov
2020-12-02 19:04 ` [PATCH v3 05/10] hvf: arm: Mark CPU as dirty on reset Alexander Graf
2020-12-03 1:52 ` Roman Bolshakov
2020-12-03 10:55 ` Alexander Graf
2020-12-03 13:02 ` Roman Bolshakov [this message]
2020-12-03 14:13 ` Alexander Graf
2020-12-02 19:04 ` [PATCH v3 06/10] hvf: Add Apple Silicon support Alexander Graf
2020-12-03 5:21 ` Roman Bolshakov
2020-12-03 14:26 ` Alexander Graf
2020-12-02 19:04 ` [PATCH v3 07/10] arm: Add Hypervisor.framework build target Alexander Graf
2020-12-03 5:25 ` Roman Bolshakov
2020-12-02 19:04 ` [PATCH v3 08/10] arm/hvf: Add a WFI handler Alexander Graf
2020-12-03 10:39 ` Roman Bolshakov
2020-12-03 18:18 ` Peter Collingbourne
2020-12-04 18:15 ` Roman Bolshakov
2020-12-02 19:04 ` [PATCH v3 09/10] hvf: arm: Add support for GICv3 Alexander Graf
2020-12-02 19:04 ` [PATCH v3 10/10] hvf: arm: Implement -cpu host Alexander Graf
2020-12-02 19:27 ` [PATCH v3 00/10] hvf: Implement Apple Silicon Support no-reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201203130233.GA14685@SPB-NB-133.local \
--to=r.bolshakov@yadro.com \
--cc=agraf@csgraf.de \
--cc=dirty@apple.com \
--cc=ehabkost@redhat.com \
--cc=lfy@google.com \
--cc=pbonzini@redhat.com \
--cc=pcc@google.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).