From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [BUG][PATCH?] kvm: unhandled wrmsr: 0xc0000083 Date: Sun, 09 Sep 2007 20:13:14 +0300 Message-ID: <46E429AA.7090004@qumranet.com> References: <20070811212520.GA26794@dreamland.darkstar.lan> <46C01FDA.9000302@qumranet.com> <68676e00708171314r4be1840bo95f5af50df6f7dfd@mail.gmail.com> <46C7F2E6.4030808@qumranet.com> <20070819195458.GA31865@dreamland.darkstar.lan> <46C949C1.90807@qumranet.com> <20070903210949.GA19919@dreamland.darkstar.lan> <46E3EC48.60004@qumranet.com> <20070909170718.GA8918@dreamland.darkstar.lan> 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 Tettamanti Return-path: In-Reply-To: <20070909170718.GA8918-sTXFmx6KbOnUXq0IF5SVAZ4oGUkBHcCu@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 Tettamanti wrote: > Il Sun, Sep 09, 2007 at 03:51:20PM +0300, Avi Kivity ha scritto: > >> Luca Tettamanti wrote: >> >>>> Actually 0xfff2 is in the middle of an instruction. >>>> >>>> I'm guessing an 'out' instruction triggered the reboot, and >>>> skip_emulated_instruction() added 2 to rip. >>>> >>>> >>> I think you're right; the reset is triggered by an outb to 0x64. >>> >>> Now, with this patch: >>> >>> diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c >>> index 491c32c..722d838 100644 >>> --- a/qemu/qemu-kvm.c >>> +++ b/qemu/qemu-kvm.c >>> @@ -706,8 +706,12 @@ static void update_regs_for_sipi(CPUState *env) >>> static void update_regs_for_init(CPUState *env) >>> { >>> - cpu_reset(env); >>> - load_regs(env); >>> + if (env->cpu_index) { >>> + cpu_reset(env); >>> + load_regs(env); >>> + } else { >>> + vcpu_info[env->cpu_index].init = 0; >>> + } >>> } >>> >>> >> Can you explain this patch? Why is the boot cpu treated differently? >> I think the only difference should be the halted flag. >> > > The reset has already been done by qmeu_system_reset(), so it's > superfluous. Furthermore, the extra reset causes the vmentry failure. I just committed a patch which prevented .init from being set to 1 on cpu_index == 0. > I > still don't understand which check is failing though... > > These are tough... >>> the #GP makes more sense than the vm entry failure if the the emulator >>> is jumping to fff2. >>> >> Right. Maybe the processor dropped out of vm86 mode and we're getting #gp >> on ds. >> > > Ok, the culprit really is skip_emulated_instruction: skipping the > increment when EIP is 0xfff0 allows rebooting (yes, it's disgusting...) > > So I think that there are two different issues: > > 1) Extra reset in update_regs_for_init causes vm entry failure due to > invalid guest state > > 2) The emulator is doing something wrong since it used to handle the > reset just fine > It may have been timing. kvm continued to run for a bit, reaching a non-emulated instruction, and then the reset hit it in the face. The reset is much quicker now. We should probably both fix the kernel to handle reset-during-emulation correctly (one ugly way is to zero the instruction length if we're setting rip), and fix userspace to delay reset like it used to for compatibility with older kernels. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/