From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [BUG][PATCH?] kvm: unhandled wrmsr: 0xc0000083 Date: Sun, 19 Aug 2007 10:36:06 +0300 Message-ID: <46C7F2E6.4030808@qumranet.com> References: <20070811212520.GA26794@dreamland.darkstar.lan> <46C01FDA.9000302@qumranet.com> <68676e00708171314r4be1840bo95f5af50df6f7dfd@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-TtF/mJH4Jtrk1uMJSBkQmQ@public.gmane.org, Uri Lublin To: Luca Return-path: In-Reply-To: <68676e00708171314r4be1840bo95f5af50df6f7dfd-JsoAwUIsXosN+BqQ9rBEUg@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 Luca wrote: > On 8/13/07, Avi Kivity wrote: > >> Luca Tettamanti wrote: >> >>> The patch stops the "unhandled wrmsr", but reboot is still not working >>> (guest is stuck using 100% of the CPU). The last working userspace is >>> KVM-28, and I tested it with recent kernel modules. Any idea on this >>> one? >>> >>> >> That's around the time kvm moved to its own main loop (for smp), so it's >> not surprising there's breakage there. I tested erboot at the time, but >> not with all guests. >> > > Here I can't reboot anything... the only thing that works is GRUB, but > I guess that it just goes through the BIOS. > > I debugged a bit the problem, but I'm not sure about the solution. > This is what's happening: > - guest requests the reboot, the corresponding branch > kvm_main_loop_cpu() is executed. > - qemu_system_reset() is called; among the other stuff the APIC is > re-initialized. > - kvm_apic_init (called via reset notifier: qemu_system_reset -> > apic_reset -> apic_init_ipi -> > kvm_apic_init) set the ->init flag of the vcpu to 1 > - in next loop if (info->init) is executed. Forever ;-) > > The only thing that clears ->init is kvm_update_after_sipi which in > turn is only called by apic_startup; (I'm following the execution with > gdb and that function is never called, btw). Anyway, as long as ->init > is set, guest code won't be executed, so qemu/kvm spins forever in the > main loop, executing update_regs_for_init(). > Hmm. INIT processing should be different for the boot processor (->cpu_index == 0), in that it should resume execution after INIT, whereas non-boot processors enter a halt state waiting for a SIPI. Maybe that's the issue. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- 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/