On 27/02/2017 16:48, Alex Bennée wrote:
> Currently the code does:
>
> static bool default_mttcg_enabled(void)
> {
> QemuOpts *icount_opts = qemu_find_opts_singleton("icount");
> const char *rr = qemu_opt_get(icount_opts, "rr");
>
> if (rr || TCG_OVERSIZED_GUEST) {
> return false;
>
> I suspect I should just fail if any icount options are set.
Yes.
> However
> qemu_find_opts_singleton always returns the structure. How do I test
> for any icount options?
use_icount != 0 if configure_icount has been called already.
>> 2) "-icount auto -accel tcg,thread=single" hangs fairly early, printing
>> this on the serial console. It's okay if it hangs at
>>
>> [Bds]=============End Load Options Dumping=============
>> [Bds]BdsWait ...Zzzzzzzzzzzz...
>> [Bds]BdsWait(3)..Zzzz...
>>
>> (pressing Enter a few times then seems to unhang it), but it now hangs
>> much earlier than that.
>
> Hmm I can see a hang on linux booting like that. It looks like a vCPU
> get stuck in waitio and never schedules the others.
I don't know if it's the same. For OVMF it fails in many different ways
and it complains about unexpected expensions too.
>> Also, x86 "-accel tcg,thread=multi" prints the scary message on memory
>> ordering.
>
> That is expected until x86 is properly tested and we submit the default
> enabling patch for x86 on x86. To be honest we could submit the MO patch
> now to make that warning go away.
Yeah, this is just the message being unnecessarily specific.
Paolo
