kvm-kmod.git

kvm-kmod.git

[Avi Kivity]

This is a small git repository for the kvm external module kit.  It 
includes a submodule link to the kernel tree, so when you check out the 
repository, it also checks out a kernel tree for a specific revision.  
This way the various scripts and the kernel source are always synchronized.

$ git clone git://git.kernel.org/pub/scm/virt/kvm/kvm-kmod.git
$ git submodule init
$ git submodule update
$ ./configure
$ make sync
$ make

Todo:

- add maint branches
- automatic 'make sync'? perhaps replace by symlimks?
- add release script

-- 
error compiling committee.c: too many arguments to function

Re: kvm-kmod.git

[Farkas Levente]

Avi Kivity wrote:
> This is a small git repository for the kvm external module kit.  It
> includes a submodule link to the kernel tree, so when you check out the
> repository, it also checks out a kernel tree for a specific revision. 
> This way the various scripts and the kernel source are always synchronized.
> 
> $ git clone git://git.kernel.org/pub/scm/virt/kvm/kvm-kmod.git
> $ git submodule init
> $ git submodule update
> $ ./configure
> $ make sync
> $ make
> 
> Todo:
> 
> - add maint branches
> - automatic 'make sync'? perhaps replace by symlimks?
> - add release script
> 

hi,
i see this big reorganization of the sources (which is good), but does
it means that there will be separate tarball releases for kvm-kmod and
kvm userspace (which can be compiled without other tarball and git
commands)?
if yes, it means there'll be one kvm-kmod tarball or for each kernel
there will be a different tarball?
thanks.

-- 
  Levente                               "Si vis pacem para bellum!"

Re: kvm-kmod.git

[Avi Kivity]

Farkas Levente wrote:
> hi,
> i see this big reorganization of the sources (which is good), but does
> it means that there will be separate tarball releases for kvm-kmod and
> kvm userspace (which can be compiled without other tarball and git
> commands)?
> if yes, it means there'll be one kvm-kmod tarball or for each kernel
> there will be a different tarball?
> thanks

There will be a qemu-kvm tarball (qemu only), kvm-kmod tarball (kernel 
module only, suitable for any supported host kernel), and kvm tarball 
(contains both of the above).

-- 
error compiling committee.c: too many arguments to function

Re: kvm-kmod.git

[Cam Macdonell]

Avi Kivity wrote:
> This is a small git repository for the kvm external module kit.  It 
> includes a submodule link to the kernel tree, so when you check out the 
> repository, it also checks out a kernel tree for a specific revision.  
> This way the various scripts and the kernel source are always synchronized.
> 
> $ git clone git://git.kernel.org/pub/scm/virt/kvm/kvm-kmod.git
> $ git submodule init
> $ git submodule update
> $ ./configure
> $ make sync
> $ make
> 
> Todo:
> 
> - add maint branches
> - automatic 'make sync'? perhaps replace by symlimks?
> - add release script

Configure spits out an error about include/asm not existing.  I think 
that make sync has to be run before configure to create the include 
directory and copy asm-x86 inside so that "ln -sf asm-"$karch" 
include/asm" will work.

Cam

Re: kvm-kmod.git

[Avi Kivity]

Cam Macdonell wrote:
> Configure spits out an error about include/asm not existing.  I think 
> that make sync has to be run before configure to create the include 
> directory and copy asm-x86 inside so that "ln -sf asm-"$karch" 
> include/asm" will work.

I changed configure to create include/ if it doesn't exist.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: kvm-kmod.git

[Michael S. Tsirkin]

On Mon, Apr 27, 2009 at 03:32:29PM +0300, Avi Kivity wrote:
> This is a small git repository for the kvm external module kit.

So, I am building on a host with CONFIG_KVM_TRACE set in its
kernel, but I run configure without enabling kvm trace.
As a result the module fails to link:

WARNING: "kvm_trace_ioctl" [/home/mtsirkin/scm/kvm-kmod/x86/kvm.ko] undefined!
WARNING: "kvm_trace_cleanup" [/home/mtsirkin/scm/kvm-kmod/x86/kvm.ko] undefined!

I think you need to undef CONFIG_KVM_TRACE somewhere to override the
value set in autoconf.h?

-- 
MST

Re: kvm-kmod.git

[Avi Kivity]

