On 21/09/2016 19:29, Emilio G. Cota wrote:
> BTW should we take this chance to RCU'ify the CPU list?
Yeah, CPU_FOREACH should be audited.
> This series
> + safe cpu_list traversals + cmpxchg changes = MTTCG user-mode would
> be in very good shape. (full-system mode still needs work on the TLB
On Mon, Sep 19, 2016 at 14:50:43 +0200, Paolo Bonzini wrote:
> In addition to fixing some of the issues found by Alex, safe work items
> need not run anymore with a mutex taken. Of course, cpu_exec_start/end
> and start_exclusive/end_exclusive are essentially the read and write
> side of a
Hi,
Your series failed automatic build test. Please find the testing commands and
their output below. If you have docker installed, you can probably reproduce it
locally.
Subject: [Qemu-devel] [PATCH v7 00/16] cpu-exec: Safe work in quiescent state
Message-id: 1474289459-15242-1-git-send-email
Hi,
Your series seems to have some coding style problems. See output below for
more information:
Type: series
Subject: [Qemu-devel] [PATCH v7 00/16] cpu-exec: Safe work in quiescent state
Message-id: 1474289459-15242-1-git-send-email-pbonz...@redhat.com
=== TEST SCRIPT BEGIN ===
#!/bin/bash
In addition to fixing some of the issues found by Alex, safe work items
need not run anymore with a mutex taken. Of course, cpu_exec_start/end
and start_exclusive/end_exclusive are essentially the read and write
side of a specialized rwlock, so there is still a lock in disguise looming
to cause
On 14/09/2016 19:16, Richard Henderson wrote:
> On 09/12/2016 04:12 AM, Paolo Bonzini wrote:
>> In addition to fixing some of the issues found by Alex, safe work items
>> need not run anymore with a mutex taken. Of course, cpu_exec_start/end
>> and start_exclusive/end_exclusive are essentially
On 09/12/2016 04:12 AM, Paolo Bonzini wrote:
> In addition to fixing some of the issues found by Alex, safe work items
> need not run anymore with a mutex taken. Of course, cpu_exec_start/end
> and start_exclusive/end_exclusive are essentially the read and write
> side of a specialized rwlock, so
In addition to fixing some of the issues found by Alex, safe work items
need not run anymore with a mutex taken. Of course, cpu_exec_start/end
and start_exclusive/end_exclusive are essentially the read and write
side of a specialized rwlock, so there is still a lock in disguise looming
to cause
