* Can we force a KVM VCPU in Guest Mode to Exit to User Mode From User Mode ?
@ 2012-07-26 9:38 Mian M. Hamayun
2012-07-26 10:06 ` Avi Kivity
0 siblings, 1 reply; 6+ messages in thread
From: Mian M. Hamayun @ 2012-07-26 9:38 UTC (permalink / raw)
To: kvm
[-- Attachment #1: Type: text/plain, Size: 3168 bytes --]
Hi Everyone,
I want to know if we can force a VMExit on a KVM VCPU currently in Guest
Mode from the User Mode ?
As an example, I want to execute an IOCTL on a KVM VCPU which is
currently in Guest Mode, say it is waiting to execute some guest
instructions.
As far as I know, the VCPU should not be running for an IOCTL to
complete on it.
To give you a concrete example, please see the following code segments
(taken from qemu-kvm):
void run_on_cpu(CPUArchState *env, void (*func)(void *data), void *data)
{
struct qemu_work_item wi;
if (qemu_cpu_is_self(env)) {
func(data);
return;
}
wi.func = func;
wi.data = data;
if (!env->queued_work_first) {
env->queued_work_first = &wi;
} else {
env->queued_work_last->next = &wi;
}
env->queued_work_last = &wi;
wi.next = NULL;
wi.done = false;
qemu_cpu_kick(env);
while (!wi.done) {
CPUArchState *self_env = cpu_single_env;
qemu_cond_wait(&qemu_work_cond, &qemu_global_mutex);
cpu_single_env = self_env;
}
}
The "run_on_cpu" function in qemu-kvm invokes "qemu_cpu_kick" to
schedule the appropriate VCPU thread and blocks itself on the
"qemu_work_cond".
void qemu_cpu_kick(void *_env)
{
CPUArchState *env = _env;
qemu_cond_broadcast(env->halt_cond);
if (!tcg_enabled() && !env->thread_kicked) {
qemu_cpu_kick_thread(env);
env->thread_kicked = true;
}
}
A "SIG_IPI" is sent to the vcpu thread, which wakes up the target VCPU
thread.
static void qemu_cpu_kick_thread(CPUArchState *env)
{
int err;
err = pthread_kill(env->thread->thread, SIG_IPI);
if (err) {
fprintf(stderr, "qemu:%s: %s", __func__, strerror(err));
exit(1);
}
}
And this thread flushes the queued work using the following function and
unblocks the original thread waiting on "qemu_work_cond".
static void flush_queued_work(CPUArchState *env)
{
struct qemu_work_item *wi;
if (!env->queued_work_first) {
return;
}
while ((wi = env->queued_work_first)) {
env->queued_work_first = wi->next;
wi->func(wi->data);
wi->done = true;
}
env->queued_work_last = NULL;
qemu_cond_broadcast(&qemu_work_cond);
}
This mechanism 'seems' to work fine when both vcpu threads are in User
Mode. But when booting an SMP Guest, the boot processor (BSP) initially
executes the bootstrap code while the non-boot processors (APs) are
waiting for initial INIT-SIPI-SIPI messages.
What I fail to understand is if an AP is currently waiting for an INIT
signal, and we call the "run_on_cpu" function above for this cpu, it
blocks the whole system, as the AP is in Guest mode and cannot call the
"flush_queued_work" and the BSP is waiting for this to happen.
How can we resolve this deadlock ? Is there a way to force the AP to
quit the Guest Mode, by using some specific mechanism from the User mode ?
I hope I was able to explain the problem.
Best Regards,
Hamayun
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2685 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Can we force a KVM VCPU in Guest Mode to Exit to User Mode From User Mode ?
2012-07-26 9:38 Can we force a KVM VCPU in Guest Mode to Exit to User Mode From User Mode ? Mian M. Hamayun
@ 2012-07-26 10:06 ` Avi Kivity
2012-07-26 10:34 ` Mian M. Hamayun
0 siblings, 1 reply; 6+ messages in thread
From: Avi Kivity @ 2012-07-26 10:06 UTC (permalink / raw)
To: mian-muhammad.hamayun; +Cc: kvm
On 07/26/2012 12:38 PM, Mian M. Hamayun wrote:
<snip>
>
> This mechanism 'seems' to work fine when both vcpu threads are in User
> Mode. But when booting an SMP Guest, the boot processor (BSP) initially
> executes the bootstrap code while the non-boot processors (APs) are
> waiting for initial INIT-SIPI-SIPI messages.
>
> What I fail to understand is if an AP is currently waiting for an INIT
> signal, and we call the "run_on_cpu" function above for this cpu, it
> blocks the whole system, as the AP is in Guest mode and cannot call the
> "flush_queued_work" and the BSP is waiting for this to happen.
>
> How can we resolve this deadlock ? Is there a way to force the AP to
> quit the Guest Mode, by using some specific mechanism from the User mode ?
When a vcpu is waiting for an INIT, it still responds to signals and
will return to userspace if a signal is received. Did you observe
something different?
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Can we force a KVM VCPU in Guest Mode to Exit to User Mode From User Mode ?
2012-07-26 10:06 ` Avi Kivity
@ 2012-07-26 10:34 ` Mian M. Hamayun
2012-07-26 10:43 ` Avi Kivity
0 siblings, 1 reply; 6+ messages in thread
From: Mian M. Hamayun @ 2012-07-26 10:34 UTC (permalink / raw)
To: Avi Kivity; +Cc: kvm
[-- Attachment #1: Type: text/plain, Size: 3960 bytes --]
On 07/26/2012 12:06 PM, Avi Kivity wrote:
> On 07/26/2012 12:38 PM, Mian M. Hamayun wrote:
>
> <snip>
>
>> This mechanism 'seems' to work fine when both vcpu threads are in User
>> Mode. But when booting an SMP Guest, the boot processor (BSP) initially
>> executes the bootstrap code while the non-boot processors (APs) are
>> waiting for initial INIT-SIPI-SIPI messages.
>>
>> What I fail to understand is if an AP is currently waiting for an INIT
>> signal, and we call the "run_on_cpu" function above for this cpu, it
>> blocks the whole system, as the AP is in Guest mode and cannot call the
>> "flush_queued_work" and the BSP is waiting for this to happen.
>>
>> How can we resolve this deadlock ? Is there a way to force the AP to
>> quit the Guest Mode, by using some specific mechanism from the User mode ?
> When a vcpu is waiting for an INIT, it still responds to signals and
> will return to userspace if a signal is received. Did you observe
> something different?
>
Hi Avi,
So it means that when we execute the following:
err = pthread_kill(env->thread, SIG_IPI);
then this VCPU thread should wake-up and force the VCPU to quit the
guest mode ?
But I am not getting this behavior as the VCPU thread remains blocked in
Guest Mode.
What could be wrong here ?
Many Thanks,
Hamayun
P.S. Please see the following trace; As it might help understanding the
problem. (thread 2 is the BSP and thread 3 is for AP)
run_on_cpu: Kicked CPU#1 ... Waiting on qemu_work_cond
Program received signal SIGUSR1, User defined signal 1.
^C
Program received signal SIGINT, Interrupt.
0xb7fdd424 in __kernel_vsyscall ()
(gdb) info threads
Id Target Id Frame
3 Thread 0xaea17b40 (LWP 2843) "arch.x" 0xb7fdd424 in
__kernel_vsyscall ()
2 Thread 0xaf218b40 (LWP 2842) "arch.x" 0xb7fdd424 in
__kernel_vsyscall ()
* 1 Thread 0xb7359940 (LWP 2822) "arch.x" 0xb7fdd424 in
__kernel_vsyscall ()
(gdb) thread 2
[Switching to thread 2 (Thread 0xaf218b40 (LWP 2842))]
#0 0xb7fdd424 in __kernel_vsyscall ()
(gdb) bt
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb7f7096b in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/i386-linux-gnu/libpthread.so.0
#2 0xb7fc5715 in qemu_cond_wait (cond=0xb7fda640, lock=0xb7fda670) at
gdb_srv_arch.c:578
#3 0xb7fc5981 in run_on_cpu (env=0x8465818, func=0xb7fc5417
<kvm_invoke_set_guest_debug>, data=0xaf20fe50) at gdb_srv_arch.c:782
#4 0xb7fc5b90 in kvm_update_guest_debug (env=0x8465818,
reinject_trap=0) at gdb_srv_arch.c:863
#5 0xb7fc5ef1 in kvm_remove_all_breakpoints (current_env=0x8465418) at
gdb_srv_arch.c:983
#6 0xb7fc2e0a in gdb_breakpoint_remove_all (env=0x8465418) at gdb_srv.c:369
#7 0xb7fc3139 in gdb_handle_packet (s=0x80ac3e0, line_buf=0x80ac3fc
"?") at gdb_srv.c:497
#8 0xb7fc439c in gdb_read_byte (s=0x80ac3e0, ch=102) at gdb_srv.c:830
#9 0xb7fc4522 in gdb_loop (env=0x8465418) at gdb_srv.c:878
#10 0xb7fc4621 in gdb_srv_handle_debug (env=0x8465418) at gdb_srv.c:924
#11 0xb7fc5265 in kvm_arch_handle_debug (env=0x8465418) at
gdb_srv_arch.c:424
#12 0xb7fac3a8 in kvm_cpu__start (cpu=0x8465418) at kvm-cpu.c:588
#13 0xb7fc6521 in kvm_cpu_thread (arg=0x8465418) at libkvm-main.c:276
#14 0xb7f6cd4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#15 0xb7d7bace in clone () from /lib/i386-linux-gnu/libc.so.6
(gdb) thread 3
[Switching to thread 3 (Thread 0xaea17b40 (LWP 2843))]
#0 0xb7fdd424 in __kernel_vsyscall ()
(gdb) bt
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb7d73869 in ioctl () from /lib/i386-linux-gnu/libc.so.6
#2 0xb7fabe9c in kvm_cpu__run (vcpu=0x8465818) at kvm-cpu.c:429
#3 0xb7fac376 in kvm_cpu__start (cpu=0x8465818) at kvm-cpu.c:578
#4 0xb7fc6521 in kvm_cpu_thread (arg=0x8465818) at libkvm-main.c:276
#5 0xb7f6cd4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#6 0xb7d7bace in clone () from /lib/i386-linux-gnu/libc.so.6
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2685 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Can we force a KVM VCPU in Guest Mode to Exit to User Mode From User Mode ?
2012-07-26 10:34 ` Mian M. Hamayun
@ 2012-07-26 10:43 ` Avi Kivity
2012-07-26 13:39 ` Mian M. Hamayun
0 siblings, 1 reply; 6+ messages in thread
From: Avi Kivity @ 2012-07-26 10:43 UTC (permalink / raw)
To: mian-muhammad.hamayun; +Cc: kvm
On 07/26/2012 01:34 PM, Mian M. Hamayun wrote:
>
> On 07/26/2012 12:06 PM, Avi Kivity wrote:
>> On 07/26/2012 12:38 PM, Mian M. Hamayun wrote:
>>
>> <snip>
>>
>>> This mechanism 'seems' to work fine when both vcpu threads are in User
>>> Mode. But when booting an SMP Guest, the boot processor (BSP) initially
>>> executes the bootstrap code while the non-boot processors (APs) are
>>> waiting for initial INIT-SIPI-SIPI messages.
>>>
>>> What I fail to understand is if an AP is currently waiting for an INIT
>>> signal, and we call the "run_on_cpu" function above for this cpu, it
>>> blocks the whole system, as the AP is in Guest mode and cannot call the
>>> "flush_queued_work" and the BSP is waiting for this to happen.
>>>
>>> How can we resolve this deadlock ? Is there a way to force the AP to
>>> quit the Guest Mode, by using some specific mechanism from the User
>>> mode ?
>> When a vcpu is waiting for an INIT, it still responds to signals and
>> will return to userspace if a signal is received. Did you observe
>> something different?
>>
>
> Hi Avi,
>
> So it means that when we execute the following:
>
> err = pthread_kill(env->thread, SIG_IPI);
>
> then this VCPU thread should wake-up and force the VCPU to quit the
> guest mode ?
Yes.
> But I am not getting this behavior as the VCPU thread remains blocked in
> Guest Mode.
> What could be wrong here ?
>
Perhaps signals are blocked?
Can you share your reproducer?
> Many Thanks,
> Hamayun
>
> P.S. Please see the following trace; As it might help understanding the
> problem. (thread 2 is the BSP and thread 3 is for AP)
>
> run_on_cpu: Kicked CPU#1 ... Waiting on qemu_work_cond
>
> Program received signal SIGUSR1, User defined signal 1.
> ^C
> Program received signal SIGINT, Interrupt.
> 0xb7fdd424 in __kernel_vsyscall ()
> (gdb) info threads
> Id Target Id Frame
> 3 Thread 0xaea17b40 (LWP 2843) "arch.x" 0xb7fdd424 in
> __kernel_vsyscall ()
> 2 Thread 0xaf218b40 (LWP 2842) "arch.x" 0xb7fdd424 in
> __kernel_vsyscall ()
> * 1 Thread 0xb7359940 (LWP 2822) "arch.x" 0xb7fdd424 in
> __kernel_vsyscall ()
> (gdb) thread 2
> [Switching to thread 2 (Thread 0xaf218b40 (LWP 2842))]
> #0 0xb7fdd424 in __kernel_vsyscall ()
> (gdb) bt
> #0 0xb7fdd424 in __kernel_vsyscall ()
> #1 0xb7f7096b in pthread_cond_wait@@GLIBC_2.3.2 () from
> /lib/i386-linux-gnu/libpthread.so.0
> #2 0xb7fc5715 in qemu_cond_wait (cond=0xb7fda640, lock=0xb7fda670) at
> gdb_srv_arch.c:578
> #3 0xb7fc5981 in run_on_cpu (env=0x8465818, func=0xb7fc5417
> <kvm_invoke_set_guest_debug>, data=0xaf20fe50) at gdb_srv_arch.c:782
> #4 0xb7fc5b90 in kvm_update_guest_debug (env=0x8465818,
> reinject_trap=0) at gdb_srv_arch.c:863
> #5 0xb7fc5ef1 in kvm_remove_all_breakpoints (current_env=0x8465418) at
> gdb_srv_arch.c:983
> #6 0xb7fc2e0a in gdb_breakpoint_remove_all (env=0x8465418) at
> gdb_srv.c:369
> #7 0xb7fc3139 in gdb_handle_packet (s=0x80ac3e0, line_buf=0x80ac3fc
> "?") at gdb_srv.c:497
> #8 0xb7fc439c in gdb_read_byte (s=0x80ac3e0, ch=102) at gdb_srv.c:830
> #9 0xb7fc4522 in gdb_loop (env=0x8465418) at gdb_srv.c:878
> #10 0xb7fc4621 in gdb_srv_handle_debug (env=0x8465418) at gdb_srv.c:924
> #11 0xb7fc5265 in kvm_arch_handle_debug (env=0x8465418) at
> gdb_srv_arch.c:424
> #12 0xb7fac3a8 in kvm_cpu__start (cpu=0x8465418) at kvm-cpu.c:588
> #13 0xb7fc6521 in kvm_cpu_thread (arg=0x8465418) at libkvm-main.c:276
> #14 0xb7f6cd4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
> #15 0xb7d7bace in clone () from /lib/i386-linux-gnu/libc.so.6
> (gdb) thread 3
> [Switching to thread 3 (Thread 0xaea17b40 (LWP 2843))]
> #0 0xb7fdd424 in __kernel_vsyscall ()
> (gdb) bt
> #0 0xb7fdd424 in __kernel_vsyscall ()
> #1 0xb7d73869 in ioctl () from /lib/i386-linux-gnu/libc.so.6
> #2 0xb7fabe9c in kvm_cpu__run (vcpu=0x8465818) at kvm-cpu.c:429
> #3 0xb7fac376 in kvm_cpu__start (cpu=0x8465818) at kvm-cpu.c:578
> #4 0xb7fc6521 in kvm_cpu_thread (arg=0x8465818) at libkvm-main.c:276
> #5 0xb7f6cd4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
> #6 0xb7d7bace in clone () from /lib/i386-linux-gnu/libc.so.6
>
Are you sure thread 3 did not receive the signal?
Try stracing the run.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Can we force a KVM VCPU in Guest Mode to Exit to User Mode From User Mode ?
2012-07-26 10:43 ` Avi Kivity
@ 2012-07-26 13:39 ` Mian M. Hamayun
2012-07-26 13:55 ` Avi Kivity
0 siblings, 1 reply; 6+ messages in thread
From: Mian M. Hamayun @ 2012-07-26 13:39 UTC (permalink / raw)
To: Avi Kivity; +Cc: kvm
[-- Attachment #1: Type: text/plain, Size: 6332 bytes --]
On 07/26/2012 12:43 PM, Avi Kivity wrote:
> On 07/26/2012 01:34 PM, Mian M. Hamayun wrote:
>> On 07/26/2012 12:06 PM, Avi Kivity wrote:
>>> On 07/26/2012 12:38 PM, Mian M. Hamayun wrote:
>>>
>>> <snip>
>>>
>>>> This mechanism 'seems' to work fine when both vcpu threads are in User
>>>> Mode. But when booting an SMP Guest, the boot processor (BSP) initially
>>>> executes the bootstrap code while the non-boot processors (APs) are
>>>> waiting for initial INIT-SIPI-SIPI messages.
>>>>
>>>> What I fail to understand is if an AP is currently waiting for an INIT
>>>> signal, and we call the "run_on_cpu" function above for this cpu, it
>>>> blocks the whole system, as the AP is in Guest mode and cannot call the
>>>> "flush_queued_work" and the BSP is waiting for this to happen.
>>>>
>>>> How can we resolve this deadlock ? Is there a way to force the AP to
>>>> quit the Guest Mode, by using some specific mechanism from the User
>>>> mode ?
>>> When a vcpu is waiting for an INIT, it still responds to signals and
>>> will return to userspace if a signal is received. Did you observe
>>> something different?
>>>
>> Hi Avi,
>>
>> So it means that when we execute the following:
>>
>> err = pthread_kill(env->thread, SIG_IPI);
>>
>> then this VCPU thread should wake-up and force the VCPU to quit the
>> guest mode ?
> Yes.
>
>> But I am not getting this behavior as the VCPU thread remains blocked in
>> Guest Mode.
>> What could be wrong here ?
>>
> Perhaps signals are blocked?
No, thats not the case.
>
> Can you share your reproducer?
Actually its based on kvm-tool and I have integrated some code from
qemu-kvm to add debug support to kvm-tool.
I don't have a smaller example that could reproduce the same problem.
>
>> Many Thanks,
>> Hamayun
>>
>> P.S. Please see the following trace; As it might help understanding the
>> problem. (thread 2 is the BSP and thread 3 is for AP)
>>
>> run_on_cpu: Kicked CPU#1 ... Waiting on qemu_work_cond
>>
>> Program received signal SIGUSR1, User defined signal 1.
>> ^C
>> Program received signal SIGINT, Interrupt.
>> 0xb7fdd424 in __kernel_vsyscall ()
>> (gdb) info threads
>> Id Target Id Frame
>> 3 Thread 0xaea17b40 (LWP 2843) "arch.x" 0xb7fdd424 in
>> __kernel_vsyscall ()
>> 2 Thread 0xaf218b40 (LWP 2842) "arch.x" 0xb7fdd424 in
>> __kernel_vsyscall ()
>> * 1 Thread 0xb7359940 (LWP 2822) "arch.x" 0xb7fdd424 in
>> __kernel_vsyscall ()
>> (gdb) thread 2
>> [Switching to thread 2 (Thread 0xaf218b40 (LWP 2842))]
>> #0 0xb7fdd424 in __kernel_vsyscall ()
>> (gdb) bt
>> #0 0xb7fdd424 in __kernel_vsyscall ()
>> #1 0xb7f7096b in pthread_cond_wait@@GLIBC_2.3.2 () from
>> /lib/i386-linux-gnu/libpthread.so.0
>> #2 0xb7fc5715 in qemu_cond_wait (cond=0xb7fda640, lock=0xb7fda670) at
>> gdb_srv_arch.c:578
>> #3 0xb7fc5981 in run_on_cpu (env=0x8465818, func=0xb7fc5417
>> <kvm_invoke_set_guest_debug>, data=0xaf20fe50) at gdb_srv_arch.c:782
>> #4 0xb7fc5b90 in kvm_update_guest_debug (env=0x8465818,
>> reinject_trap=0) at gdb_srv_arch.c:863
>> #5 0xb7fc5ef1 in kvm_remove_all_breakpoints (current_env=0x8465418) at
>> gdb_srv_arch.c:983
>> #6 0xb7fc2e0a in gdb_breakpoint_remove_all (env=0x8465418) at
>> gdb_srv.c:369
>> #7 0xb7fc3139 in gdb_handle_packet (s=0x80ac3e0, line_buf=0x80ac3fc
>> "?") at gdb_srv.c:497
>> #8 0xb7fc439c in gdb_read_byte (s=0x80ac3e0, ch=102) at gdb_srv.c:830
>> #9 0xb7fc4522 in gdb_loop (env=0x8465418) at gdb_srv.c:878
>> #10 0xb7fc4621 in gdb_srv_handle_debug (env=0x8465418) at gdb_srv.c:924
>> #11 0xb7fc5265 in kvm_arch_handle_debug (env=0x8465418) at
>> gdb_srv_arch.c:424
>> #12 0xb7fac3a8 in kvm_cpu__start (cpu=0x8465418) at kvm-cpu.c:588
>> #13 0xb7fc6521 in kvm_cpu_thread (arg=0x8465418) at libkvm-main.c:276
>> #14 0xb7f6cd4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
>> #15 0xb7d7bace in clone () from /lib/i386-linux-gnu/libc.so.6
>> (gdb) thread 3
>> [Switching to thread 3 (Thread 0xaea17b40 (LWP 2843))]
>> #0 0xb7fdd424 in __kernel_vsyscall ()
>> (gdb) bt
>> #0 0xb7fdd424 in __kernel_vsyscall ()
>> #1 0xb7d73869 in ioctl () from /lib/i386-linux-gnu/libc.so.6
>> #2 0xb7fabe9c in kvm_cpu__run (vcpu=0x8465818) at kvm-cpu.c:429
>> #3 0xb7fac376 in kvm_cpu__start (cpu=0x8465818) at kvm-cpu.c:578
>> #4 0xb7fc6521 in kvm_cpu_thread (arg=0x8465818) at libkvm-main.c:276
>> #5 0xb7f6cd4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
>> #6 0xb7d7bace in clone () from /lib/i386-linux-gnu/libc.so.6
>>
> Are you sure thread 3 did not receive the signal?
The thread 3 does actually receives the signal, but the order is not right.
As the BSP (Thread 2) starts, it locks the "qemu_global_mutex" and
releases it only when it calls the "run_on_cpu" function and starts
waiting on "qemu_work_cond".
The AP (Thread 3) wakes-up due to the SIG_IPI signal from thread 2,
acquires the lock on "qemu_global_mutex" and enters the guest mode.
(This is the deadlock case)
If we do not lock the "qemu_global_mutex" in each cpu thread at the
beginning, and only lock it when we quit the guest mode, the problem
seems to go away, as now we get the SIG_IPI when the Thread 3 is
actually in the guest mode and it quits to user mode.
But I am not sure if this is the right way to do it, as in qemu-kvm we
_always_ start each cpu thread by locking the "qemu_global_mutex".
i.e.
static void *qemu_kvm_cpu_thread_fn(void *arg)
{
CPUArchState *env = arg;
int r;
qemu_mutex_lock(&qemu_global_mutex);
qemu_thread_get_self(env->thread);
env->thread_id = qemu_get_thread_id();
cpu_single_env = env;
r = kvm_init_vcpu(env);
if (r < 0) {
fprintf(stderr, "kvm_init_vcpu failed: %s\n", strerror(-r));
exit(1);
}
qemu_kvm_init_cpu_signals(env);
/* signal CPU creation */
env->created = 1;
qemu_cond_signal(&qemu_cpu_cond);
while (1) {
if (cpu_can_run(env)) {
r = kvm_cpu_exec(env);
if (r == EXCP_DEBUG) {
cpu_handle_guest_debug(env);
}
}
qemu_kvm_wait_io_event(env);
}
return NULL;
}
>
> Try stracing the run.
>
>
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2685 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Can we force a KVM VCPU in Guest Mode to Exit to User Mode From User Mode ?
2012-07-26 13:39 ` Mian M. Hamayun
@ 2012-07-26 13:55 ` Avi Kivity
0 siblings, 0 replies; 6+ messages in thread
From: Avi Kivity @ 2012-07-26 13:55 UTC (permalink / raw)
To: mian-muhammad.hamayun; +Cc: kvm
On 07/26/2012 04:39 PM, Mian M. Hamayun wrote:
>>
>> Can you share your reproducer?
> Actually its based on kvm-tool and I have integrated some code from
> qemu-kvm to add debug support to kvm-tool.
> I don't have a smaller example that could reproduce the same problem.
Then there's probably a bug there.
>
> The thread 3 does actually receives the signal, but the order is not right.
>
> As the BSP (Thread 2) starts, it locks the "qemu_global_mutex" and
> releases it only when it calls the "run_on_cpu" function and starts
> waiting on "qemu_work_cond".
> The AP (Thread 3) wakes-up due to the SIG_IPI signal from thread 2,
> acquires the lock on "qemu_global_mutex" and enters the guest mode.
> (This is the deadlock case)
Why would it enter guest mode? Shouldn't it execute the function you
queued?
>
> If we do not lock the "qemu_global_mutex" in each cpu thread at the
> beginning, and only lock it when we quit the guest mode, the problem
> seems to go away, as now we get the SIG_IPI when the Thread 3 is
> actually in the guest mode and it quits to user mode.
> But I am not sure if this is the right way to do it, as in qemu-kvm we
> _always_ start each cpu thread by locking the "qemu_global_mutex".
Do you call KVM_SET_SIGNAL_MASK to allow the signal?
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-07-26 13:56 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-07-26 9:38 Can we force a KVM VCPU in Guest Mode to Exit to User Mode From User Mode ? Mian M. Hamayun
2012-07-26 10:06 ` Avi Kivity
2012-07-26 10:34 ` Mian M. Hamayun
2012-07-26 10:43 ` Avi Kivity
2012-07-26 13:39 ` Mian M. Hamayun
2012-07-26 13:55 ` Avi Kivity
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).