Michael S. Tsirkin wrote:
> On Mon, Apr 27, 2009 at 03:32:29PM +0300, Avi Kivity wrote:
>   
>> This is a small git repository for the kvm external module kit.
>>     
>
> So, I am building on a host with CONFIG_KVM_TRACE set in its
> kernel, but I run configure without enabling kvm trace.
> As a result the module fails to link:
>
> WARNING: "kvm_trace_ioctl" [/home/mtsirkin/scm/kvm-kmod/x86/kvm.ko] undefined!
> WARNING: "kvm_trace_cleanup" [/home/mtsirkin/scm/kvm-kmod/x86/kvm.ko] undefined!
>
> I think you need to undef CONFIG_KVM_TRACE somewhere to override the
> value set in autoconf.h?
>   

Or maybe, add a s/CONFIG_KVM_TRACE/CONFIG_KMOD_KVM_TRACE/ to make the 
two options independent.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: kvm-kmod.git

[Michael S. Tsirkin]

On Tue, Apr 28, 2009 at 01:24:44PM +0300, Avi Kivity wrote:
> Michael S. Tsirkin wrote:
>> On Mon, Apr 27, 2009 at 03:32:29PM +0300, Avi Kivity wrote:
>>   
>>> This is a small git repository for the kvm external module kit.
>>>     
>>
>> So, I am building on a host with CONFIG_KVM_TRACE set in its
>> kernel, but I run configure without enabling kvm trace.
>> As a result the module fails to link:
>>
>> WARNING: "kvm_trace_ioctl" [/home/mtsirkin/scm/kvm-kmod/x86/kvm.ko] undefined!
>> WARNING: "kvm_trace_cleanup" [/home/mtsirkin/scm/kvm-kmod/x86/kvm.ko] undefined!
>>
>> I think you need to undef CONFIG_KVM_TRACE somewhere to override the
>> value set in autoconf.h?
>>   
>
> Or maybe, add a s/CONFIG_KVM_TRACE/CONFIG_KMOD_KVM_TRACE/ to make the  
> two options independent.

You decide. I also wonder what happens if one tries to build on
a machine with kvm built into kernel. Ideally one would get
a clear error message.

-- 
MST

Re: kvm-kmod.git

[Avi Kivity]

Michael S. Tsirkin wrote:
>> Or maybe, add a s/CONFIG_KVM_TRACE/CONFIG_KMOD_KVM_TRACE/ to make the  
>> two options independent.
>>     
>
> You decide. 

Well, I think it's less confusing.

> I also wonder what happens if one tries to build on
> a machine with kvm built into kernel. Ideally one would get
> a clear error message.
>   

kvm-kmod is really designed for those running on pre-kvm distro kernels, 
and for those testing newer kvm versions on distro kernels.  If you can 
compile your own kernel, download kvm.git and run that.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: kvm-kmod.git

[Michael S. Tsirkin]

On Tue, Apr 28, 2009 at 01:53:26PM +0300, Avi Kivity wrote:
> Michael S. Tsirkin wrote:
>>> Or maybe, add a s/CONFIG_KVM_TRACE/CONFIG_KMOD_KVM_TRACE/ to make the 
>>>  two options independent.
>>>     
>>
>> You decide. 
>
> Well, I think it's less confusing.

Fine. Patch?

-- 
MST

Re: kvm-kmod.git

[Avi Kivity]

Michael S. Tsirkin wrote:
> On Tue, Apr 28, 2009 at 01:53:26PM +0300, Avi Kivity wrote:
>   
>> Michael S. Tsirkin wrote:
>>     
>>>> Or maybe, add a s/CONFIG_KVM_TRACE/CONFIG_KMOD_KVM_TRACE/ to make the 
>>>>  two options independent.
>>>>     
>>>>         
>>> You decide. 
>>>       
>> Well, I think it's less confusing.
>>     
>
> Fine. Patch?
>
>   

Please.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: kvm-kmod.git

[Ryan Harper]

* Avi Kivity <avi@redhat.com> [2009-04-28 05:53]:
> Michael S. Tsirkin wrote:
> >>Or maybe, add a s/CONFIG_KVM_TRACE/CONFIG_KMOD_KVM_TRACE/ to make the  
> >>two options independent.
> >>    
> >
> >You decide. 
> 
> Well, I think it's less confusing.
> 
> >I also wonder what happens if one tries to build on
> >a machine with kvm built into kernel. Ideally one would get
> >a clear error message.
> >  
> 
> kvm-kmod is really designed for those running on pre-kvm distro kernels, 
> and for those testing newer kvm versions on distro kernels.  If you can 
> compile your own kernel, download kvm.git and run that.

So no way of having kvm-kmod sync in kvm.git bits and still build
against the current running kernel?

