On Thu, Jun 23, 2022 at 02:04:03PM +0100, Peter Maydell wrote: > On Fri, 17 Jun 2022 at 15:57, Peter Xu <pet...@redhat.com> wrote: > > > > This version of run_on_cpu() allows to take an Error** to detect errors. > > > > Signed-off-by: Peter Xu <pet...@redhat.com> > > --- > > cpus-common.c | 27 +++++++++++++++++++++++++++ > > include/hw/core/cpu.h | 26 ++++++++++++++++++++++++++ > > softmmu/cpus.c | 6 ++++++ > > 3 files changed, 59 insertions(+) > > > +/** > > + * run_on_cpu2: > > + * @cpu: The vCPU to run on. > > + * @func: The function to be executed. > > + * @data: Data to pass to the function. > > + * @errp: The Error** pointer to be passed into @func2. > > + * > > + * Schedules the function @func2 for execution on the vCPU @cpu, capture > > + * any error and put it into *@errp when provided. > > + */ > > +void run_on_cpu2(CPUState *cpu, run_on_cpu_func2 func2, run_on_cpu_data > > data, > > + Error **errp); > > Can you give this a more descriptive name, please,
Ack on the rename, though do you have a suggestion? I did thought about things like run_on_cpu_with_error_captured but that's awfully long.. The use of "suffix 2" seem to be an option in this case and there're users of it even on published KVM interfaces (to name some, KVM_[SET|GET]_PIT2, KVM_[SET|GET]_CPUID2, KVM_[SET|GET]_SREGS2, KVM_GET_XSAVE2..), while this is qemu helper so we can even rename when we want. > unless the plan is to convert all the users of the existing run_on_cpu() > and then rename this function to that ? No plan for that, since I don't see a strong need and maybe many callers do not care about retval. What I plan to do is to fix the immediate migration issue only so we at least don't hit hard-to-debug bugs even when migration completed succeeded (it seems) on QEMU level. That's also why I used a separate helper just to keep the rest untouched. We could move to the new one in other codes when proper, but that's not part of the goal of this series. Thanks, -- Peter Xu
