On 12/04/16 14:48, Alex Bennée wrote:
> Sergey Fedorov <serge.f...@gmail.com> writes:
>
>> On 05/04/16 18:32, Alex Bennée wrote:
>>> diff --git a/qemu-options.hx b/qemu-options.hx
>>> index a770086..4eca704 100644
>>> --- a/qemu-options.hx
>>> +++ b/qemu-options.hx
>>> @@ -3224,6 +3224,20 @@ Attach to existing xen domain.
>>> xend will use this when starting QEMU (XEN only).
>>> ETEXI
>>>
>>> +DEF("tcg", HAS_ARG, QEMU_OPTION_tcg, \
>>> + "-tcg [mttcg=on|off] control TCG options\n", QEMU_ARCH_ALL)
>>> +STEXI
>>> +@item -tcg
>>> +@findex -tcg
>>> +@table @option
>>> +@item mttcg=[on|off]
>>> +Control multi-threaded TCG. By default QEMU will enable multi-threaded
>>> +emulation for front/back-end combinations that are known to work. The
>>> +user may enable it against the defaults however odd guest behaviour
>>> +may occur.
>>> +@end table
>>> +ETEXI
>> Maybe we'd better use existing qemu accelerator framework and introduce
>> "-machine accel=mttcg" option?
> My worry would be breaking existing code which assumes kvm | tcg. We
> will want to enable mttcg by default for combos that work without having
> to tweak tooling that already uses the -machine options.
You are right, we'd better make MTTCG as an option for TCG, not as a
separate accelerator.
Kind regards,
Sergey
