On Thu, 29 Oct 2026 at 14:55, Eric Auger <[email protected]> wrote:
>
> Hi Peter,
>
> On 10/29/26 3:37 PM, Peter Maydell wrote:
> > On Thu, 29 Oct 2026 at 09:23, Eric Auger <[email protected]> wrote:
> >> This allows to report a precise error message if any error occurs.
> >>
> >> Signed-off-by: Eric Auger <[email protected]>
> >
> >
> >> @@ -371,7 +377,8 @@ static void 
> >> kvm_arm_get_host_cpu_features(ARMHostCPUFeatures *ahcf)
> >>          features |= 1ULL << ARM_FEATURE_PMU;
> >>      }
> >>
> >> -    if (!kvm_arm_create_scratch_host_vcpu(fdarray, &init)) {
> >> +    if (!kvm_arm_create_scratch_host_vcpu(fdarray, &init, &local_err)) {
> >> +        error_report_err(local_err);
> >>          return;
> >>      }
> > This isn't supposed to report an error here. The caller of
> > this function is kvm_arm_set_cpu_features_from_host(), which
> > sets cpu->host_cpu_probe_failed for any failures. That is
> But is there anything wrong output an error? Added errors are related to
> - Failed opening /dev/kvm
> - Failed creating the scratch VM
> - Failed creating the scratch VCPU
> - Failed getting the preferred target
> - Failed the init of the scratch vcpu
>
> all of those are practically tagged as errors, aren't they? So does it
> add any spurious msg for something that is supposed to be normal?

We call kvm_arm_set_cpu_features_from_host() from the
"host" cpu type's instance_init, which can happen during QOM
introspection (which does an init/deinit but not a realize).
instance_init isn't allowed to fail, which is why we defer
reporting the "this didn't work" to realize.

> > later checked by arm_cpu_realizefn(), which reports either
> > that you didn't use an accelerator type you should have or else
> > the rather vague "Failed to retrieve host CPU features".
> >
> > If you want to make that more specific, I think you need to save
> > that more specific error information instead of the plain
> > boolean host_cpu_probe_failed, so you have it in arm_cpu_realizefn
> > where you can report it up.
> Maybe I can store the error handle instead?

Yes, that would work; needs a little care about cleanup:
arm_cpu_finalizefn() needs to error_free() the error if and
only if we didn't propagate it to the caller of realize.

-- PMM

Reply via email to