On Thu, May 04, 2017 at 09:11:50 +0200, Markus Armbruster wrote:
> Thomas Huth <th...@redhat.com> writes:
(snip)
> > STEXI
> > @item -accel @var{name}[,prop=@var{value}[,...]]
> > @findex -accel
> > This is used to enable an accelerator. Depending on the target
> > architecture,
> > -kvm, xen, or tcg can be available. By default, tcg is used. If there is
> > more
> > -than one accelerator specified, the next one is used if the previous one
> > fails
> > -to initialize.
> > +kvm, xen, hax or tcg can be available. By default, tcg is used. If there is
> > +more than one accelerator specified, the next one is used if the previous
> > one
> > +fails to initialize.
> > @table @option
> > @item thread=single|multi
> > Controls number of TCG threads. When the TCG is multi-threaded there will
> > be one
> > diff --git a/vl.c b/vl.c
> > index f46e070..0a1b931 100644
> > --- a/vl.c
> > +++ b/vl.c
> > @@ -3725,26 +3725,21 @@ int main(int argc, char **argv, char **envp)
> > qdev_prop_register_global(&kvm_pit_lost_tick_policy);
> > break;
> > }
> > - case QEMU_OPTION_accel:
> > + case QEMU_OPTION_accel: {
> > + QemuOpts *accel_opts;
>
> Doesn't this shadow the @accel_opts declared in main()'s outermost
> scope?
Yes, it does :( Unfortunately Markus' review slipped through the
cracks and this patch ended up upstream (bde4d9205). It causes
a regression that breaks qemu_tcg_configure(accel_opts)
since now accel_opts is always NULL. That is, in `-accel [..],thread=foo'
foo is ignored.
Emilio