I wanted to test out 2.6.29-maint kernel modules and in
kvm-userspace/kernel, I could checkout maint/2.6.29 in kvm.git and then
make LINUX= sync.  I couldn't quite figure out how to do that with
kvm-kmod since when I do a ./configure --kerneldir -- it's building
modules *for* whatever kernel is at kerneldir rather than just syncing
in the kvm bits from that kerneldir and then building modules against
the running kernel.

The reason I'm digging is that I'm seeing 64-bit migration failing on
maint/2.6.29 kvm modules, but not on upstream kvm kernel bits and I
wanted to bisect to find where 64-bit migration is fixed so I can
suggest what to pull into maint/2.6.29.


-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh@us.ibm.com

Re: kvm-kmod.git

[Avi Kivity]

Ryan Harper wrote:
>>> I also wonder what happens if one tries to build on
>>> a machine with kvm built into kernel. Ideally one would get
>>> a clear error message.
>>>  
>>>       
>> kvm-kmod is really designed for those running on pre-kvm distro kernels, 
>> and for those testing newer kvm versions on distro kernels.  If you can 
>> compile your own kernel, download kvm.git and run that.
>>     
>
> So no way of having kvm-kmod sync in kvm.git bits and still build
> against the current running kernel?
>   

We must be miscommunicating, what you describe is kvm-kmod.git's sole 
purpose in life.

> I wanted to test out 2.6.29-maint kernel modules and in
> kvm-userspace/kernel, I could checkout maint/2.6.29 in kvm.git and then
> make LINUX= sync.  I couldn't quite figure out how to do that with
> kvm-kmod since when I do a ./configure --kerneldir -- it's building
> modules *for* whatever kernel is at kerneldir rather than just syncing
> in the kvm bits from that kerneldir and then building modules against
> the running kernel.
>   

'make sync' will copy the kvm bits from the linux-2.6 directory, or 
$(LINUX) if you specify that to make.

So:
  LINUX= is for the kvm sources (further controlled by whatever branch 
is checked out)
  --kerneldir= is for the host kernel

> The reason I'm digging is that I'm seeing 64-bit migration failing on
> maint/2.6.29 kvm modules, but not on upstream kvm kernel bits and I
> wanted to bisect to find where 64-bit migration is fixed so I can
> suggest what to pull into maint/2.6.29.
>   

Thanks, that's helpful.  How does it fail?  maybe I can supply an 
educated guess.

-- 
error compiling committee.c: too many arguments to function

Re: kvm-kmod.git

[Ryan Harper]

* Avi Kivity <avi@redhat.com> [2009-06-01 12:04]:
> Ryan Harper wrote:
> >>>I also wonder what happens if one tries to build on
> >>>a machine with kvm built into kernel. Ideally one would get
> >>>a clear error message.
> >>> 
> >>>      
> >>kvm-kmod is really designed for those running on pre-kvm distro kernels, 
> >>and for those testing newer kvm versions on distro kernels.  If you can 
> >>compile your own kernel, download kvm.git and run that.
> >>    
> >
> >So no way of having kvm-kmod sync in kvm.git bits and still build
> >against the current running kernel?
> >  
> 
> We must be miscommunicating, what you describe is kvm-kmod.git's sole 
> purpose in life.
> 
> >I wanted to test out 2.6.29-maint kernel modules and in
> >kvm-userspace/kernel, I could checkout maint/2.6.29 in kvm.git and then
> >make LINUX= sync.  I couldn't quite figure out how to do that with
> >kvm-kmod since when I do a ./configure --kerneldir -- it's building
> >modules *for* whatever kernel is at kerneldir rather than just syncing
> >in the kvm bits from that kerneldir and then building modules against
> >the running kernel.
> >  
> 
> 'make sync' will copy the kvm bits from the linux-2.6 directory, or 
> $(LINUX) if you specify that to make.
> 
> So:
>  LINUX= is for the kvm sources (further controlled by whatever branch 
> is checked out)
>  --kerneldir= is for the host kernel

Ah, excellent, I didn't see it documented on the Code page of the wiki
and I blindly assumed that it went away.  Thanks for correction.
> 
> >The reason I'm digging is that I'm seeing 64-bit migration failing on
> >maint/2.6.29 kvm modules, but not on upstream kvm kernel bits and I
> >wanted to bisect to find where 64-bit migration is fixed so I can
> >suggest what to pull into maint/2.6.29.
> >  
> 
> Thanks, that's helpful.  How does it fail?  maybe I can supply an 
> educated guess.

