From mboxrd@z Thu Jan 1 00:00:00 1970 From: david ahern Subject: Re: [ANNOUNCE] kvm-51 release Date: Mon, 12 Nov 2007 14:46:29 -0700 Message-ID: <4738C9B5.6060609@cisco.com> References: <4731F5B5.1000108@qumranet.com> <473435B6.1000503@bppiac.hu> <4736C752.7060703@qumranet.com> <4736FC77.2080804@bppiac.hu> <47371510.3020804@qumranet.com> <47372070.30604@cisco.com> <47372600.9080009@cisco.com> <47373380.8040809@qumranet.com> <47376FB3.30303@cisco.com> <47380C95.1030502@qumranet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel To: Avi Kivity Return-path: In-Reply-To: <47380C95.1030502-atKUWr5tajBWk0Htik3J/w@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org With kvm-52 my 32-bit host running RHEL5.1 can start an RHEL 5 SMP guest only once. Second and subsequent attempts hang. Removing kvm and kvm_intel modules have no affect; I need to reboot the host to get an SMP guest to start. My similarly configured 64-bit host does not seem to have this problem. Second attempts to start the RHEL5 SMP guest hang at: Starting udev: _ Looking at top on the host shows qemu in a loop: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3909 root 18 0 1625m 67m 9476 R 400 2.1 2:52.32 qemu-system-x86 In this case the qemu threads are: PID LWP TTY TIME CMD 3909 3909 pts/0 00:01:12 qemu-system-x86 3909 3911 pts/0 00:01:05 qemu-system-x86 3909 3912 pts/0 00:01:05 qemu-system-x86 3909 3913 pts/0 00:01:07 qemu-system-x86 3909 3917 pts/0 00:00:00 qemu-system-x86 and their kernel side backtraces are: process trace for qemu-system-x86(3909) f5967d88 00000082 f8c125e4 bbdec465 000001c6 f5230da4 00000001 f7acf000 f7d7d000 bbded629 000001c6 000011c4 00000000 f7acf110 c30126e0 00000001 f4d8a000 f5967d90 f5967d80 f5230da0 f5967000 f8c11120 f5230da0 f4d8a000 Call Trace: [] vmx_vcpu_put+0xef/0xf6 [kvm_intel] [] handle_external_interrupt+0x0/0xc [kvm_intel] [] __cond_resched+0x16/0x34 [] cond_resched+0x2a/0x31 [] kvm_arch_vcpu_ioctl_run+0x28d/0x333 [kvm] [] kvm_vcpu_ioctl+0x0/0x366 [kvm] [] kvm_vcpu_ioctl+0xbb/0x366 [kvm] [] __cond_resched+0x16/0x34 [] cond_resched+0x2a/0x31 [] core_sys_select+0x1ef/0x2ca [] __wake_up_common+0x2f/0x53 [] schedule+0x90d/0x9ba [] reschedule_interrupt+0x1f/0x24 [] __dequeue_signal+0x151/0x15c [] dequeue_signal+0x2d/0x9c [] sys_rt_sigtimedwait+0xc5/0x2c2 [] getnstimeofday+0x30/0xb6 [] ktime_get_ts+0x16/0x44 [] ktime_get+0x12/0x34 [] common_timer_get+0xee/0x129 [] kvm_vcpu_ioctl+0x0/0x366 [kvm] [] do_ioctl+0x1c/0x5d [] vfs_ioctl+0x24a/0x25c [] sys_ioctl+0x48/0x5f [] syscall_call+0x7/0xb ======================= process trace for qemu-system-x86(3911) c301a6e0 00000100 000001c7 f749baa0 00000001 c301a6e0 f749baa0 00000001 f51fed44 f51fed44 f51fed6c 00000001 00000001 00000046 f579ce20 f57ee000 00000001 c04059bf f579ce20 8005003b 00006c00 f8c113e5 f579ce20 f579ce20 Call Trace: [] apic_timer_interrupt+0x1f/0x24 [] vmcs_writel+0x1b/0x2c [kvm_intel] [] kvm_arch_vcpu_ioctl_run+0x202/0x333 [kvm] [] kvm_vcpu_ioctl+0x0/0x366 [kvm] [] kvm_vcpu_ioctl+0xbb/0x366 [kvm] [] enqueue_task+0x29/0x39 [] __activate_task+0x1c/0x29 [] try_to_wake_up+0x371/0x37b [] schedule+0x90d/0x9ba [] __wake_up_common+0x2f/0x53 [] __wake_up+0x2a/0x3d [] wake_futex+0x3a/0x44 [] futex_wake+0xa9/0xb3 [] do_futex+0x20d/0xb15 [] kvm_ack_smp_call+0x17/0x27 [kvm] [] __dequeue_signal+0x151/0x15c [] dequeue_signal+0x2d/0x9c [] kvm_vm_ioctl+0x0/0x277 [kvm] [] kvm_vm_ioctl+0x264/0x277 [kvm] [] default_wake_function+0x0/0xc [] call_function_interrupt+0x1f/0x24 [] kvm_vcpu_ioctl+0x0/0x366 [kvm] [] do_ioctl+0x1c/0x5d [] vfs_ioctl+0x24a/0x25c [] sys_ioctl+0x48/0x5f [] syscall_call+0x7/0xb ======================= process trace for qemu-system-x86(3912) f560fd88 00000082 f8c125e4 193272c5 000001c8 f52b6074 00000004 f7f09000 f7f09000 19328fc9 000001c8 00001d04 00000002 f52b6070 55eefb90 00000000 f52b6070 f5693000 f52b6070 8005003b 00006c00 f8c113e5 f52b6070 f52b6070 Call Trace: [] vmx_vcpu_put+0xef/0xf6 [kvm_intel] [] vmcs_writel+0x1b/0x2c [kvm_intel] [] kvm_arch_vcpu_ioctl_run+0x202/0x333 [kvm] [] kvm_vcpu_ioctl+0x0/0x366 [kvm] [] kvm_vcpu_ioctl+0xbb/0x366 [kvm] [] schedule+0x90d/0x9ba [] __wake_up_common+0x2f/0x53 [] find_extend_vma+0x12/0x49 [] get_futex_key+0x40/0xd0 [] futex_wake+0xa9/0xb3 [] do_futex+0x20d/0xb15 [] ext3_ordered_writepage+0x0/0x162 [ext3] [] __dequeue_signal+0x151/0x15c [] dequeue_signal+0x2d/0x9c [] kvm_vm_ioctl+0x0/0x277 [kvm] [] kvm_vm_ioctl+0x264/0x277 [kvm] [] default_wake_function+0x0/0xc [] kvm_vcpu_ioctl+0x0/0x366 [kvm] [] do_ioctl+0x1c/0x5d [] vfs_ioctl+0x24a/0x25c [] sys_ioctl+0x48/0x5f [] syscall_call+0x7/0xb ======================= process trace for qemu-system-x86(3913) c302a6e0 00000100 000001c8 f7488550 00000003 c302a6e0 f7488550 00000003 f4d92d44 f4d92d44 f4d92d6c 00000001 00000001 00000046 f52b6de0 f5aaa000 00000001 c04059bf f52b6de0 8005003b 00006c00 f8c113e5 f52b6de0 f52b6de0 Call Trace: [] apic_timer_interrupt+0x1f/0x24 [] vmcs_writel+0x1b/0x2c [kvm_intel] [] kvm_arch_vcpu_ioctl_run+0x202/0x333 [kvm] [] kvm_vcpu_ioctl+0x0/0x366 [kvm] [] kvm_vcpu_ioctl+0xbb/0x366 [kvm] [] schedule+0x90d/0x9ba [] __wake_up_common+0x2f/0x53 [] find_extend_vma+0x12/0x49 [] get_futex_key+0x40/0xd0 [] futex_wake+0xa9/0xb3 [] do_futex+0x20d/0xb15 [] call_function_interrupt+0x1f/0x24 [] __dequeue_signal+0x151/0x15c [] kvm_vm_ioctl+0x0/0x277 [kvm] [] kvm_vm_ioctl+0x264/0x277 [kvm] [] default_wake_function+0x0/0xc [] kvm_vcpu_ioctl+0x0/0x366 [kvm] [] do_ioctl+0x1c/0x5d [] vfs_ioctl+0x24a/0x25c [] sys_ioctl+0x48/0x5f [] syscall_call+0x7/0xb ======================= david Avi Kivity wrote: > david ahern wrote: >> The patch worked for me -- rhel4 smp guests boot fine on stock RHEL5 >> hosts, both 32-bit and 64-bit. >> >> > > Excellent. I had a premonition so it is already committed. > > Do note that smp_call_function_mask() emulation is pretty bad in terms > of performance on large multicores. On a dual code it's basically > equivalent to mainline, I guess it's okay for four-way, but above > four-way you will need either mainline or a better > smp_call_function_mask() (which is nontrivial but doable). > >> david >> >> >> Avi Kivity wrote: >> >>> david ahern wrote: >>> >>>> In RHEL 5.1 defines: >>>> >>>> #define CPU_TASKS_FROZEN 0x0010 >>>> >>>> #define CPU_ONLINE_FROZEN (CPU_ONLINE | CPU_TASKS_FROZEN) >>>> #define CPU_DEAD_FROZEN (CPU_DEAD | CPU_TASKS_FROZEN) >>>> >>>> which means in kvm-51/kernel/external-module-compat.h the '#ifndef >>>> CPU_TASKS_FROZEN' needs to have a case. For my purposes, I just moved >>>> up the endif around what was defined. >>>> >>> I committed a change which renders this unnecessary. Will be part of >>> kvm-52. >>> >>> >>>> With that change, kvm-51 compiles. I am still seeing 32-bit SMP guests >>>> hang on boot for both 32-bit and 64-bit hosts (again running RHEL5.1). >>>> >>> I still don't. Can you test the attached patch? >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> ------------------------------------------------------------------------- >>> >>> This SF.net email is sponsored by: Splunk Inc. >>> Still grepping through log files to find problems? Stop. >>> Now Search log events and configuration files using AJAX and a browser. >>> Download your FREE copy of Splunk now >> http://get.splunk.com/ >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> kvm-devel mailing list >>> kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org >>> https://lists.sourceforge.net/lists/listinfo/kvm-devel >>> > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/