On Tue, 27 Oct 2026 at 12:01, Mohamed Mediouni <[email protected]> wrote: > > In case of PSCI off followed by a PSCI on which > is a scenario that happens notably during kexec, > what happens today is that the state sync does > not happen and the vCPU becomes in an unexpected state. > > Address this via marking the vCPU as dirty during a PSCI power on. > > Signed-off-by: Mohamed Mediouni <[email protected]> > --- > target/arm/hvf/hvf.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/target/arm/hvf/hvf.c b/target/arm/hvf/hvf.c > index e1ddfe14c7..7ce2e38df1 100644 > --- a/target/arm/hvf/hvf.c > +++ b/target/arm/hvf/hvf.c > @@ -1651,6 +1651,14 @@ static bool hvf_handle_psci_call(CPUState *cpu, int > *excp_ret) > context_id = param[3]; > ret = arm_set_cpu_on(mpidr, entry, context_id, > hvf_psci_get_target_el(), target_aarch64); > + > + /* > + * Mark state as dirty for HVF to sync context > + * when the vCPU runs. arm_set_cpu_on() does not > + * do it by itself. > + */ > + arm_get_cpu_by_id(mpidr)->vcpu_dirty = true; > + > break; > case QEMU_PSCI_0_1_FN_CPU_OFF: > case QEMU_PSCI_0_2_FN_CPU_OFF: > -- > 2.54.0 (Apple Git-157)
I do feel like maybe this isn't the best way to do this, but unfortunately I don't have a good enough grasp on all the state sync stuff to be sure. I think that calling cpu_synchronize_post_init() or cpu_synchronize_post_reset() here would be basically equivalent, and maybe one of those is the right thing? Except looking at their implementation they use run_on_cpu() and at this point in this code we hold the BQL, so (as noted in my comment on patch 5) a bit dubious to call here. arm_set_cpu_on_async_work() could safely call one of those sync functions (because it always runs on the right CPU and run_on_cpu definitely doesn't drop the BQL if it's already on the right CPU). And we do do a cpu_reset() in that function, so that does kind of argue for a post_reset sync to happen. But obviously that's code shared with KVM so we'd need to check through the consequences. thanks -- PMM
