On 11/04/2011 10:27 AM, Fabien Chouteau wrote:
It's a huge assumption though, and I don't think it should be assumed anymore.
What can we do to improve that?
Remove the affinity change and see what breaks. :)
> With iothread the architecture of the QEMU main loop is anyway completely
diff
On 03/11/2011 12:50, Paolo Bonzini wrote:
> On 11/03/2011 11:29 AM, Avi Kivity wrote:
>> > It would ensure that two mutators wouldn't run concurrently. In some
>> > sense, signal-safe code could then be considered thread-safe too.
>>
>> How so? The scheduler can switch between the two threads o
On 11/03/2011 11:29 AM, Avi Kivity wrote:
> It would ensure that two mutators wouldn't run concurrently. In some
> sense, signal-safe code could then be considered thread-safe too.
How so? The scheduler can switch between the two threads on every
instruction.
In general signal-safe is more
On 11/03/2011 12:10 PM, Paolo Bonzini wrote:
>
>> Also, why running all the threads on the same CPU would
>> make the code thread-safe?
>
> It would ensure that two mutators wouldn't run concurrently. In some
> sense, signal-safe code could then be considered thread-safe too.
>
How so? The sched
On 11/03/2011 10:54 AM, Fabien Chouteau wrote:
>> The unchaining is neither signal-safe nor thread-safe...
>
> Yeah, but there's nothing Windows-specific in that.
That's very important, I don't see why it is different between Linux and
Windows here.
Yep, perhaps for timers it was the case a
On 02/11/2011 20:57, Peter Maydell wrote:
> On 2 November 2011 19:52, Paolo Bonzini wrote:
>> (Also, the unchaining is safer, or even completely safe in system mode than
>> it is with pthreads).
>
> I don't think it's completely safe, you're just a bit less likely
> to get bitten than if you're t
On 02/11/2011 20:52, Paolo Bonzini wrote:
> On 11/02/2011 07:01 PM, Peter Maydell wrote:
>> On 2 November 2011 17:45, Paolo Bonzini wrote:
>>> The rest is always done in the iothread. The iothread will then
>>> suspend/resume the VCPU thread around the unchaining, so what matters is (in
>>> Unix
On 2 November 2011 19:52, Paolo Bonzini wrote:
> (Also, the unchaining is safer, or even completely safe in system mode than
> it is with pthreads).
I don't think it's completely safe, you're just a bit less likely
to get bitten than if you're trying to run a linux-user-mode
multithreaded guest b
On 11/02/2011 07:01 PM, Peter Maydell wrote:
On 2 November 2011 17:45, Paolo Bonzini wrote:
The rest is always done in the iothread. The iothread will then
suspend/resume the VCPU thread around the unchaining, so what matters is (in
Unix parlance) signal-safety of the unchaining, not thread-sa
On 2 November 2011 17:45, Paolo Bonzini wrote:
> The rest is always done in the iothread. The iothread will then
> suspend/resume the VCPU thread around the unchaining, so what matters is (in
> Unix parlance) signal-safety of the unchaining, not thread-safety.
The unchaining is neither signal-sa
On Wed, 2 Nov 2011, Paolo Bonzini wrote:
> On 11/02/2011 06:16 PM, malc wrote:
> > (mm)Timers have a possibility of running on a thread of their own which
> > might be schedulled on the CPU different from the thread that runs
> > emulated code, unchaining TBs and can (and will) fail in this case.
On 11/02/2011 06:16 PM, malc wrote:
(mm)Timers have a possibility of running on a thread of their own which
might be schedulled on the CPU different from the thread that runs
emulated code, unchaining TBs and can (and will) fail in this case.
This should not be a problem with dynticks+iothread
On Wed, 2 Nov 2011, Fabien Chouteau wrote:
> On 02/11/2011 17:25, Paolo Bonzini wrote:
> > On 11/02/2011 04:38 PM, Fabien Chouteau wrote:
> >> Hello fellow Qemu aficionados,
> >>
> >> On Windows, Qemu sets the affinity mask in order to run all thread on
> >> CPU0, with this comment in the code (os
On 02/11/2011 17:25, Paolo Bonzini wrote:
> On 11/02/2011 04:38 PM, Fabien Chouteau wrote:
>> Hello fellow Qemu aficionados,
>>
>> On Windows, Qemu sets the affinity mask in order to run all thread on
>> CPU0, with this comment in the code (os-win32.c:182):
>>
>> /* Note: cpu_interrupt() is cu
On 11/02/2011 04:38 PM, Fabien Chouteau wrote:
Hello fellow Qemu aficionados,
On Windows, Qemu sets the affinity mask in order to run all thread on
CPU0, with this comment in the code (os-win32.c:182):
/* Note: cpu_interrupt() is currently not SMP safe, so we force
QEMU to run on a
Hello fellow Qemu aficionados,
On Windows, Qemu sets the affinity mask in order to run all thread on
CPU0, with this comment in the code (os-win32.c:182):
/* Note: cpu_interrupt() is currently not SMP safe, so we force
QEMU to run on a single CPU */
This was added by Fabrice Bellard i
16 matches
Mail list logo
