On Thu, Dec 3, 2009 at 12:29 PM, Paolo Bonzini wrote:
> On 12/02/2009 02:48 PM, Glauber Costa wrote:
>>
>> + if (env == qemu_get_current_env()) {
>
> Will always be false for TCG + iothread. What's wrong with
> qemu_cpu_self(env)? It appears to do the same, and it would also make the
> whole
On 12/02/2009 02:48 PM, Glauber Costa wrote:
+if (env == qemu_get_current_env()) {
Will always be false for TCG + iothread. What's wrong with
qemu_cpu_self(env)? It appears to do the same, and it would also make
the whole thread-local storage stuff redundant.
If there are performance
On 12/03/2009 02:37 PM, Glauber Costa wrote:
"Because it fixes things".
Please elaborate.
gdbstub is called from the i/o thread , and call vcpu ioctls. So it
has to use the on_vcpu
mechanism to guarantee its execution in the right thread.
What I meant is that currently, gdbstub is the o
>
> Keep the name then. The new name is misleading.
ok.
Totally synchronous,
and guarantees that a given function will be executed at the specified
vcpu.
This patch also convert usage within the breakpoints system
+void qemu_queue_work(CPUState *env, void (*fun
On 12/03/2009 02:33 PM, Glauber Costa wrote:
On Thu, Dec 3, 2009 at 10:20 AM, Avi Kivity wrote:
On 12/02/2009 03:48 PM, Glauber Costa wrote:
This function is similar to qemu-kvm's on_vcpu mechanism.
Is similar? You're replacing on_vcpu().
Yeah, it began similar, now
On Thu, Dec 3, 2009 at 10:20 AM, Avi Kivity wrote:
> On 12/02/2009 03:48 PM, Glauber Costa wrote:
>>
>> This function is similar to qemu-kvm's on_vcpu mechanism.
>
> Is similar? You're replacing on_vcpu().
Yeah, it began similar, now it is pretty much the same thing, but
using qemu-specific
data
On 12/02/2009 03:48 PM, Glauber Costa wrote:
This function is similar to qemu-kvm's on_vcpu mechanism.
Is similar? You're replacing on_vcpu().
Totally synchronous,
and guarantees that a given function will be executed at the specified vcpu.
This patch also convert usage within the breakpoin
