From: "Mian M. Hamayun" <mian-muhammad.hamayun@imag.fr>
To: Avi Kivity <avi@redhat.com>
Cc: kvm@vger.kernel.org
Subject: Re: Can we force a KVM VCPU in Guest Mode to Exit to User Mode From User Mode ?
Date: Thu, 26 Jul 2012 12:34:57 +0200 [thread overview]
Message-ID: <50111D51.7050809@imag.fr> (raw)
In-Reply-To: <501116A1.90607@redhat.com>
[-- 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 --]
next prev parent reply other threads:[~2012-07-26 10:35 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2012-07-26 10:43 ` Avi Kivity
2012-07-26 13:39 ` Mian M. Hamayun
2012-07-26 13:55 ` Avi Kivity
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50111D51.7050809@imag.fr \
--to=mian-muhammad.hamayun@imag.fr \
--cc=avi@redhat.com \
--cc=kvm@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).