* Starting a VM using /dev/kvm
@ 2013-11-19 23:56 Jim MacArthur
2013-11-20 17:28 ` Paolo Bonzini
0 siblings, 1 reply; 6+ messages in thread
From: Jim MacArthur @ 2013-11-19 23:56 UTC (permalink / raw)
To: kvm
I'm new to KVM and as a learning exercise I'd like to start a VM and
run a few instructions by using ioctls on /dev/kvm. This might be a
terrible idea, please say so if it is.
I haven't been able to find much information on it, but by reading the
API document and stracing qemu I've put together a small program which
creates a VM, VCPU, and sets up some memory. All of these ioctls
return successfully, but trying to run always returns with exit code
17 and suberror 1 which so far as I can tell seems to be a problem
with page tables. I'm on an x86_64 host.
The question is, how does a new vcpu start up? Will it start in full
64-bit mode or 16-bit real mode? And will I need a full set of
translation tables to run a single instruction or can I just point it
at some memory and expect it to run?
Thanks for any help you can offer.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Starting a VM using /dev/kvm
2013-11-19 23:56 Starting a VM using /dev/kvm Jim MacArthur
@ 2013-11-20 17:28 ` Paolo Bonzini
2013-11-21 0:39 ` Jim MacArthur
0 siblings, 1 reply; 6+ messages in thread
From: Paolo Bonzini @ 2013-11-20 17:28 UTC (permalink / raw)
To: Jim MacArthur; +Cc: kvm
Il 20/11/2013 00:56, Jim MacArthur ha scritto:
> I haven't been able to find much information on it, but by reading the
> API document and stracing qemu I've put together a small program which
> creates a VM, VCPU, and sets up some memory. All of these ioctls
> return successfully, but trying to run always returns with exit code
> 17 and suberror 1 which so far as I can tell seems to be a problem
> with page tables. I'm on an x86_64 host.
>
> The question is, how does a new vcpu start up? Will it start in full
> 64-bit mode or 16-bit real mode?
By default it start in 16-bit real mode, with CS=0xf000 and EIP=0xfff0,
but CS.base = 0xffff0000. However, you can send ioctls to modify
CR0/CR4/EFER and place the VCPU in whatever mode you'd like to have.
> And will I need a full set of
> translation tables to run a single instruction or can I just point it
> at some memory and expect it to run?
Real mode doesn't need page tables of course, and so does 32-bit
protected mode with CR0.PG=0. However, 64-bit mode only exists with
paging (and PAE) enabled. So you need page tables to enable 64-bit mode.
Paolo
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Starting a VM using /dev/kvm
2013-11-20 17:28 ` Paolo Bonzini
@ 2013-11-21 0:39 ` Jim MacArthur
2013-11-21 7:27 ` Gleb Natapov
0 siblings, 1 reply; 6+ messages in thread
From: Jim MacArthur @ 2013-11-21 0:39 UTC (permalink / raw)
To: Paolo Bonzini, kvm
On 20 November 2013 17:28, Paolo Bonzini <pbonzini@redhat.com> wrote:
> Il 20/11/2013 00:56, Jim MacArthur ha scritto:
>> The question is, how does a new vcpu start up? Will it start in full
>> 64-bit mode or 16-bit real mode?
>
> By default it start in 16-bit real mode, with CS=0xf000 and EIP=0xfff0,
> but CS.base = 0xffff0000. However, you can send ioctls to modify
> CR0/CR4/EFER and place the VCPU in whatever mode you'd like to have.
After reading this I added a call to KVM_GET_SREGS. Everything you say
here matches my experience except that CS.base=0xf0000.
So I adjusted my memory to cover physical address 0xFFFF0, and now
it's happily running instructions (NOPs, at least.)
I'm a bit puzzled that it didn't start with CS.base=0xffff0000, but it
doesn't matter, I've done what I wanted to do for now.
Thanks very much for your help.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Starting a VM using /dev/kvm
2013-11-21 0:39 ` Jim MacArthur
@ 2013-11-21 7:27 ` Gleb Natapov
2013-11-21 23:57 ` Jim MacArthur
0 siblings, 1 reply; 6+ messages in thread
From: Gleb Natapov @ 2013-11-21 7:27 UTC (permalink / raw)
To: Jim MacArthur; +Cc: Paolo Bonzini, kvm
On Thu, Nov 21, 2013 at 12:39:49AM +0000, Jim MacArthur wrote:
> On 20 November 2013 17:28, Paolo Bonzini <pbonzini@redhat.com> wrote:
> > Il 20/11/2013 00:56, Jim MacArthur ha scritto:
> >> The question is, how does a new vcpu start up? Will it start in full
> >> 64-bit mode or 16-bit real mode?
> >
> > By default it start in 16-bit real mode, with CS=0xf000 and EIP=0xfff0,
> > but CS.base = 0xffff0000. However, you can send ioctls to modify
> > CR0/CR4/EFER and place the VCPU in whatever mode you'd like to have.
>
> After reading this I added a call to KVM_GET_SREGS. Everything you say
> here matches my experience except that CS.base=0xf0000.
> So I adjusted my memory to cover physical address 0xFFFF0, and now
> it's happily running instructions (NOPs, at least.)
> I'm a bit puzzled that it didn't start with CS.base=0xffff0000, but it
> doesn't matter, I've done what I wanted to do for now.
>
What is your kernel version?
--
Gleb.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Starting a VM using /dev/kvm
2013-11-21 7:27 ` Gleb Natapov
@ 2013-11-21 23:57 ` Jim MacArthur
2013-11-22 6:56 ` Gleb Natapov
0 siblings, 1 reply; 6+ messages in thread
From: Jim MacArthur @ 2013-11-21 23:57 UTC (permalink / raw)
To: Gleb Natapov; +Cc: Paolo Bonzini, kvm
On 21 November 2013 07:27, Gleb Natapov <gleb@redhat.com> wrote:
> On Thu, Nov 21, 2013 at 12:39:49AM +0000, Jim MacArthur wrote:
>> After reading this I added a call to KVM_GET_SREGS. Everything you say
>> here matches my experience except that CS.base=0xf0000.
>> So I adjusted my memory to cover physical address 0xFFFF0, and now
>> it's happily running instructions (NOPs, at least.)
>> I'm a bit puzzled that it didn't start with CS.base=0xffff0000, but it
>> doesn't matter, I've done what I wanted to do for now.
>>
> What is your kernel version?
This is on a Mac mini: Linux version 3.2.0-56-generic
(buildd@roseapple) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) )
#86-Ubuntu SMP Wed Oct 23 09:20:45 UTC 2013
I get the same results from 3.2.0-4-amd64 on my thinkpad.
The code I'm running is at http://pastebin.com/Z1SR5Vid.
It's likely to be because I'm doing something wrong, and I've got what
I wanted working anyway. Thanks again for your help.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Starting a VM using /dev/kvm
2013-11-21 23:57 ` Jim MacArthur
@ 2013-11-22 6:56 ` Gleb Natapov
0 siblings, 0 replies; 6+ messages in thread
From: Gleb Natapov @ 2013-11-22 6:56 UTC (permalink / raw)
To: Jim MacArthur; +Cc: Paolo Bonzini, kvm
On Thu, Nov 21, 2013 at 11:57:46PM +0000, Jim MacArthur wrote:
> On 21 November 2013 07:27, Gleb Natapov <gleb@redhat.com> wrote:
> > On Thu, Nov 21, 2013 at 12:39:49AM +0000, Jim MacArthur wrote:
> >> After reading this I added a call to KVM_GET_SREGS. Everything you say
> >> here matches my experience except that CS.base=0xf0000.
> >> So I adjusted my memory to cover physical address 0xFFFF0, and now
> >> it's happily running instructions (NOPs, at least.)
> >> I'm a bit puzzled that it didn't start with CS.base=0xffff0000, but it
> >> doesn't matter, I've done what I wanted to do for now.
> >>
> > What is your kernel version?
>
> This is on a Mac mini: Linux version 3.2.0-56-generic
> (buildd@roseapple) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) )
> #86-Ubuntu SMP Wed Oct 23 09:20:45 UTC 2013
>
> I get the same results from 3.2.0-4-amd64 on my thinkpad.
>
> The code I'm running is at http://pastebin.com/Z1SR5Vid.
>
> It's likely to be because I'm doing something wrong, and I've got what
> I wanted working anyway. Thanks again for your help.
No, this is because old kernels started in incorrect state, on recent
kernels KVM_GET_SREGS will return correct one.
--
Gleb.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-11-22 6:56 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-11-19 23:56 Starting a VM using /dev/kvm Jim MacArthur
2013-11-20 17:28 ` Paolo Bonzini
2013-11-21 0:39 ` Jim MacArthur
2013-11-21 7:27 ` Gleb Natapov
2013-11-21 23:57 ` Jim MacArthur
2013-11-22 6:56 ` Gleb Natapov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox