kvm-devel — kernel virtual machine development

[kvm-devel] [PATCH] [RESEND] [v2] Make "make sync" in kernel dir work for multiple archs

[Jerone Y. <jy...@us...>]

1 file changed, 37 insertions(+), 21 deletions(-)
kernel/Makefile |   58 +++++++++++++++++++++++++++++++++++--------------------


	- This adapts perviously sent patch to new changes to kernel/Makefile
	- Fixes improper check in conditional

This patch add the ability for make sync in the kernel directory to work for mulitiple architectures and not just x86.

Signed-off-by: Jerone Young <jy...@us...>

diff --git a/kernel/Makefile b/kernel/Makefile
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -1,5 +1,10 @@ include ../config.mak
 include ../config.mak
 
+ARCH_DIR=$(ARCH)
+ifneq '$(filter $(ARCH_DIR), x86_64 i386)' ''
+	ARCH_DIR=x86
+endif
+ 
 KVERREL = $(patsubst /lib/modules/%/build,%,$(KERNELDIR))
 
 DESTDIR=
@@ -18,11 +23,25 @@ _hack = mv $1 $1.orig && \
 	    | sed '/\#include/! s/\blapic\b/l_apic/g' > $1 && rm $1.orig
 
 _unifdef = mv $1 $1.orig && \
-	  unifdef -DCONFIG_X86 $1.orig > $1; \
-          [ $$? -le 1 ] && rm $1.orig
+	unifdef -DCONFIG_$(shell echo $(ARCH_DIR)|tr '[:lower:]' '[:upper:]') $1.orig > $1; \
+	[ $$? -le 1 ] && rm $1.orig
 
 hack = $(call _hack,$T/$(strip $1))
 unifdef = $(call _unifdef,$T/$(strip $1))
+
+UNIFDEF_FILES = include/linux/kvm.h \
+		include/linux/kvm_para.h \
+		include/asm-$(ARCH_DIR)/kvm.h \
+		include/asm-$(ARCH_DIR)/kvm_para.h
+
+ifneq '$(filter $(ARCH_DIR), x86)' ''
+HACK_FILES = kvm_main.c \
+		mmu.c \
+		vmx.c \
+		svm.c \
+		x86.c \
+		irq.h 
+endif
 
 all::
 #	include header priority 1) $LINUX 2) $KERNELDIR 3) include-compat
@@ -39,17 +58,16 @@ header-sync:
 	rm -rf $T
 	rsync -R \
 	     "$(LINUX)"/./include/linux/kvm*.h \
-	     "$(LINUX)"/./include/asm-x86/kvm*.h \
-             $T/
-	mkdir -p include/linux include/asm-x86
-	ln -sf asm-x86 include/asm
-	ln -sf asm-x86 include-compat/asm
+	     "$(LINUX)"/./include/asm-$(ARCH_DIR)/kvm*.h \
+	     $T/
 
-	$(call unifdef, include/linux/kvm.h)
-	$(call unifdef, include/linux/kvm_para.h)
-	$(call unifdef, include/asm-x86/kvm.h)
-	$(call unifdef, include/asm-x86/kvm_para.h)
-	$(call hack, include/linux/kvm.h)
+	mkdir -p include/linux include/asm-$(ARCH_DIR)
+	ln -sf asm-$(ARCH_DIR) include/asm
+	ln -sf asm-$(ARCH_DIR) include-compat/asm
+
+	for i in $(UNIFDEF_FILES); \
+		do $(call unifdef, $$i); done
+
 	for i in $$(find $T -type f -printf '%P '); \
 		do cmp -s $$i $T/$$i || cp $T/$$i $$i; done
 	rm -rf $T
@@ -57,15 +75,13 @@ source-sync:
 source-sync:
 	rm -rf $T
 	rsync --exclude='*.mod.c' -R \
-             "$(LINUX)"/arch/x86/kvm/./*.[ch] \
-             "$(LINUX)"/virt/kvm/./*.[ch] \
-             $T/
-	$(call hack, kvm_main.c)
-	$(call hack, mmu.c)
-	$(call hack, vmx.c)
-	$(call hack, svm.c)
-	$(call hack, x86.c)
-	$(call hack, irq.h)
+	     "$(LINUX)"/arch/$(ARCH_DIR)/kvm/./*.[ch] \
+	     "$(LINUX)"/virt/kvm/./*.[ch] \
+	     $T/
+
+	for i in $(HACK_FILES); \
+		do $(call hack, $$i); done
+
 	for i in $$(find $T -type f -printf '%P '); \
 		do cmp -s $$i $T/$$i || cp $T/$$i $$i; done
 	rm -rf $T

Re: [kvm-devel] [PATCH] [RESEND] Make "make sync" in kernel dir work for multiple archs

[Jerone Y. <jy...@us...>]

On Wed, 2008-04-23 at 18:02 -0500, Anthony Liguori wrote:
> > diff --git a/kernel/Makefile b/kernel/Makefile
> > --- a/kernel/Makefile
> > +++ b/kernel/Makefile
> > @@ -1,5 +1,10 @@ include ../config.mak
> >  include ../config.mak
> >  
> > +ARCH_DIR=$(ARCH)
> > +ifneq '$(filter $(ARCH_DIR), x86_64 i386)' ''
> > +	ARCH_DIR=x86
> > +endif
> > +
> >   
> 
> This sets ARCH_DIR to x86

yeap.

> 
> >  KVERREL = $(patsubst /lib/modules/%/build,%,$(KERNELDIR))
> >  
> >  DESTDIR=
> > @@ -18,11 +23,25 @@ _hack = mv $1 $1.orig && \
> >  	    | sed '/\#include/! s/\blapic\b/l_apic/g' > $1 && rm $1.orig
> >  
> >  _unifdef = mv $1 $1.orig && \
> > -	  unifdef -DCONFIG_X86 $1.orig > $1; \
> > +	unifdef -DCONFIG_$(shell echo $(ARCH_DIR)|tr '[:lower:]' '[:upper:]') $1.orig > $1; \
> >            [ $$? -le 1 ] && rm $1.orig
> >  
> >  hack = $(call _hack,$T/$(strip $1))
> >  unifdef = $(call _unifdef,$T/$(strip $1))
> > +
> > +ifneq '$(filter $(ARCH_DIR), x86_64 i386)' ''
> >   

Doh! Yeap again. This was caused when things where need to change in a
respin of the last patch. I just didn't notice it.

I'll change it and resend ... again.
> 
> And I'm not quite sure what this is supposed to do but it doesn't look 
> right.  ARCH_DIR is going to equal 'x86' so this is going to break 
> things on x86 sinc ethe filter will return an empty string.
> 
> Regards,
> 
> Anthony Liguori
> 
> > +UNIFDEF_FILES = include/linux/kvm.h \
> > +		include/linux/kvm_para.h \
> > +		include/asm-$(ARCH_DIR)/kvm.h \
> > +		include/asm-x86/kvm_para.h
> > +
> > +HACK_FILES = kvm_main.c \
> > +		mmu.c \
> > +		vmx.c \
> > +		svm.c \
> > +		x86.c \
> > +		irq.h 
> > +endif
> >  
> >  all::
> >  #	include header priority 1) $LINUX 2) $KERNELDIR 3) include-compat
> > @@ -39,17 +58,16 @@ header-sync:
> >  	rm -rf $T
> >  	rsync -R \
> >  	     "$(LINUX)"/./include/linux/kvm*.h \
> > -	     "$(LINUX)"/./include/asm-x86/kvm*.h \
> > -             $T/
> > -	mkdir -p include/linux include/asm-x86
> > -	ln -sf asm-x86 include/asm
> > -	ln -sf asm-x86 include-compat/asm
> > +	     "$(LINUX)"/./include/asm-$(ARCH_DIR)/kvm*.h \
> > +	     $T/
> >  
> > -	$(call unifdef, include/linux/kvm.h)
> > -	$(call unifdef, include/linux/kvm_para.h)
> > -	$(call unifdef, include/asm-x86/kvm.h)
> > -	$(call unifdef, include/asm-x86/kvm_para.h)
> > -	$(call hack, include/linux/kvm.h)
> > +	mkdir -p include/linux include/asm-$(ARCH_DIR)
> > +	ln -s asm-$(ARCH_DIR) include/asm
> > +	ln -sf asm-$(ARCH_DIR) include-compat/asm
> > +
> > +	for i in $(UNIFDEF_FILES); \
> > +		do $(call unifdef, $$i); done
> > +
> >  	for i in $$(find $T -type f -printf '%P '); \
> >  		do cmp -s $$i $T/$$i || cp $T/$$i $$i; done
> >  	rm -rf $T
> > @@ -57,15 +75,13 @@ source-sync:
> >  source-sync:
> >  	rm -rf $T
> >  	rsync --exclude='*.mod.c' -R \
> > -             "$(LINUX)"/arch/x86/kvm/./*.[ch] \
> > -             "$(LINUX)"/virt/kvm/./*.[ch] \
> > -             $T/
> > -	$(call hack, kvm_main.c)
> > -	$(call hack, mmu.c)
> > -	$(call hack, vmx.c)
> > -	$(call hack, svm.c)
> > -	$(call hack, x86.c)
> > -	$(call hack, irq.h)
> > +	     "$(LINUX)"/arch/$(ARCH_DIR)/kvm/./*.[ch] \
> > +	     "$(LINUX)"/virt/kvm/./*.[ch] \
> > +	     $T/
> > +
> > +	for i in $(HACK_FILES); \
> > +		do $(call hack, $$i); done
> > +
> >  	for i in $$(find $T -type f -printf '%P '); \
> >  		do cmp -s $$i $T/$$i || cp $T/$$i $$i; done
> >  	rm -rf $T
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> > Don't miss this year's exciting event. There's still time to save $100. 
> > Use priority code J8TL2D2. 
> > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> > _______________________________________________
> > kvm-devel mailing list
> > kvm...@li...
> > https://lists.sourceforge.net/lists/listinfo/kvm-devel
> >   
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save $100. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> kvm-devel mailing list
> kvm...@li...
> https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] Error: KVM_TRACE_PAUSE, KVM_TRACE_ENABLE, KVM_TRACE_DISABLE undeclared

[Peter T. <htm...@gm...>]

My current patched kernel is 2.6.25-rc9:

CONFIG_HAVE_KVM=y
CONFIG_KVM=m
CONFIG_KVM_INTEL=m
CONFIG_KVM_AMD=m

and then while compiling kvm-66:

/root/download/kvm/kvm-66>./configure --disable-gcc-check
--prefix=/usr/local/kvm --with-patched-kernel

make[1]: Entering directory `/mnt/sdc2/download/kvm/kvm-66/user'
gcc  -m32 -D__i386__ -I /mnt/sdc2/download/linux-2.6_latest/include
-O1 -MMD -MF ./.main.d -g -fomit-frame-pointer -Wall
-fno-stack-protector   -I ../libkvm   -c -o main.o main.c
gcc  -m32 -D__i386__ -I /mnt/sdc2/download/linux-2.6_latest/include
-O1 -MMD -MF ./.iotable.d -g -fomit-frame-pointer -Wall
-fno-stack-protector   -I ../libkvm   -c -o iotable.o iotable.c
gcc  -m32 -D__i386__ -I /mnt/sdc2/download/linux-2.6_latest/include
-O1 -MMD -MF ..d -g -fomit-frame-pointer -Wall  -fno-stack-protector
-I ../libkvm -L ../libkvm -pthread -lrt main.o iotable.o
../libkvm/libkvm.a -o kvmctl
gcc  -m32 -D__i386__ -I /mnt/sdc2/download/linux-2.6_latest/include
-O1 -MMD -MF ./.kvmtrace.d -g -fomit-frame-pointer -Wall
-fno-stack-protector   -I ../libkvm   -c -o kvmtrace.o kvmtrace.c
kvmtrace.c: In function 'handle_sigint':
kvmtrace.c:174: error: 'KVM_TRACE_PAUSE' undeclared (first use in this function)
kvmtrace.c:174: error: (Each undeclared identifier is reported only once
kvmtrace.c:174: error: for each function it appears in.)
kvmtrace.c: In function 'start_trace':
kvmtrace.c:465: error: storage size of 'kuts' isn't known
kvmtrace.c:477: error: 'KVM_TRACE_ENABLE' undeclared (first use in
this function)
kvmtrace.c:465: warning: unused variable 'kuts'
kvmtrace.c: In function 'cleanup_trace':
kvmtrace.c:496: error: 'KVM_TRACE_DISABLE' undeclared (first use in
this function)
make[1]: *** [kvmtrace.o] Error 1
make[1]: Leaving directory `/mnt/sdc2/download/kvm/kvm-66/user'

Any ideas?

-- 
Regards,
Peter Teoh

Re: [kvm-devel] [PATCH/RFC] virtio: export more headers to userspace

[Rusty R. <ru...@ru...>]

On Wednesday 23 April 2008 20:57:00 Christian Borntraeger wrote:
> Rusty,
>
> is there a reason why we dont export the virtio headers for
> 9p, balloon, console, pci, and virtio_ring? kvm uses make sync,
> but I think it is still useful to heave these headers exported
> as they might be useful for other userspace tools.

Applied, thanks.

Cheers,
Rusty.

Re: [kvm-devel] [PATCH] [RESEND] Make "make sync" in kernel dir work for multiple archs

[Anthony L. <an...@co...>]

> diff --git a/kernel/Makefile b/kernel/Makefile
> --- a/kernel/Makefile
> +++ b/kernel/Makefile
> @@ -1,5 +1,10 @@ include ../config.mak
>  include ../config.mak
>  
> +ARCH_DIR=$(ARCH)
> +ifneq '$(filter $(ARCH_DIR), x86_64 i386)' ''
> +	ARCH_DIR=x86
> +endif
> +
>   

This sets ARCH_DIR to x86

>  KVERREL = $(patsubst /lib/modules/%/build,%,$(KERNELDIR))
>  
>  DESTDIR=
> @@ -18,11 +23,25 @@ _hack = mv $1 $1.orig && \
>  	    | sed '/\#include/! s/\blapic\b/l_apic/g' > $1 && rm $1.orig
>  
>  _unifdef = mv $1 $1.orig && \
> -	  unifdef -DCONFIG_X86 $1.orig > $1; \
> +	unifdef -DCONFIG_$(shell echo $(ARCH_DIR)|tr '[:lower:]' '[:upper:]') $1.orig > $1; \
>            [ $$? -le 1 ] && rm $1.orig
>  
>  hack = $(call _hack,$T/$(strip $1))
>  unifdef = $(call _unifdef,$T/$(strip $1))
> +
> +ifneq '$(filter $(ARCH_DIR), x86_64 i386)' ''
>   

And I'm not quite sure what this is supposed to do but it doesn't look 
right.  ARCH_DIR is going to equal 'x86' so this is going to break 
things on x86 sinc ethe filter will return an empty string.

Regards,

Anthony Liguori

> +UNIFDEF_FILES = include/linux/kvm.h \
> +		include/linux/kvm_para.h \
> +		include/asm-$(ARCH_DIR)/kvm.h \
> +		include/asm-x86/kvm_para.h
> +
> +HACK_FILES = kvm_main.c \
> +		mmu.c \
> +		vmx.c \
> +		svm.c \
> +		x86.c \
> +		irq.h 
> +endif
>  
>  all::
>  #	include header priority 1) $LINUX 2) $KERNELDIR 3) include-compat
> @@ -39,17 +58,16 @@ header-sync:
>  	rm -rf $T
>  	rsync -R \
>  	     "$(LINUX)"/./include/linux/kvm*.h \
> -	     "$(LINUX)"/./include/asm-x86/kvm*.h \
> -             $T/
> -	mkdir -p include/linux include/asm-x86
> -	ln -sf asm-x86 include/asm
> -	ln -sf asm-x86 include-compat/asm
> +	     "$(LINUX)"/./include/asm-$(ARCH_DIR)/kvm*.h \
> +	     $T/
>  
> -	$(call unifdef, include/linux/kvm.h)
> -	$(call unifdef, include/linux/kvm_para.h)
> -	$(call unifdef, include/asm-x86/kvm.h)
> -	$(call unifdef, include/asm-x86/kvm_para.h)
> -	$(call hack, include/linux/kvm.h)
> +	mkdir -p include/linux include/asm-$(ARCH_DIR)
> +	ln -s asm-$(ARCH_DIR) include/asm
> +	ln -sf asm-$(ARCH_DIR) include-compat/asm
> +
> +	for i in $(UNIFDEF_FILES); \
> +		do $(call unifdef, $$i); done
> +
>  	for i in $$(find $T -type f -printf '%P '); \
>  		do cmp -s $$i $T/$$i || cp $T/$$i $$i; done
>  	rm -rf $T
> @@ -57,15 +75,13 @@ source-sync:
>  source-sync:
>  	rm -rf $T
>  	rsync --exclude='*.mod.c' -R \
> -             "$(LINUX)"/arch/x86/kvm/./*.[ch] \
> -             "$(LINUX)"/virt/kvm/./*.[ch] \
> -             $T/
> -	$(call hack, kvm_main.c)
> -	$(call hack, mmu.c)
> -	$(call hack, vmx.c)
> -	$(call hack, svm.c)
> -	$(call hack, x86.c)
> -	$(call hack, irq.h)
> +	     "$(LINUX)"/arch/$(ARCH_DIR)/kvm/./*.[ch] \
> +	     "$(LINUX)"/virt/kvm/./*.[ch] \
> +	     $T/
> +
> +	for i in $(HACK_FILES); \
> +		do $(call hack, $$i); done
> +
>  	for i in $$(find $T -type f -printf '%P '); \
>  		do cmp -s $$i $T/$$i || cp $T/$$i $$i; done
>  	rm -rf $T
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save $100. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> kvm-devel mailing list
> kvm...@li...
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>   

[kvm-devel] [PATCH] [RESEND] Make "make sync" in kernel dir work for multiple archs

[Jerone Y. <jy...@us...>]

1 file changed, 36 insertions(+), 20 deletions(-)
kernel/Makefile |   56 +++++++++++++++++++++++++++++++++++--------------------


	- This adapts perviously sent patch to new changes to kernel/Makefile

This patch add the ability for make sync in the kernel directory to work for mulitiple architectures and not just x86.

Signed-off-by: Jerone Young <jy...@us...>

diff --git a/kernel/Makefile b/kernel/Makefile
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -1,5 +1,10 @@ include ../config.mak
 include ../config.mak
 
+ARCH_DIR=$(ARCH)
+ifneq '$(filter $(ARCH_DIR), x86_64 i386)' ''
+	ARCH_DIR=x86
+endif
+ 
 KVERREL = $(patsubst /lib/modules/%/build,%,$(KERNELDIR))
 
 DESTDIR=
@@ -18,11 +23,25 @@ _hack = mv $1 $1.orig && \
 	    | sed '/\#include/! s/\blapic\b/l_apic/g' > $1 && rm $1.orig
 
 _unifdef = mv $1 $1.orig && \
-	  unifdef -DCONFIG_X86 $1.orig > $1; \
+	unifdef -DCONFIG_$(shell echo $(ARCH_DIR)|tr '[:lower:]' '[:upper:]') $1.orig > $1; \
           [ $$? -le 1 ] && rm $1.orig
 
 hack = $(call _hack,$T/$(strip $1))
 unifdef = $(call _unifdef,$T/$(strip $1))
+
+ifneq '$(filter $(ARCH_DIR), x86_64 i386)' ''
+UNIFDEF_FILES = include/linux/kvm.h \
+		include/linux/kvm_para.h \
+		include/asm-$(ARCH_DIR)/kvm.h \
+		include/asm-x86/kvm_para.h
+
+HACK_FILES = kvm_main.c \
+		mmu.c \
+		vmx.c \
+		svm.c \
+		x86.c \
+		irq.h 
+endif
 
 all::
 #	include header priority 1) $LINUX 2) $KERNELDIR 3) include-compat
@@ -39,17 +58,16 @@ header-sync:
 	rm -rf $T
 	rsync -R \
 	     "$(LINUX)"/./include/linux/kvm*.h \
-	     "$(LINUX)"/./include/asm-x86/kvm*.h \
-             $T/
-	mkdir -p include/linux include/asm-x86
-	ln -sf asm-x86 include/asm
-	ln -sf asm-x86 include-compat/asm
+	     "$(LINUX)"/./include/asm-$(ARCH_DIR)/kvm*.h \
+	     $T/
 
-	$(call unifdef, include/linux/kvm.h)
-	$(call unifdef, include/linux/kvm_para.h)
-	$(call unifdef, include/asm-x86/kvm.h)
-	$(call unifdef, include/asm-x86/kvm_para.h)
-	$(call hack, include/linux/kvm.h)
+	mkdir -p include/linux include/asm-$(ARCH_DIR)
+	ln -s asm-$(ARCH_DIR) include/asm
+	ln -sf asm-$(ARCH_DIR) include-compat/asm
+
+	for i in $(UNIFDEF_FILES); \
+		do $(call unifdef, $$i); done
+
 	for i in $$(find $T -type f -printf '%P '); \
 		do cmp -s $$i $T/$$i || cp $T/$$i $$i; done
 	rm -rf $T
@@ -57,15 +75,13 @@ source-sync:
 source-sync:
 	rm -rf $T
 	rsync --exclude='*.mod.c' -R \
-             "$(LINUX)"/arch/x86/kvm/./*.[ch] \
-             "$(LINUX)"/virt/kvm/./*.[ch] \
-             $T/
-	$(call hack, kvm_main.c)
-	$(call hack, mmu.c)
-	$(call hack, vmx.c)
-	$(call hack, svm.c)
-	$(call hack, x86.c)
-	$(call hack, irq.h)
+	     "$(LINUX)"/arch/$(ARCH_DIR)/kvm/./*.[ch] \
+	     "$(LINUX)"/virt/kvm/./*.[ch] \
+	     $T/
+
+	for i in $(HACK_FILES); \
+		do $(call hack, $$i); done
+
 	for i in $$(find $T -type f -printf '%P '); \
 		do cmp -s $$i $T/$$i || cp $T/$$i $$i; done
 	rm -rf $T

[kvm-devel] [PATCH] Don't quit IO thread before all lvcpus stopped

[Dor L. <dor...@qu...>]

while investigating the revert of "fix sci irq set when acpi timer" I
discovered the reason. Please also re-revert the original patch.
Thanks,
Dor

-------------
[PATCH] Don't quit IO thread before all lvcpus stopped

Call pause_all_threads() before exiting the i/o thread
main loop.
This scenario happened on system_powerdown request:
The vcpu eventually makes pm_ioport_writew (soft power off)
access that calls qemu_system_shutdown_request.
It causes the i/o thread to exit although the vcpu did not
exit yet.

One of the symptoms is that vcpu may trigger timers thus
causing a segfault since the i/o thread stopped the timer.
[This is what happened on the sci irq timer, now there is no
need to revert it[

Signed-off-by: Dor Laor <dor...@qu...>
---
 qemu/qemu-kvm.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
index 50589a7..78127de 100644
--- a/qemu/qemu-kvm.c
+++ b/qemu/qemu-kvm.c
@@ -452,7 +452,9 @@ int kvm_main_loop(void)
         pthread_mutex_unlock(&qemu_mutex);
     }
 
+    pause_all_threads();
     pthread_mutex_unlock(&qemu_mutex);
+
     return 0;
 }
 
-- 
1.5.4.1

Re: [kvm-devel] [PATCH 01 of 12] Core of mmu notifiers

[Andrea A. <an...@qu...>]

On Wed, Apr 23, 2008 at 06:37:13PM +0200, Andrea Arcangeli wrote:
> I'm afraid if you don't want to worst-case unregister with ->release
> you need to have a better idea than my mm_lock and personally I can't
> see any other way than mm_lock to ensure not to miss range_begin...

But wait, mmu_notifier_register absolutely requires mm_lock to ensure
that when the kvm->arch.mmu_notifier_invalidate_range_count is zero
(large variable name, it'll get shorter but this is to explain),
really no cpu is in the middle of range_begin/end critical
section. That's why we've to take all the mm locks.

But we cannot care less if we unregister in the middle, unregister
only needs to be sure that no cpu could possibly still using the ram
of the notifier allocated by the driver before returning. So I'll
implement unregister in O(1) and without ram allocations using srcu
and that'll fix all issues with unregister. It'll return "void" to
make it crystal clear it can't fail. It turns out unregister will make
life easier to kvm as well, mostly to simplify the teardown of the
/dev/kvm closure. Given this can be a considered a bugfix to
mmu_notifier_unregister I'll apply it to 1/N and I'll release a new
mmu-notifier-core patch for you to review before I resend to Andrew
before Saturday. Thanks!

Re: [kvm-devel] Solution: Problems with MAC address with e1000 on Windows 2003

[Alberto T. <al...@by...>]

On Wednesday 23 April 2008 01:09:25 pm Michael Lilie (mlilie) wrote:
> Fedora8, Windows 2008 see the MAC address correctly with an e1000
> interface.
>
> But in Windows 2003 with e1000, the last four bytes of the MAC
> address are always FF:FF:FF:FF.
> The first two bytes can be either what I set or FF:FF (and then it
> doesn't pass traffic),
> and that can change on each reboot of the guest.
> info network always shows the MAC address I set.

The solution is to download and install the PRO/1000 MT drivers from 
Intel.  Once the new drivers are installed, shut down the VM and start 
it up again.  That will clear any FF's left on the mac and bring up the 
correct mac address.

Thanks to Michael Lilie and David Mair for helping me verify this 
problem and find the solution.

-- 
Alberto Treviño
al...@by...

Re: [kvm-devel] Stupid Newbee Questions...

[Avi K. <av...@qu...>]

Stuart Sheldon wrote:
> Thanks to both of you for answering my questions. And thank you Avi for
> fixing the bug. I did not report it because of some of the conversation
> I saw in the mailing list regarding that feature, and thought it might
> have been removed.

If you see us removing a feature you need, let us know.  We might 
reconsider it.

It's better to waste our time by asking "stupid newbee questions" than 
wasting our time (and other users' time) by not reporting bugs, or 
letting us remove useful features.

[Having said all this lofty stuff, our bug counts are piling up, with no 
light at the end of the tunnel...]

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

Re: [kvm-devel] [PATCH 04 of 12] Moves all mmu notifier methods outside the PT lock (first and not last

[Avi K. <av...@qu...>]

Robin Holt wrote:
>> an hurry like we are, we can't progress without this. Infact we can
>>     
>
> SGI is under an equally strict timeline.  We really needed the sleeping
> version into 2.6.26.  We may still be able to get this accepted by
> vendor distros if we make 2.6.27.
>   

The difference is that the non-sleeping variant can be shown not to 
affect stability or performance, even if configed in, as long as its not 
used.  The sleeping variant will raise performance and stability concerns.

I have zero objections to sleeping mmu notifiers; I only object to tying 
the schedules of the two together.

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

Re: [kvm-devel] Ubuntu Gutsy host / XP guest / -smp 2

[Avi K. <av...@qu...>]

David Abrahams wrote:
>>>> Unless you have a recent Intel processor, the combination of SMP and
>>>> Windows XP will give noticeably lower performance.  I recommend sticking
>>>> with uniprocessor in such cases.
>>>>     
>>>>         
>>> I have a Core Duo; isn't that recent enough?
>>>   
>>>       
>> No, this feature is present only on some of the Core 2s, IIRC.
>>     
>
> Huh.  What is the feature called

FlexPriority.

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

Re: [kvm-devel] [PATCH] Make virtio devices multi-function

[Marcelo T. <mto...@re...>]

> > It sounds reasonable to expect so.  ACPI has objects for devices, not 
> > functions (IIRC).
> 
> So what I dislike about multifunction devices is the fact that a single
> slot shares an IRQ, and that special code is required in the QEMU
> drivers (virtio guest capability might not always be present).

Actually this is not true. It is possible to have separate IRQ's for
different devices residing in the same slot, changes are required to the
ACPI tables though.

> I don't see any need for using them if we can extend PCI slots...
> 
> > Maybe require explicit device/function assignment on the command line?  
> > It will be managed anyway.
> 
> ACPI does support hotplugging of individual functions inside slots,
> not sure how well does Linux (and other OSes) support that.. should be
> transparent though.

Re: [kvm-devel] [PATCH 04 of 12] Moves all mmu notifier methods outside the PT lock (first and not last

[Robin H. <ho...@sg...>]

On Wed, Apr 23, 2008 at 06:15:45PM +0200, Andrea Arcangeli wrote:
> Once I get confirmation that everyone is ok with #v13 I'll push a #v14
> before Saturday with that cosmetical error cleaned up and
> mmu_notifier_unregister moved at the end (XPMEM will have unregister
> don't worry). I expect the 1/13 of #v14 to go in -mm and then 2.6.26.

I think GRU needs _unregister as well.

Thanks,
Robin

Re: [kvm-devel] Stupid Newbee Questions...

[Stuart S. <st...@ac...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks to both of you for answering my questions. And thank you Avi for
fixing the bug. I did not report it because of some of the conversation
I saw in the mailing list regarding that feature, and thought it might
have been removed.

Thanks again...

Stu


Avi Kivity wrote:
> Avi Kivity wrote:
>> Stuart Sheldon wrote:
>>> 2) When I started writing the management scripts to start and stop the
>>> guests from the command line, I was using KVM-63 which allowed me to
>>> send a "system_powerdown" to the console, this would send a PWR to the
>>> guest's acpid that would bring the guest down gracefully. This stopped
>>> working in kvm-64 and is still not working in kvm-66. Is there a better
>>> way to do this? How can the host bring down a guest without messing with
>>> it's open programs?
>>>   
>>
>> This is not a question, it's a bug report.  It's a clear regression
>> that needs to be fixed, not worked around.
>>
>> Please send timely reports of such issues when you encounter them.
>>
> 
> This was caused by
> 
> commit 6bb0805aeabd5c6ef5408f57c7da5ca6385dd0f5
> Author: Dor Laor <dor...@qu...>
> Date:   Thu Mar 13 00:11:41 2008 +0200
> 
>    kvm: qemu: fix sci irq set when acpi timer about to wrap
> 
>    The acpi timer should generate sci irq when enabled and
>    when bit 23 of the timer counter toogles.
> 
>    Fixes time reading by the performance counter api of windows guest.
> 
> 
> I'm reverting it for kvm-68.
> 
> 

- --
Well I've always had a deep respect, And I mean that most sincerely.
The band is just fantastic, that is really what I think.
Oh by the way, which one's Pink?
               -- Pink Floyd - "Have a Cigar Lyrics"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFID4yuK69Y+xPZrWYRAkCIAJwIPLjXQHYZUGq6MLYtRy4cwpQ+IQCdGgBD
DdUGj2ibk2xoAenyHAEn2lY=
=fZVh
-----END PGP SIGNATURE-----

Re: [kvm-devel] Ubuntu Gutsy host / XP guest / -smp 2

[David A. <da...@bo...>]

Avi Kivity wrote:
> David Abrahams wrote:
>>>>         
>>> Versions of kvm producing this sort of output are common in
>>> archaeological digs.  Please try a more recent release.
>>>     
>>
>> Well, I'll try Hardy Heron soon enough, I suppose.  It's due out in 2
>> weeks.
>>
>> I'm sure you understand that most people can't afford to rebuild all
>> their important software so that it stays on the bleeding edge.  Have
>> you considered getting more recent versions of kvm into the updates or
>> backports repositories of major distros?  I'm not really sure how much
>> influence you can have over such things; I'm just asking.
> 
> That's up to the distro maintainers, or concerned users (who may either
> volunteer work or apply pressure).

Well Hardy is due out, like, tomorrow or something.  Its kvm seems to be
much newer.

>>>>> What HAL do you see in device manager?
>>>>>             
>>>> "Standard PC"
>>>>
>>>>         
>>> This HAL does not support SMP.  You need the "ACPI Multiprocessor PC"
>>> HAL or some such.
>>>     
>>
>> And how would I get that HAL set up?
>>
>>   
> 
> Follow http://kvm.qumranet.com/kvmwiki/Windows_ACPI_Workaround,
> substituting your desired HAL for "Standard PC".

Thanks.

>>> Unless you have a recent Intel processor, the combination of SMP and
>>> Windows XP will give noticeably lower performance.  I recommend sticking
>>> with uniprocessor in such cases.
>>>     
>>
>> I have a Core Duo; isn't that recent enough?
>>   
> 
> No, this feature is present only on some of the Core 2s, IIRC.

Huh.  What is the feature called?


-- 
Dave Abrahams
Boost Consulting
http://boost-consulting.com

Re: [kvm-devel] Problems with MAC address with e1000 on Windows 2003

[Michael L. (mlilie) <ml...@ci...>]

I think 00 is pretty much the standard starting byte for MAC addresses.

I've seen the same problem - for KVM 61-65, with a 2.6.23 host kernel.

Fedora8, Windows 2008 see the MAC address correctly with an e1000
interface.

But in Windows 2003 with e1000, the last four bytes of the MAC address
are always FF:FF:FF:FF.
The first two bytes can be either what I set or FF:FF (and then it
doesn't pass traffic),
and that can change on each reboot of the guest.
info network always shows the MAC address I set.

Invocation:
qemu -boot c -m 1000 -vnc :3
-net nic,vlan=0,macaddr=00:16:3E:AE:AE:09,model=e1000
-net tap,vlan=0,ifname=vblade30,script=/tmp/vblade30
-monitor `tty` /vbspace/vb3-disk0

Alexey Eremenko wrote:
> Do not start MAC address with 00: 01: or FF:
> Those are illegal addresses.
> 
> Try 50: or 52: or something....

Re: [kvm-devel] [PATCH 0/2] Batch writes to MMIO

[Laurent V. <Lau...@bu...>]

Le mercredi 23 avril 2008 à 11:48 -0500, Anthony Liguori a écrit :
> Laurent Vivier wrote:
> > Le mercredi 23 avril 2008 à 19:25 +0300, Avi Kivity a écrit :
> >   
> >> Laurent Vivier wrote:
> >>     
> >>> Le mercredi 23 avril 2008 à 10:10 -0500, Anthony Liguori a écrit :
> >>> [...]
> >>>   
> >>>       
> >>>> The ne2k is pretty mmio heavy.  You should be able to observe a boost 
> >>>> with something like iperf (guest=>host) I would think if this is a real 
> >>>> savings.
> >>>>     
> >>>>         
> >>> I like your advices :-D
> >>>
> >>> I use iperf with e1000 emulation and a slightly modified patch (to
> >>> detect MMIO write in a loop), server is on the host, client on the
> >>> guest, with default values.
> >>>
> >>> RESULT WITHOUT BATCHING:
> >>>
> >>> [  4]  0.0-10.0 sec    235 MBytes    197 Mbits/sec
> >>> [  5]  0.0-10.0 sec    194 MBytes    163 Mbits/sec
> >>> [  4]  0.0-10.0 sec    185 MBytes    155 Mbits/sec
> >>> [  5]  0.0-10.0 sec    227 MBytes    190 Mbits/sec
> >>> [  4]  0.0-10.0 sec    196 MBytes    164 Mbits/sec
> >>> [  5]  0.0-10.0 sec    194 MBytes    163 Mbits/sec
> >>> [  4]  0.0-10.0 sec    184 MBytes    154 Mbits/sec
> >>>
> >>> RESULT WITH BATCHING:
> >>>
> >>> ------------------------------------------------------------
> >>> Server listening on TCP port 5001
> >>> TCP window size: 85.3 KByte (default)
> >>> ------------------------------------------------------------
> >>> [  4]  0.0-10.0 sec    357 MBytes    299 Mbits/sec
> >>> [  5]  0.0-10.1 sec    418 MBytes    347 Mbits/sec
> >>> [  4]  0.0-10.0 sec    408 MBytes    342 Mbits/sec
> >>> [  5]  0.0-10.0 sec    422 MBytes    353 Mbits/sec
> >>> [  4]  0.0-10.1 sec    436 MBytes    362 Mbits/sec
> >>> [  5]  0.0-10.0 sec    416 MBytes    348 Mbits/sec
> >>> [  4]  0.0-10.0 sec    431 MBytes    361 Mbits/sec
> >>>
> >>> Well, it's nice ?
> >>>   
> >>>       
> >> It's too good to be true.
> >>
> >> I think we're seeing two bugs cancel each other out, resulting in a 
> >> performance gain.  Linux doesn't know how to queue outgoing packets, so 
> >> it bangs on the mmio that starts the transmit after every packet.  mmio 
> >> batching doesn't know that this mmio register is critical for latency, 
> >> so it queues it up.  The result is that you you get not just mmio 
> >> batching, but also packet batching!  Which dramatically improves 
> >> performace at the expense of latency.
> >>     
> >
> > How can I check that ? How can I measure latency ?
> >   
> 
> ping (from guest to host)

I have 40 ms instead of 0.09 ms, so Avi you are right.

Laurent
-- 
------------- Lau...@bu... ---------------
"The best way to predict the future is to invent it."
- Alan Kay

Re: [kvm-devel] Problems with MAC address with e1000 on Windows 2003

[Alberto T. <al...@by...>]

On Wednesday 23 April 2008 01:05:50 am Alexey Eremenko wrote:
> Do not start MAC address with 00: 01: or FF:
> Those are illegal addresses.
>
> Try 50: or 52: or something....

Thanks for the tip.  I tried those but the same problem persisted.  As I 
played around with several MAC addresses (even trying to set several 
Intel OUI's and the OUI's of several Dell servers I have with e1000 
cards and the problem didn't go away.  However, I noticed the the 
problems are with the last 4 bytes of the MAC address.  The first 2 are 
always what I set them to, while the last 6 are always FF:FF:FF:FF.  I 
don't know if the problem lies in the Windows driver looking for a 
specific third byte in the MAC (still part of the OUI), or with the way 
Windows extracts the MAC address out of the emulated hardware.  It's 
odd that Linux doesn't suffer the same problem, however.

Just to cure my ignorance, I know why 01: and FF: are wrong (broadcast 
and multicast).  However, why is 00 wrong?  All nic's I have start with 
00 and the current list of OUI's from IEEE shows that 00:Fx is unused 
(hence my choice of 00:FF).  Is there a specific OUI we should be using 
for Qemu/KVM?

-- 
Alberto Treviño
al...@by...

Re: [kvm-devel] [PATCH 01 of 12] Core of mmu notifiers

[Christoph L. <cla...@sg...>]

On Wed, 23 Apr 2008, Andrea Arcangeli wrote:

> Yes, there's really no risk of races in this area after introducing
> mm_lock, any place that mangles over ptes and doesn't hold any of the
> three locks is buggy anyway. I appreciate the audit work (I also did
> it and couldn't find bugs but the more eyes the better).

I guess I would need to merge some patches together somehow to be able 
to review them properly like I did before <sigh>. I have not reviewed the 
latest code completely.

Re: [kvm-devel] [PATCH 01 of 12] Core of mmu notifiers

[Andrea A. <an...@qu...>]

On Wed, Apr 23, 2008 at 11:27:21AM -0700, Christoph Lameter wrote:
> There is a potential issue in move_ptes where you call 
> invalidate_range_end after dropping i_mmap_sem whereas my patches did the 
> opposite. Mmap_sem saves you there?

Yes, there's really no risk of races in this area after introducing
mm_lock, any place that mangles over ptes and doesn't hold any of the
three locks is buggy anyway. I appreciate the audit work (I also did
it and couldn't find bugs but the more eyes the better).

Re: [kvm-devel] [PATCH 01 of 12] Core of mmu notifiers

[Andrea A. <an...@qu...>]

On Wed, Apr 23, 2008 at 11:21:49AM -0700, Christoph Lameter wrote:
> No I really want you to do this. I have no interest in a takeover in the 

Ok if you want me to do this, I definitely prefer the core to go in
now. It's so much easier to concentrate on two problems at different
times then to attack both problems at the same time given they're
mostly completely orthogonal problems. Given we already solved one
problem, I'd like to close it before concentrating on the second
problem. I already told you it was my interest to support XPMEM
too. For example it was me to notice we couldn't possibly remove
can_sleep parameter from invalidate_range without altering the locking
as vmas were unstable outside of one of the three core vm locks. That
finding resulted in much bigger patches than we hoped (like Andrew
previously sort of predicted) and you did all great work to develop
those. From my part, once the converged part is in, it'll be a lot
easier to fully concentrate on the rest. My main focus right now is to
produce a mmu-notifier-core that is entirely bug free for .26.

Re: [kvm-devel] [PATCH 01 of 12] Core of mmu notifiers

[Christoph L. <cla...@sg...>]

On Wed, 23 Apr 2008, Andrea Arcangeli wrote:

> On Wed, Apr 23, 2008 at 11:09:35AM -0700, Christoph Lameter wrote:
> > Why is there still the hlist stuff being used for the mmu notifier list? 
> > And why is this still unsafe?
> 
> What's the problem with hlist, it saves 8 bytes for each mm_struct,
> you should be using it too instead of list.

list heads in mm_struct and in the mmu_notifier struct seemed to 
be more consistent. We have no hash list after all.

> 
> > There are cases in which you do not take the reverse map locks or mmap_sem
> > while traversing the notifier list?
> 
> There aren't.

There is a potential issue in move_ptes where you call 
invalidate_range_end after dropping i_mmap_sem whereas my patches did the 
opposite. Mmap_sem saves you there?

Re: [kvm-devel] [PATCH 01 of 12] Core of mmu notifiers

[Andrea A. <an...@qu...>]

On Wed, Apr 23, 2008 at 11:19:26AM -0700, Christoph Lameter wrote:
> If unregister fails then the driver should not detach from the address
> space immediately but wait until -->release is called. That may be
> a possible solution. It will be rare that the unregister fails.

This is the current idea, exactly. Unless we find a way to replace
mm_lock with something else, I don't see a way to make
mmu_notifier_unregister reliable without wasting ram.

[kvm-devel] [PATCH]: Fix MSR_K7_EVNTSEL{0,3} for SVM

[Chris L. <cla...@re...>]

Avi, Joerg,
     While trying to boot a RHEL-4 guest on latest KVM tip on an AMD machine, I
found that the guest would consistently crash when trying to setup the NMI
watchdog.  I traced it down to the following commit:

51ef1ac7b23ee32bfcc61c229d634fdc1c68b38a

It seems that in that commit, the K7_EVNTSEL MSR's were set to fail if the data
!= 0.  That test is actually fine, the problem is how the code around it is
generated.  That is, we are only supposed to go to unhandled if data != 0; but
for some reason, we are *always* going to unhandled, even when the data == 0.
That causes RHEL-4 kernel to crash.  If I rearrange the code to look like this:

	case MSR_K7_EVNTSEL0:
	case MSR_K7_EVNTSEL1:
	case MSR_K7_EVNTSEL2:
	case MSR_K7_EVNTSEL3:

		if (data != 0)
			return kvm_set_msr_common(vcpu, ecx, data);
		
	default:
		return kvm_set_msr_common(vcpu, ecx, data);
	}

Then everything works again.  A patch that does just this is attached.  It might
be slightly nicer to say "if (data == 0) return 0" and then just fall through to
the default case, but I don't much care either way.

Signed-off-by: Chris Lalancette <cla...@re...>