Migration succeeds, but source and target are frozen (though monitor of
guest is still interactive. 

Nothing interesting in host dmesg, and of course no output from either
guest (they seemed locked).  Reproduced this sort of hang for any number
of guests (RHEL4u7/8, SLES10 SP2, SLES11, Win2k3-r2, win2k8, etc.) as
long as they are 64-bit

I think Gleb was working on a irq-chip fix for migration, so I need to
try with -no-kvm-irqchip as well to see if
that helps.

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh@us.ibm.com

Re: kvm-kmod.git

[Ryan Harper]

* Avi Kivity <avi@redhat.com> [2009-06-01 12:04]:
> Ryan Harper wrote:
> >>>I also wonder what happens if one tries to build on
> >>>a machine with kvm built into kernel. Ideally one would get
> >>>a clear error message.
> >>> 
> >>>      
> >>kvm-kmod is really designed for those running on pre-kvm distro kernels, 
> >>and for those testing newer kvm versions on distro kernels.  If you can 
> >>compile your own kernel, download kvm.git and run that.
> >>    
> >
> >So no way of having kvm-kmod sync in kvm.git bits and still build
> >against the current running kernel?
> >  
> 
> We must be miscommunicating, what you describe is kvm-kmod.git's sole 
> purpose in life.
> 
> >I wanted to test out 2.6.29-maint kernel modules and in
> >kvm-userspace/kernel, I could checkout maint/2.6.29 in kvm.git and then
> >make LINUX= sync.  I couldn't quite figure out how to do that with
> >kvm-kmod since when I do a ./configure --kerneldir -- it's building
> >modules *for* whatever kernel is at kerneldir rather than just syncing
> >in the kvm bits from that kerneldir and then building modules against
> >the running kernel.
> >  
> 
> 'make sync' will copy the kvm bits from the linux-2.6 directory, or 
> $(LINUX) if you specify that to make.
> 
> So:
>  LINUX= is for the kvm sources (further controlled by whatever branch 
> is checked out)
>  --kerneldir= is for the host kernel

% cd kvm
% git checkout -f 2.6.29-stable origins/maint/2.6.29
% cd ../kvm-kmod.git
% ./configure
% make LINUX=../kvm sync
./sync -v kvm-devel -l ../kvm
Traceback (most recent call last):
  File "./sync", line 207, in <module>
    source_sync(arch)
  File "./sync", line 200, in source_sync
    hack(T, arch, i)
  File "./sync", line 123, in hack
    _hack(T + '/' + file, arch)
  File "./sync", line 114, in _hack
    data = file(fname).read()
IOError: [Errno 2] No such file or directory: 'source/timer.c'
make: *** [sync] Error 1

kvm.git on branch kvm-85:
% make LINUX=/home/rharper/work/git/kvm sync
./sync -v kvm-devel -l /home/rharper/work/git/kvm
Traceback (most recent call last):
  File "./sync", line 207, in <module>
    source_sync(arch)
  File "./sync", line 200, in source_sync
    hack(T, arch, i)
  File "./sync", line 123, in hack
    _hack(T + '/' + file, arch)
  File "./sync", line 114, in _hack
    data = file(fname).read()
IOError: [Errno 2] No such file or directory: 'source/eventfd.c'
make: *** [sync] Error 1

kvm.git on branch kvm-86:
% make LINUX=/home/rharper/work/git/kvm sync
./sync -v kvm-devel -l /home/rharper/work/git/kvm
Traceback (most recent call last):
  File "./sync", line 207, in <module>
    source_sync(arch)
  File "./sync", line 200, in source_sync
    hack(T, arch, i)
  File "./sync", line 123, in hack
    _hack(T + '/' + file, arch)
  File "./sync", line 114, in _hack
    data = file(fname).read()
IOError: [Errno 2] No such file or directory: 'source/eventfd.c'
make: *** [sync] Error 1


only branch master seems to work with kvm-kmod

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh@us.ibm.com

Re: kvm-kmod.git

[Avi Kivity]

Ryan Harper wrote:
>> So:
>>  LINUX= is for the kvm sources (further controlled by whatever branch 
>> is checked out)
>>  --kerneldir= is for the host kernel
>>     
>
> Ah, excellent, I didn't see it documented on the Code page of the wiki
> and I blindly assumed that it went away.  Thanks for correction.
>   

It actually did go away, but Jan brought it back.

>>> The reason I'm digging is that I'm seeing 64-bit migration failing on
>>> maint/2.6.29 kvm modules, but not on upstream kvm kernel bits and I
>>> wanted to bisect to find where 64-bit migration is fixed so I can
>>> suggest what to pull into maint/2.6.29.
>>>  
>>>       
>> Thanks, that's helpful.  How does it fail?  maybe I can supply an 
>> educated guess.
>>     
>
> Migration succeeds, but source and target are frozen (though monitor of
> guest is still interactive. 
>
> Nothing interesting in host dmesg, and of course no output from either
> guest (they seemed locked).  Reproduced this sort of hang for any number
> of guests (RHEL4u7/8, SLES10 SP2, SLES11, Win2k3-r2, win2k8, etc.) as
> long as they are 64-bit
>   

SMP?  Uniprocessor?

Try 'info registers' on both source and target and compare.  Maybe we 
lose some bit in EFER.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: kvm-kmod.git

[Avi Kivity]

Ryan Harper wrote:
> % cd kvm
> % git checkout -f 2.6.29-stable origins/maint/2.6.29
> % cd ../kvm-kmod.git
> % ./configure
> % make LINUX=../kvm sync
> ./sync -v kvm-devel -l ../kvm
> Traceback (most recent call last):
>   File "./sync", line 207, in <module>
>     source_sync(arch)
>   File "./sync", line 200, in source_sync
>     hack(T, arch, i)
>   File "./sync", line 123, in hack
>     _hack(T + '/' + file, arch)
>   File "./sync", line 114, in _hack
>     data = file(fname).read()
> IOError: [Errno 2] No such file or directory: 'source/timer.c'
> make: *** [sync] Error 1
>
> kvm.git on branch kvm-85:
> % make LINUX=/home/rharper/work/git/kvm sync
> ./sync -v kvm-devel -l /home/rharper/work/git/kvm
> Traceback (most recent call last):
>   File "./sync", line 207, in <module>
>     source_sync(arch)
>   File "./sync", line 200, in source_sync
>     hack(T, arch, i)
>   File "./sync", line 123, in hack
>     _hack(T + '/' + file, arch)
>   File "./sync", line 114, in _hack
>     data = file(fname).read()
> IOError: [Errno 2] No such file or directory: 'source/eventfd.c'
> make: *** [sync] Error 1
>
> kvm.git on branch kvm-86:
> % make LINUX=/home/rharper/work/git/kvm sync
> ./sync -v kvm-devel -l /home/rharper/work/git/kvm
> Traceback (most recent call last):
>   File "./sync", line 207, in <module>
>     source_sync(arch)
>   File "./sync", line 200, in source_sync
>     hack(T, arch, i)
>   File "./sync", line 123, in hack
>     _hack(T + '/' + file, arch)
>   File "./sync", line 114, in _hack
>     data = file(fname).read()
> IOError: [Errno 2] No such file or directory: 'source/eventfd.c'
> make: *** [sync] Error 1
>
>
> only branch master seems to work with kvm-kmod
>
>   

Well there are differences in the source trees, so they need different 
hacking.  There is a branch for 2.6.30 in kvm-kmod.git, but 2.6.29 is 
slightly different and doesn't have a branch.  You can just remove the 
offending files from ./sync, there's a good chance it will work.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: kvm-kmod.git

[Ryan Harper]

* Avi Kivity <avi@redhat.com> [2009-06-01 13:20]:
> Ryan Harper wrote:
> >% cd kvm
> >% git checkout -f 2.6.29-stable origins/maint/2.6.29
> >% cd ../kvm-kmod.git
> >% ./configure
> >% make LINUX=../kvm sync
> >./sync -v kvm-devel -l ../kvm
> >Traceback (most recent call last):
> >  File "./sync", line 207, in <module>
> >    source_sync(arch)
> >  File "./sync", line 200, in source_sync
> >    hack(T, arch, i)
> >  File "./sync", line 123, in hack
> >    _hack(T + '/' + file, arch)
> >  File "./sync", line 114, in _hack
> >    data = file(fname).read()
> >IOError: [Errno 2] No such file or directory: 'source/timer.c'
> >make: *** [sync] Error 1
> >

> >
> >only branch master seems to work with kvm-kmod
> >
> >  
> 
> Well there are differences in the source trees, so they need different 
> hacking.  There is a branch for 2.6.30 in kvm-kmod.git, but 2.6.29 is 
> slightly different and doesn't have a branch.  You can just remove the 
> offending files from ./sync, there's a good chance it will work.

Yeah, updating sync and x86/Kbuild to not include source files/objects
works -- though it would be nice to have something to indicate the
version we synced, right now all modules that are built this way, dmesg
reports:

loaded kvm module (kvm-devel)


-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh@us.ibm.com

Re: kvm-kmod.git

[Avi Kivity]

Ryan Harper wrote:
> though it would be nice to have something to indicate the
> version we synced, right now all modules that are built this way, dmesg
> reports:
>
> loaded kvm module (kvm-devel

I committed something to use 'git describe' when appropriate.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.