diff mbox

[v13,00/24] MTTCG Base enabling patches with ARM enablement

Message ID CAJhHMCAwFVfW1u7VnCE2WVDtueD1+BJhq9EpSjOTGO85Q3fytw@mail.gmail.com (mailing list archive)
State New, archived
Headers show

Commit Message

Pranith Kumar Feb. 23, 2017, 1:14 a.m. UTC
On Wed, Feb 22, 2017 at 4:02 PM, Alex Bennée <alex.bennee@linaro.org> wrote:
>
> Alex Bennée <alex.bennee@linaro.org> writes:
>
>> no-reply@patchew.org writes:
>>
>>> Hi,
>>>
>>> This series failed build test on s390x host. Please find the details
>>> below.
>
> It also failed on x86-on-x86 MTTCG as well as other tests:
>
>>> ERROR:/var/tmp/patchew-tester-tmp-_186415r/src/cpus.c:1554:qemu_mutex_lock_iothread: assertion failed: (!qemu_mutex_iothread_locked())
>>> GTester: last random seed: R02Sf1ce767b432f1559eaf8cc0c5a31eb02
>>
>> Well I've seen this before if the IRQ chain doesn't do locking properly
>> but I'm at a loss why this breaks on an s390 host as the code is common.
>>
>> Does anyone have a spare s390 that I can test on?
>
> Look like I'll have to roll this in:
>
>   https://github.com/stsquad/qemu/commit/c6f4245ffd9df8ffcd2d4d655c322189c19a6c1a
>

I am able to successfully boot my test images using this patch (they
fail without it). Another approach might be to reset the lock in the
outer loop:



I think either patch is fine.

Thanks,

Comments

Alex Bennée Feb. 23, 2017, 8:19 a.m. UTC | #1
Pranith Kumar <bobby.prani@gmail.com> writes:

> On Wed, Feb 22, 2017 at 4:02 PM, Alex Bennée <alex.bennee@linaro.org> wrote:
>>
>> Alex Bennée <alex.bennee@linaro.org> writes:
>>
>>> no-reply@patchew.org writes:
>>>
>>>> Hi,
>>>>
>>>> This series failed build test on s390x host. Please find the details
>>>> below.
>>
>> It also failed on x86-on-x86 MTTCG as well as other tests:
>>
>>>> ERROR:/var/tmp/patchew-tester-tmp-_186415r/src/cpus.c:1554:qemu_mutex_lock_iothread: assertion failed: (!qemu_mutex_iothread_locked())
>>>> GTester: last random seed: R02Sf1ce767b432f1559eaf8cc0c5a31eb02
>>>
>>> Well I've seen this before if the IRQ chain doesn't do locking properly
>>> but I'm at a loss why this breaks on an s390 host as the code is common.
>>>
>>> Does anyone have a spare s390 that I can test on?
>>
>> Look like I'll have to roll this in:
>>
>>   https://github.com/stsquad/qemu/commit/c6f4245ffd9df8ffcd2d4d655c322189c19a6c1a
>>
>
> I am able to successfully boot my test images using this patch (they
> fail without it). Another approach might be to reset the lock in the
> outer loop:
>
> diff --git a/cpu-exec.c b/cpu-exec.c
> index f3c78a9..8327050 100644
> --- a/cpu-exec.c
> +++ b/cpu-exec.c
> @@ -684,6 +684,9 @@ int cpu_exec(CPUState *cpu)
>                 if the guest is in advance */
>              align_clocks(&sc, cpu);
>          }
> +        if (qemu_mutex_iothread_locked()) {
> +          qemu_mutex_unlock_iothread();
> +        }

The only aesthetic objection I have is not aligning the unlocks with
where the lock are taken. That said my patch is fairly ugly in that
regard ;-)

>      }
>
>      cc->cpu_exec_exit(cpu);
>
>
> I think either patch is fine.




--
Alex Bennée
diff mbox

Patch

diff --git a/cpu-exec.c b/cpu-exec.c
index f3c78a9..8327050 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -684,6 +684,9 @@  int cpu_exec(CPUState *cpu)
                if the guest is in advance */
             align_clocks(&sc, cpu);
         }
+        if (qemu_mutex_iothread_locked()) {
+          qemu_mutex_unlock_iothread();
+        }
     }

     cc->cpu_exec_exit(cpu);