On Fri, Jun 29, 2018 at 11:39:10AM +0100, Daniel P. Berrangé wrote: > On Fri, Jun 29, 2018 at 12:35:09PM +0200, Paolo Bonzini wrote: > > On 29/06/2018 12:29, Greg Kurz wrote: > > > It is unsafe to rely on *_enabled() helpers before the accelerator has > > > been initialized, ie, accel_init_machine() has succeeded, because they > > > always return false. But it is still possible to end up calling them > > > indirectly by inadvertance, and cause QEMU to misbehave. > > > > > > This patch causes QEMU to abort if we try to check for an accelerator > > > before it has been set up. This will help to catch bugs earlier. > > > > > > Signed-off-by: Greg Kurz <gr...@kaod.org> > > > Reviewed-by: David Gibson <da...@gibson.dropbear.id.au> > > > --- > > > > > > This patch was motivated by an regression we're currently fixing in > > > spapr because of an early use of kvm_enabled(). David suggested to > > > post this patch separately: > > > > > > https://lists.nongnu.org/archive/html/qemu-ppc/2018-06/msg01136.html > > > > > > v2: - dropped change in qom/cpu.c (useless header inclusion) > > > - only #include "sysemu/kvm.h" if we actually need it > > > - added David's R-b from v1 because changes in v2 are minor > > > > This adds a function call on possibly hot paths. Can you make it inline? > > > > Also asserting current_machine != NULL is not necessary, since you're > > immediately dereferencing it. > > Is there a practical way to simply initialize the accelerators earlier > in startup sequence, so we just remove or at least reduce, the liklihood > of accessing it too early ?
We can reduce it, but not eliminate it: it would still be possible to use the *_enabled() macros too early, before we parse all command-line options (on QOM class_init, for example). -- Eduardo
