From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: pekka-vm and kvm documentation Date: Thu, 25 Mar 2010 22:57:31 +0200 Message-ID: <4BABCE3B.5080605@redhat.com> References: <4BAB1CCB.3070800@redhat.com> <4BABC636.5010905@cs.helsinki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: Pekka Enberg Return-path: Received: from mx1.redhat.com ([209.132.183.28]:19712 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751531Ab0CYU5h (ORCPT ); Thu, 25 Mar 2010 16:57:37 -0400 In-Reply-To: <4BABC636.5010905@cs.helsinki.fi> Sender: kvm-owner@vger.kernel.org List-ID: On 03/25/2010 10:23 PM, Pekka Enberg wrote: > Hi Avi, > > Avi Kivity wrote: >> When you come up against something that is undocumented or badly >> described, please complain on kvm@. We will then update the >> documentation. > > So one thing I'm wondering is in what mode do we enter the guest? Is > that entirely specified with KVM_SET_REGS and KVM_SET_SREGS? Yes. cr0.pe = real/protected, eflags.vm = vm86 mode, cs.d = prot16/prot32, efer.lme/efer.lma/cs.l = longmode. > > I assume we're entering real mode as per how I set up "rflags" but for > some reason I'm seeing "cs" base being zeroed out before first > instruction is executed with my simple kvm program which could mean > that it's trying to use GDT (which is not set up at that point). I see you set up the cpu as if after reset (cs:ip = f000:fff0) but just dumped a kernel there. That won't work, you need real code. Try poking 'e9 fd ff' at your entry point (ffff0) and see the cpu pegged at 100% (1: jmp 1b) (this is probably the largest possible kernel that is bug-free). -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.