Menu
▾
▴
kvm-devel — kernel virtual machine development
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(33) |
Nov
(325) |
Dec
(320) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(484) |
Feb
(438) |
Mar
(407) |
Apr
(713) |
May
(831) |
Jun
(806) |
Jul
(1023) |
Aug
(1184) |
Sep
(1118) |
Oct
(1461) |
Nov
(1224) |
Dec
(1042) |
| 2008 |
Jan
(1449) |
Feb
(1110) |
Mar
(1428) |
Apr
(1643) |
May
(682) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Avi K. <av...@qu...> - 2008-04-14 11:47:19
|
Christoph Hellwig wrote: > On Mon, Apr 14, 2008 at 03:37:04AM -0500, Jerone Young wrote: > >> 2 files changed, 25 insertions(+), 4 deletions(-) >> Makefile | 21 ++++++++++++++++++++- >> configure | 8 +++++--- >> >> >> This patch adds ability for kvm-userspace build system to sync needed kernel headers locally without the need of compiled kernel source. >> > > Please just keep a copy of the kernel headers in the userspace tree so > it can be built standalone. > > The tarballs do contain a copy of the kernel headers; the 'make sync' mechanism is for developers to generate the tarballs without keeping the sources duplicated in git. -- error compiling committee.c: too many arguments to function |
|
From: Avi K. <av...@qu...> - 2008-04-14 11:35:49
|
Joerg Roedel wrote: > On Mon, Apr 14, 2008 at 01:29:50PM +0300, Avi Kivity wrote: > >> Joerg Roedel wrote: >> >>> Only the state saved in the VMCB is undefined after an intercepted >>> shutdown event. >>> >> The vmcb stores two types of states, guest state and control >> information. Are both undefined? >> > > Only the guest state is undefined. > > Okay, so we don't need to init_vmcb() there. We can just reset the processor (actually, we should rely on userspace to reset the processor; IIRC shutdown does not reset the processor directly; instead the system board detects the shutdown and converts it to a reset, and we may want to emulate other types of system boards). >>> I am not sure if I understand your second question, what >>> do you mean with "core melting down" vs. guest initiated shutdown? >>> >>> >> IIRC shutdown can occur not only as a result of triple faults, due to >> other internal errors or inconsistent state. Not sure about that >> though. >> > > No, there is no way to to differentiate between a shutdown caused by a > triple fault and other shutdown situations. If the shutdown event is > caused by a too hot processor it is not intercepted. This situation is > handled like a normal cpu shutdown. > Well, that gives you some differentiation (enough for our needs). -- error compiling committee.c: too many arguments to function |
|
From: Joerg R. <joe...@am...> - 2008-04-14 10:52:37
|
On Mon, Apr 14, 2008 at 01:29:50PM +0300, Avi Kivity wrote:
> Joerg Roedel wrote:
> >Only the state saved in the VMCB is undefined after an intercepted
> >shutdown event.
>
> The vmcb stores two types of states, guest state and control
> information. Are both undefined?
Only the guest state is undefined.
>
> >I am not sure if I understand your second question, what
> >do you mean with "core melting down" vs. guest initiated shutdown?
> >
>
> IIRC shutdown can occur not only as a result of triple faults, due to
> other internal errors or inconsistent state. Not sure about that
> though.
No, there is no way to to differentiate between a shutdown caused by a
triple fault and other shutdown situations. If the shutdown event is
caused by a too hot processor it is not intercepted. This situation is
handled like a normal cpu shutdown.
--
| AMD Saxony Limited Liability Company & Co. KG
Operating | Wilschdorfer Landstr. 101, 01109 Dresden, Germany
System | Register Court Dresden: HRA 4896
Research | General Partner authorized to represent:
Center | AMD Saxony LLC (Wilmington, Delaware, US)
| General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy
|
|
From: Nguyen A. Q. <aq...@gm...> - 2008-04-14 10:38:36
|
This patch fixes a wrong calculation in the physical address of extboot (qemu/hw/extboot.c). Looks like a typo. Signed-off-by: Nguyen Anh Quynh <aq...@gm...> |
|
From: Joerg R. <joe...@am...> - 2008-04-14 10:36:01
|
On Mon, Apr 14, 2008 at 12:43:30PM +0300, Avi Kivity wrote:
> Michal Ludvig wrote:
> >Hi all,
> >
> >in short: CentOS 5 guest (32bit) crashes when I run "reboot" in the VM with qemu message:
> >kvm_run: failed entry, reason 65535
> >kvm_run returned -8
> >
> >In dmesg is this message:
> >kvm: 23769: cpu0 kvm_set_msr_common: MSR_IA32_MC0_STATUS 0x0, nop
> >
> >Details:
> >KVM 65
> >Host is openSUSE 10.3 with my own 2.6.24, 64 bit
> >Guest is CentOS 5.1 with 2.6.18-53.1.14.el5, 32 bit
> >GCC 4.2.1 for module, GCC 3.3.3 for qemu
> >CPU "AMD Athlon(tm) 64 X2 Dual Core Processor 5600+"
> >
> >Everything works fine, except that I can't reboot the guest. In VNC it says "md: stopping devices" and then Qemu exits with:
> >kvm_run: failed entry, reason 65535
> >kvm_run returned -8
> >
> >IIRC reboot used to work with kvm-64
> >
>
> I think two bugs are involved:
>
> - the guest invokes the triple-fault shutdown path, so it seems normal reboot doesn't work with iothread. Haven't looked as to why yet.
> - amd shutdown interception clears the vmcb, leaving asid == 0, which is illegal. Adding force_new_asid() fixes this. There are probably
> other issues with clearing the vmcb as well.
>
> Joerg, can you find out if the "vmcb is undefined" applies to the entire vmcb or just the guest saved state? Is there a way to
> differentiate between a guest initiated shutdown due to triple fault and the core melting down?
Only the state saved in the VMCB is undefined after an intercepted
shutdown event. I am not sure if I understand your second question, what
do you mean with "core melting down" vs. guest initiated shutdown?
Joerg
--
| AMD Saxony Limited Liability Company & Co. KG
Operating | Wilschdorfer Landstr. 101, 01109 Dresden, Germany
System | Register Court Dresden: HRA 4896
Research | General Partner authorized to represent:
Center | AMD Saxony LLC (Wilmington, Delaware, US)
| General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy
|
|
From: Avi K. <av...@qu...> - 2008-04-14 10:31:04
|
Joerg Roedel wrote: > On Mon, Apr 14, 2008 at 12:43:30PM +0300, Avi Kivity wrote: > >> Michal Ludvig wrote: >> >>> Hi all, >>> >>> in short: CentOS 5 guest (32bit) crashes when I run "reboot" in the VM with qemu message: >>> kvm_run: failed entry, reason 65535 >>> kvm_run returned -8 >>> >>> In dmesg is this message: >>> kvm: 23769: cpu0 kvm_set_msr_common: MSR_IA32_MC0_STATUS 0x0, nop >>> >>> Details: >>> KVM 65 >>> Host is openSUSE 10.3 with my own 2.6.24, 64 bit >>> Guest is CentOS 5.1 with 2.6.18-53.1.14.el5, 32 bit >>> GCC 4.2.1 for module, GCC 3.3.3 for qemu >>> CPU "AMD Athlon(tm) 64 X2 Dual Core Processor 5600+" >>> >>> Everything works fine, except that I can't reboot the guest. In VNC it says "md: stopping devices" and then Qemu exits with: >>> kvm_run: failed entry, reason 65535 >>> kvm_run returned -8 >>> >>> IIRC reboot used to work with kvm-64 >>> >>> >> I think two bugs are involved: >> >> - the guest invokes the triple-fault shutdown path, so it seems normal reboot doesn't work with iothread. Haven't looked as to why yet. >> - amd shutdown interception clears the vmcb, leaving asid == 0, which is illegal. Adding force_new_asid() fixes this. There are probably >> other issues with clearing the vmcb as well. >> >> Joerg, can you find out if the "vmcb is undefined" applies to the entire vmcb or just the guest saved state? Is there a way to >> differentiate between a guest initiated shutdown due to triple fault and the core melting down? >> > > Only the state saved in the VMCB is undefined after an intercepted > shutdown event. The vmcb stores two types of states, guest state and control information. Are both undefined? > I am not sure if I understand your second question, what > do you mean with "core melting down" vs. guest initiated shutdown? > IIRC shutdown can occur not only as a result of triple faults, due to other internal errors or inconsistent state. Not sure about that though. -- error compiling committee.c: too many arguments to function |
|
From: Avi K. <av...@qu...> - 2008-04-14 09:43:56
|
Michal Ludvig wrote: > Hi all, > > in short: CentOS 5 guest (32bit) crashes when I run "reboot" in the VM > with qemu message: > kvm_run: failed entry, reason 65535 > kvm_run returned -8 > > In dmesg is this message: > kvm: 23769: cpu0 kvm_set_msr_common: MSR_IA32_MC0_STATUS 0x0, nop > > Details: > KVM 65 > Host is openSUSE 10.3 with my own 2.6.24, 64 bit > Guest is CentOS 5.1 with 2.6.18-53.1.14.el5, 32 bit > GCC 4.2.1 for module, GCC 3.3.3 for qemu > CPU "AMD Athlon(tm) 64 X2 Dual Core Processor 5600+" > > Everything works fine, except that I can't reboot the guest. In VNC it > says "md: stopping devices" and then Qemu exits with: > kvm_run: failed entry, reason 65535 > kvm_run returned -8 > > IIRC reboot used to work with kvm-64 > I think two bugs are involved: - the guest invokes the triple-fault shutdown path, so it seems normal reboot doesn't work with iothread. Haven't looked as to why yet. - amd shutdown interception clears the vmcb, leaving asid == 0, which is illegal. Adding force_new_asid() fixes this. There are probably other issues with clearing the vmcb as well. Joerg, can you find out if the "vmcb is undefined" applies to the entire vmcb or just the guest saved state? Is there a way to differentiate between a guest initiated shutdown due to triple fault and the core melting down? I'll commit the fix for the second problem, and look at the first later. -- error compiling committee.c: too many arguments to function |
|
From: 钟文辉 <she...@12...> - 2008-04-14 09:35:03
|
各位老总：您们好！
诚祝：您们在2008年里；有鼠不尽的快乐！鼠不尽的收获！鼠不尽的钞票！
鼠不尽的幸福！鼠不尽的美满生活！愿： 您们阖家欢乐！幸福安康！
我是（深圳市珊湖岛进出口有限公司）的负责人；可以提供：出口报关单，
核销单等等一系列手续；代理：出口报关，商检，境内外运输......等等；还可
以代办：出口欧盟许可证，欧盟产地证；并且还有（广州国际贸易交易会）的摊
位可以转让；有意者请来邮件或来电联系；谢谢合作！
电话：0755-81153047。
传真：0755-81172940。
手机：15817477278。
联系人：钟文辉。
此致：
敬礼！
|
|
From: Globecom E. du F. <ex...@fa...> - 2008-04-14 09:22:13
|
Vous souhaitez développer vos ventes à lexportation ? En Afrique et Moyen Orient ? En Amérique du Sud ? En Asie ? En Europe de lEst ? La confiance, ça se gagne ! Testez gratuitement notre support papier sur lédition de votre choix ! (1/8 de page, hors frais techniques, offre limitée aux 30 premiers nouveaux inscrits, enregistrés dici 10 jours). Qui sommes nous? Editeur du FANE : guide dexportateurs bilingue diffusé dans toute lAfrique, le Moyen Orient, lAmérique du Sud, lAsie et lEurope de lEst Quel est notre objectif? Indiquer aux acheteurs des continents émergeants une liste de fournisseurs souhaitant développer des relations daffaires avec leur pays. Qui peut être présent dans le guide FANE? Toutes entreprises exportatrices ou désirant exporter Qui sont les utilisateurs du guide? Des importateurs, des distributeurs, des prescripteurs et des entreprises ou administrations à la recherche de fournisseurs Quels sont nos atouts? 17 années de diffusion avec une parution annuelle 1 réseau de Représentation Officielle dans les pays de diffusion 1 site Internet www.fane.fr appuyant le support papier avec ses 20 000 consultations mensuelles La promotion du support lors de salons internationaux (Sénégal, Libye, Algérie, Cameroun, Madagascar etc. ) |
|
From: Carsten O. <co...@de...> - 2008-04-14 09:18:22
|
Avi Kivity wrote: > Why? This one does'nt work for us. Our arch defines various reasons why we would not fall asleep but do something else, and we need to check them while in atomic of a lock that other archs don't have before sleeping. See kvm_s390_handle_wait in arch/s390/kvm/interrupt.c. |
|
From: 钟文辉 <she...@12...> - 2008-04-14 08:54:43
|
各位老总：您们好！
诚祝：您们在2008年里；有鼠不尽的快乐！鼠不尽的收获！鼠不尽的钞票！
鼠不尽的幸福！鼠不尽的美满生活！愿： 您们阖家欢乐！幸福安康！
我是（深圳市珊湖岛进出口有限公司）的负责人；可以提供：出口报关单，
核销单等等一系列手续；代理：出口报关，商检，境内外运输......等等；还可
以代办：出口欧盟许可证，欧盟产地证；并且还有（广州国际贸易交易会）的摊
位可以转让；有意者请来邮件或来电联系；谢谢合作！
电话：0755-81153047。
传真：0755-81172940。
手机：15817477278。
联系人：钟文辉。
此致：
敬礼！
|
|
From: Christoph H. <hc...@in...> - 2008-04-14 08:49:58
|
On Mon, Apr 14, 2008 at 03:37:04AM -0500, Jerone Young wrote: > 2 files changed, 25 insertions(+), 4 deletions(-) > Makefile | 21 ++++++++++++++++++++- > configure | 8 +++++--- > > > This patch adds ability for kvm-userspace build system to sync needed kernel headers locally without the need of compiled kernel source. Please just keep a copy of the kernel headers in the userspace tree so it can be built standalone. |
|
From: 钟文辉 <she...@12...> - 2008-04-14 08:49:33
|
各位老总：您们好！
诚祝：您们在2008年里；有鼠不尽的快乐！鼠不尽的收获！鼠不尽的钞票！
鼠不尽的幸福！鼠不尽的美满生活！愿： 您们阖家欢乐！幸福安康！
我是（深圳市珊湖岛进出口有限公司）的负责人；可以提供：出口报关单，
核销单等等一系列手续；代理：出口报关，商检，境内外运输......等等；还可
以代办：出口欧盟许可证，欧盟产地证；并且还有（广州国际贸易交易会）的摊
位可以转让；有意者请来邮件或来电联系；谢谢合作！
电话：0755-81153047。
传真：0755-81172940。
手机：15817477278。
联系人：钟文辉。
此致：
敬礼！
|
|
From: Jerone Y. <jy...@us...> - 2008-04-14 08:38:40
|
5 files changed, 1 insertion(+), 8 deletions(-)
user/Makefile | 1 +
user/config-i386.mak | 1 -
user/config-powerpc.mak | 1 -
user/config-x86_64.mak | 1 -
user/configure | 5 -----
This patch fixes user directory to now include synced headers. It also removes the kerneldir option, as it is no longer needed.
Signed-off-by: Jerone Young <jy...@us...>
diff --git a/user/Makefile b/user/Makefile
--- a/user/Makefile
+++ b/user/Makefile
@@ -28,6 +28,7 @@ CFLAGS += $(call cc-option, -fno-stack-p
CFLAGS += $(call cc-option, -fno-stack-protector, "")
CFLAGS += $(call cc-option, -fno-stack-protector-all, "")
CFLAGS += -I ../libkvm
+CFLAGS += $(INCLUDES_DIR)
LDFLAGS += $(CFLAGS) -L ../libkvm
diff --git a/user/config-i386.mak b/user/config-i386.mak
--- a/user/config-i386.mak
+++ b/user/config-i386.mak
@@ -4,7 +4,6 @@ ldarch = elf32-i386
ldarch = elf32-i386
CFLAGS += -m32
CFLAGS += -D__i386__
-CFLAGS += -I $(KERNELDIR)/include
tests=
diff --git a/user/config-powerpc.mak b/user/config-powerpc.mak
--- a/user/config-powerpc.mak
+++ b/user/config-powerpc.mak
@@ -30,7 +30,6 @@ all: kvmctl $(tests) $(simpletests)
CFLAGS += -m32
CFLAGS += -D__powerpc__
-CFLAGS += -I $(KERNELDIR)/include
CFLAGS += -Wa,-mregnames
$(simpletests): %.bin: %.o
diff --git a/user/config-x86_64.mak b/user/config-x86_64.mak
--- a/user/config-x86_64.mak
+++ b/user/config-x86_64.mak
@@ -4,7 +4,6 @@ ldarch = elf64-x86-64
ldarch = elf64-x86-64
CFLAGS += -m64
CFLAGS += -D__x86_64__
-CFLAGS += -I $(KERNELDIR)/include
tests = $(TEST_DIR)/access.flat $(TEST_DIR)/irq.flat $(TEST_DIR)/sieve.flat \
$(TEST_DIR)/simple.flat $(TEST_DIR)/stringio.flat \
diff --git a/user/configure b/user/configure
--- a/user/configure
+++ b/user/configure
@@ -18,7 +18,6 @@ usage() {
--cc=CC c compiler to use ($cc)
--ld=LD ld linker to use ($ld)
--prefix=PREFIX where to install things ($prefix)
- --kerneldir=DIR kernel build directory for kvm.h ($kerneldir)
EOF
exit 1
}
@@ -33,9 +32,6 @@ while [[ "$1" = -* ]]; do
case "$opt" in
--prefix)
prefix="$arg"
- ;;
- --kerneldir)
- kerneldir="$arg"
;;
--arch)
arch="$arg"
@@ -60,7 +56,6 @@ done
cat <<EOF > config.mak
PREFIX=$prefix
-KERNELDIR=$(readlink -f $kerneldir)
ARCH=$arch
CC=$cross_prefix$cc
LD=$cross_prefix$ld
|
|
From: Jerone Y. <jy...@us...> - 2008-04-14 08:38:36
|
2 files changed, 2 insertions(+), 8 deletions(-)
qemu/Makefile.target | 3 +--
qemu/configure | 7 +------
Now that kvm headers are synced locally, qemu does not need a specific option to find the kernel headers as they can now be specified in the --extra-cflags option.
Signed-off-by: Jerone Young <jy...@us...>
diff --git a/qemu/Makefile.target b/qemu/Makefile.target
--- a/qemu/Makefile.target
+++ b/qemu/Makefile.target
@@ -546,8 +546,7 @@ SOUND_HW += gus.o gusemu_hal.o gusemu_mi
SOUND_HW += gus.o gusemu_hal.o gusemu_mixer.o
endif
-ifdef CONFIG_KVM_KERNEL_INC
-CFLAGS += -I $(CONFIG_KVM_KERNEL_INC)
+ifeq ($(USE_KVM), 1)
LIBS += -lkvm
DEPLIBS += ../libkvm/libkvm.a
endif
diff --git a/qemu/configure b/qemu/configure
--- a/qemu/configure
+++ b/qemu/configure
@@ -102,7 +102,6 @@ kvm="no"
kvm="no"
kvm_cap_pit="no"
profiler="no"
-kernel_path=""
cocoa="no"
check_gfx="yes"
check_gcc="yes"
@@ -305,8 +304,6 @@ for opt do
;;
--enable-profiler) profiler="yes"
;;
- --kernel-path=*) kernel_path="$optarg"
- ;;
--enable-cocoa) cocoa="yes" ; coreaudio="yes" ; sdl="no"
;;
--disable-gfx-check) check_gfx="no"
@@ -418,7 +415,6 @@ echo ""
echo ""
echo "kqemu kernel acceleration support:"
echo " --disable-kqemu disable kqemu support"
-echo " --kernel-path=PATH set the kernel path (configure probes it)"
echo " --disable-kvm disable kernel virtual machine support"
echo ""
echo "Advanced options (experts only):"
@@ -627,7 +623,7 @@ cat > $TMPC <<EOF
#endif
int main(void) { return 0; }
EOF
- if $cc $ARCH_CFLAGS $CFLAGS -I"$kernel_path"/include -o $TMPE ${OS_CFLAGS} $TMPC 2> /dev/null ; then
+ if $cc $ARCH_CFLAGS $CFLAGS -o $TMPE ${OS_CFLAGS} $TMPC 2> /dev/null ; then
kvm_cap_pit="yes"
fi
fi
@@ -1184,7 +1180,6 @@ configure_kvm() {
\( "$cpu" = "i386" -o "$cpu" = "x86_64" -o "$cpu" = "ia64" -o "$cpu" = "powerpc" \); then
echo "#define USE_KVM 1" >> $config_h
echo "USE_KVM=1" >> $config_mak
- echo "CONFIG_KVM_KERNEL_INC=$kernel_path/include" >> $config_mak
if test $kvm_cap_pit = "yes" ; then
echo "USE_KVM_PIT=1" >> $config_mak
fi
|
|
From: Jerone Y. <jy...@us...> - 2008-04-14 08:38:36
|
1 file changed, 3 insertions(+), 3 deletions(-) libkvm/Makefile | 6 +++--- This modifies libfdt makefile to now include from synced header directory. Signed-off-by: Jerone Young <jy...@us...> diff --git a/libkvm/Makefile b/libkvm/Makefile --- a/libkvm/Makefile +++ b/libkvm/Makefile @@ -10,7 +10,7 @@ CFLAGS += $(autodepend-flags) -g -fomit- CFLAGS += $(autodepend-flags) -g -fomit-frame-pointer -Wall CFLAGS += $(call cc-option, -fno-stack-protector, "") CFLAGS += $(call cc-option, -fno-stack-protector-all, "") -CFLAGS += -I $(KERNELDIR)/include +CFLAGS += -I $(INCLUDES_DIR) LDFLAGS += $(CFLAGS) @@ -26,9 +26,9 @@ libkvm.a: libkvm.o $(libkvm-$(ARCH)-objs install: install -D libkvm.h $(DESTDIR)/$(PREFIX)/include/libkvm.h - install -D $(KERNELDIR)/include/linux/kvm.h \ + install -D $(INCLUDES_DIR)/linux/kvm.h \ $(DESTDIR)/$(PREFIX)/include/linux/kvm.h - install -D $(KERNELDIR)/include/linux/kvm_para.h \ + install -D $(INCLUDES_DIR)/linux/kvm_para.h \ $(DESTDIR)/$(PREFIX)/include/linux/kvm_para.h install -D libkvm.a $(DESTDIR)/$(PREFIX)/$(LIBDIR)/libkvm.a |
|
From: Jerone Y. <jy...@us...> - 2008-04-14 08:38:35
|
2 files changed, 25 insertions(+), 4 deletions(-)
Makefile | 21 ++++++++++++++++++++-
configure | 8 +++++---
This patch adds ability for kvm-userspace build system to sync needed kernel headers locally without the need of compiled kernel source.
Signed-off-by: Jerone Young <jy...@us...>
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -7,7 +7,7 @@ rpmrelease = devel
.PHONY: kernel user libkvm qemu bios vgabios extboot clean libfdt
-all: libkvm qemu
+all: sync libkvm qemu
ifneq '$(filter $(ARCH), x86_64 i386 ia64)' ''
all: $(if $(WANT_MODULE), kernel) user
endif
@@ -69,6 +69,24 @@ install:
make -C libkvm DESTDIR="$(DESTDIR)" install
make -C qemu DESTDIR="$(DESTDIR)" install
+
+ASM_DIR=$(ARCH)
+ifneq '$(filter $(ARCH), i386 x86_64)' ''
+ ASM_DIR=x86
+endif
+
+sync:
+ mkdir -p $(INCLUDES_DIR)
+ mkdir -p $(INCLUDES_DIR)/asm-$(ASM_DIR)
+ mkdir -p $(INCLUDES_DIR)/linux
+ cp -f $(KERNELDIR)/include/asm-$(ASM_DIR)/kvm*.h \
+ $(INCLUDES_DIR)/asm-$(ASM_DIR)/
+ cp -f $(KERNELDIR)/include/linux/kvm*.h \
+ $(KERNELDIR)/include/linux/compiler*.h \
+ $(INCLUDES_DIR)/linux
+ ln -sf $(INCLUDES_DIR)/asm-$(ASM_DIR) $(INCLUDES_DIR)/asm
+
+
tmpspec = .tmp.kvm.spec
RPMTOPDIR = $$(pwd)/rpmtop
@@ -99,3 +117,4 @@ clean:
distclean: clean
rm -f config.mak user/config.mak
+ rm -rf $(INCLUDES_DIR)
diff --git a/configure b/configure
--- a/configure
+++ b/configure
@@ -10,6 +10,7 @@ cross_prefix=
cross_prefix=
arch=`uname -m`
target_exec=
+local_kernel_includes_dir=$PWD/includes
usage() {
cat <<-EOF
@@ -108,16 +109,16 @@ fi
fi
#configure user dir
-(cd user; ./configure --prefix="$prefix" --kerneldir="$libkvm_kerneldir" \
+(cd user; ./configure --prefix="$prefix" \
--arch="$arch" \
${cross_prefix:+"--cross-prefix=$cross_prefix"})
#configure qemu
(cd qemu; ./configure --target-list=$target_exec \
--disable-kqemu \
- --extra-cflags="-I $PWD/../libkvm $qemu_cflags" \
+ --extra-cflags="-I $PWD/../libkvm $qemu_cflags \
+ -I $local_kernel_includes_dir" \
--extra-ldflags="-L $PWD/../libkvm $qemu_ldflags" \
- --kernel-path="$libkvm_kerneldir" \
--prefix="$prefix" \
${qemu_cc:+"--cc=$qemu_cc"} \
${cross_prefix:+"--cross-prefix=$cross_prefix"} \
@@ -131,4 +132,5 @@ KERNELDIR=$kerneldir
KERNELDIR=$kerneldir
WANT_MODULE=$want_module
CROSS_COMPILE=$cross_prefix
+INCLUDES_DIR=$local_kernel_includes_dir
EOF
|
|
From: Yunfeng Z. <yun...@in...> - 2008-04-14 08:34:01
|
Hi All, This is today's KVM test result against kvm.git 1c5f974ab7e82d0f3a28cd8fc72088a6e0a4b5fb and kvm-userspace.git f1fbe45cad078d376a04f8d92bef34c3be3f06be. Issue list: ================================================ 1. Fails to save/restore ia32e guests https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1936539&group_id=180599 2. Booting four guests likely fails https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1919354&group_id=180599 3. booting smp windows guests has 30% chance of hang https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1910923&group_id=180599 4. Cannot boot guests with hugetlbfs https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1941302&group_id=180599 Test environment ================================================ Platform Woodcrest CPU 4 Memory size 8G' Details ================================================ IA32-pae: 1. boot guest with 256M memory PASS 2. boot two windows xp guest PASS 3. boot 4 same guest in parallel PASS 4. boot linux and windows guest in parallel PASS 5. boot guest with 1500M memory PASS 6. boot windows 2003 with ACPI enabled PASS 7. boot Windows xp with ACPI enabled PASS 8. boot Windows 2000 without ACPI PASS 9. kernel build on SMP linux guest PASS 10. LTP on SMP linux guest PASS 11. boot base kernel linux PASS 12. save/restore 32-bit HVM guests PASS 13. live migration 32-bit HVM guests PASS 14. boot SMP Windows xp with ACPI enabled PASS 15. boot SMP Windows 2003 with ACPI enabled PASS 16. boot SMP Windows 2000 with ACPI enabled PASS ================================================ IA32e: 1. boot four 32-bit guest in parallel PASS 2. boot four 64-bit guest in parallel PASS 3. boot 4G 64-bit guest PASS 4. boot 4G pae guest PASS 5. boot 32-bit linux and 32 bit windows guest in parallel PASS 6. boot 32-bit guest with 1500M memory PASS 7. boot 64-bit guest with 1500M memory PASS 8. boot 32-bit guest with 256M memory PASS 9. boot 64-bit guest with 256M memory PASS 10. boot two 32-bit windows xp in parallel PASS 11. boot four 32-bit different guest in para PASS 12. save/restore 64-bit linux guests FAIL 13. save/restore 32-bit linux guests PASS 14. boot 32-bit SMP windows 2003 with ACPI enabled PASS 15. boot 32-bit SMP Windows 2000 with ACPI enabled PASS 16. boot 32-bit SMP Windows xp with ACPI enabled PASS 17. boot 32-bit Windows 2000 without ACPI PASS 18. boot 64-bit Windows xp with ACPI enabled PASS 19. boot 32-bit Windows xp without ACPI PASS 20. boot 64-bit UP vista PASS 21. boot 64-bit SMP vista PASS 22. kernel build in 32-bit linux guest OS PASS 23. kernel build in 64-bit linux guest OS PASS 24. LTP on SMP 32-bit linux guest OS PASS 25. LTP on SMP 64-bit linux guest OS PASS 26. boot 64-bit guests with ACPI enabled PASS 27. boot 32-bit x-server PASS 28. boot 64-bit SMP windows XP with ACPI enabled PASS 29. boot 64-bit SMP windows 2003 with ACPI enabled PASS 30. live migration 64bit linux guests PASS 31. live migration 32bit linux guests PASS 32. reboot 32bit windows xp guest PASS 33. reboot 32bit windows xp guest PASS Report Summary on IA32-pae Summary Test Report of Last Session ===================================================================== Total Pass Fail NoResult Crash ===================================================================== control_panel 7 7 0 0 0 Restart 2 2 0 0 0 gtest 15 15 0 0 0 ===================================================================== control_panel 7 7 0 0 0 :KVM_LM_PAE_gPAE 1 1 0 0 0 :KVM_four_sguest_PAE_gPA 1 1 0 0 0 :KVM_256M_guest_PAE_gPAE 1 1 0 0 0 :KVM_linux_win_PAE_gPAE 1 1 0 0 0 :KVM_1500M_guest_PAE_gPA 1 1 0 0 0 :KVM_SR_PAE_gPAE 1 1 0 0 0 :KVM_two_winxp_PAE_gPAE 1 1 0 0 0 Restart 2 2 0 0 0 :GuestPAE_PAE_gPAE 1 1 0 0 0 :BootTo32pae_PAE_gPAE 1 1 0 0 0 gtest 15 15 0 0 0 :ltp_nightly_PAE_gPAE 1 1 0 0 0 :boot_up_acpi_PAE_gPAE 1 1 0 0 0 :reboot_xp_PAE_gPAE 1 1 0 0 0 :boot_up_vista_PAE_gPAE 1 1 0 0 0 :boot_up_acpi_xp_PAE_gPA 1 1 0 0 0 :boot_up_acpi_win2k3_PAE 1 1 0 0 0 :boot_base_kernel_PAE_gP 1 1 0 0 0 :boot_smp_acpi_win2k3_PA 1 1 0 0 0 :boot_smp_acpi_win2k_PAE 1 1 0 0 0 :boot_up_acpi_win2k_PAE_ 1 1 0 0 0 :boot_smp_acpi_xp_PAE_gP 1 1 0 0 0 :boot_up_noacpi_win2k_PA 1 1 0 0 0 :boot_smp_vista_PAE_gPAE 1 1 0 0 0 :bootx_PAE_gPAE 1 1 0 0 0 :kb_nightly_PAE_gPAE 1 1 0 0 0 ===================================================================== Total 24 24 0 0 0 Report Summary on IA32e Summary Test Report of Last Session ===================================================================== Total Pass Fail NoResult Crash ===================================================================== control_panel 15 14 1 0 0 Restart 3 3 0 0 0 gtest 26 25 1 0 0 ===================================================================== control_panel 15 14 1 0 0 :KVM_LM_64_g64 1 1 0 0 0 :KVM_four_sguest_64_gPAE 1 1 0 0 0 :KVM_4G_guest_64_g64 1 1 0 0 0 :KVM_four_sguest_64_g64 1 1 0 0 0 :KVM_linux_win_64_gPAE 1 1 0 0 0 :KVM_1500M_guest_64_gPAE 1 1 0 0 0 :KVM_SR_64_g64 1 0 1 0 0 :KVM_LM_64_gPAE 1 1 0 0 0 :KVM_256M_guest_64_g64 1 1 0 0 0 :KVM_1500M_guest_64_g64 1 1 0 0 0 :KVM_4G_guest_64_gPAE 1 1 0 0 0 :KVM_SR_64_gPAE 1 1 0 0 0 :KVM_256M_guest_64_gPAE 1 1 0 0 0 :KVM_two_winxp_64_gPAE 1 1 0 0 0 :KVM_four_dguest_64_gPAE 1 1 0 0 0 Restart 3 3 0 0 0 :GuestPAE_64_gPAE 1 1 0 0 0 :BootTo64_64_gPAE 1 1 0 0 0 :Guest64_64_gPAE 1 1 0 0 0 gtest 26 25 1 0 0 :boot_up_acpi_64_gPAE 1 1 0 0 0 :boot_up_noacpi_xp_64_gP 1 1 0 0 0 :boot_smp_acpi_xp_64_g64 1 1 0 0 0 :boot_base_kernel_64_gPA 1 1 0 0 0 :boot_smp_acpi_win2k3_64 1 1 0 0 0 :boot_smp_acpi_win2k_64_ 1 1 0 0 0 :boot_base_kernel_64_g64 1 1 0 0 0 :bootx_64_gPAE 1 1 0 0 0 :kb_nightly_64_gPAE 1 1 0 0 0 :ltp_nightly_64_g64 1 1 0 0 0 :boot_up_acpi_64_g64 1 1 0 0 0 :boot_up_noacpi_win2k_64 1 1 0 0 0 :boot_smp_acpi_xp_64_gPA 1 1 0 0 0 :boot_smp_vista_64_gPAE 1 1 0 0 0 :boot_up_acpi_win2k3_64_ 1 1 0 0 0 :reboot_xp_64_gPAE 1 1 0 0 0 :bootx_64_g64 1 1 0 0 0 :reboot_xp_64_g64 1 0 1 0 0 :boot_up_vista_64_g64 1 1 0 0 0 :boot_smp_vista_64_g64 1 1 0 0 0 :boot_up_acpi_xp_64_g64 1 1 0 0 0 :boot_up_vista_64_gPAE 1 1 0 0 0 :ltp_nightly_64_gPAE 1 1 0 0 0 :boot_smp_acpi_win2k3_64 1 1 0 0 0 :boot_up_noacpi_win2k3_6 1 1 0 0 0 :kb_nightly_64_g64 1 1 0 0 0 ===================================================================== Total 44 42 2 0 0 Thanks Yunfeng |
|
From: Anthony L. <an...@co...> - 2008-04-14 01:41:16
|
Gerd von Egidy wrote: > Hi, > > I just tried the virtio block device with the intent > to boost disk throughput for my vm. > We really haven't optimized virtio block yet under KVM. Most of the effort so far has been focused on virtio_net. We'll get there though in the near future. Regards, Anthony Liguori > I ran bonnie++ -r 512 -s 2048 -u nobody -d /tmp: > > Version 1.03 ------Sequential Output------ --Sequential Input- --Random- > -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- > Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP > virtio_blk 2G 14274 42 20206 14 22363 37 31116 92 66731 81 140.8 13 > kvm-ide 2G 26065 83 26435 28 24146 33 26587 84 57991 18 91.5 2 > > The host is a Xeon 3040, 1G RAM (I know that that is a bit > few, it's just a test machine...), the vm gets 512MB of that. > The data is stored on two SATA disks, mirrored (RAID1) with > md, lvm running on top of that. > > Host and Client are running 2.6.25-0.200.rc8.git3.i686. This > is a kernel from Fedora-Rawhide with kvm manually enabled by me. > KVM version is 64. > > Especially writing seems to be slower using virtio, but > reading isn't that much faster. > > I thought virtio would improve io speed significantly because > of fewer steps needed to communicate betweeen host and client. > What might be the reason that I can't see a speed boost? > > - Wrong setup (The virtio-client boots from /dev/vda1, > so I think virtio is working) > - virtio_blk is not matured/tuned enough to give a real > speed boost > - I'm missing a patch that is not included into 2.6.26-rc8 > but can be found in kvm-git > - The output of bonnie++ is bogus because timing is not that > accurate within a kvm-client > > Any ideas welcome. > > Kind regards, > > Gerd > > |
|
From: Jerone Y. <jy...@us...> - 2008-04-14 01:09:00
|
I just took the old description that was there before. A much better one would be: Remove declarations of kvm_*_pit() on architectures who do not support not have a PIT. That is what I was really intending. It removes a lot of compile warnings, when compiling anything with libkvm.h on platforms that do not have a pit. It's mainly because of the structures that are used as arguments to these function declrations. On Sun, 2008-04-13 at 17:24 +0300, Avi Kivity wrote: > Jerone Young wrote: > > - I am resending this patch removing ia64. It apprently fell through the cracks. > > > > Don't compile kvm_*_pit() on architectures whose currently supported platforms do not contain a PIT. > > > > Signed-off-by: Hollis Blanchard <ho...@us...> > > Signed-off-by: Jerone Young <jy...@us...> > > > > diff --git a/libkvm/libkvm.h b/libkvm/libkvm.h > > --- a/libkvm/libkvm.h > > +++ b/libkvm/libkvm.h > > @@ -549,6 +549,7 @@ int kvm_pit_in_kernel(kvm_context_t kvm) > > > > #ifdef KVM_CAP_PIT > > > > +#if defined(__i386__) || defined(__x86_64__) > > /*! > > * \brief Get in kernel PIT of the virtual domain > > * > > @@ -569,6 +570,7 @@ int kvm_get_pit(kvm_context_t kvm, struc > > * \param s PIT state of the virtual domain > > */ > > int kvm_set_pit(kvm_context_t kvm, struct kvm_pit_state *s); > > +#endif > > > > #endif > > Patch is okay, but doesn't match the description at all. Is this what > you intended to send? > |
|
From: Samuel M. <sam...@gm...> - 2008-04-14 00:31:01
|
On Sun, Apr 13, 2008 at 9:49 PM, Dor Laor <dor...@qu...> wrote: > On Thu, 2008-04-10 at 11:48 +0300, Amit Shah wrote: > > If kvm uses the in-kernel irqchip, interrupts are routed to > > the guest via the kvm module (accompanied kernel changes are necessar). > > If -no-kvm-irqchip is used, the 'irqhook' module, also included here, > > is to be used. > > > > IMO we can drop the pci pass through support in userspace and only keep > the in-kenel chip path. Normally we do want the option of running w/o > kernel devices but it's only to test for regressions against userspace. > In this case it's all new code so there is no point to compare, it's > just lots of complicated code (userspace apic, irqhook module) that only > helpful for qemu. Since it's not likely qemu will merge it, let's stick > with the main path. > Comments? Please keep the userspace support alive. I am particularly interested in using the pci-passthough to qemu running non x86 system emulation (at the moment mips) My hope is that the pci - passthough could help with developing drivers and testing across architectures... Samuel > Dor > > > > Signed-off-by: Amit Shah <ami...@qu...> > > --- > > Makefile | 10 +- > > irqhook/Kbuild | 3 + > > irqhook/Makefile | 25 ++ > > irqhook/irqhook_main.c | 215 ++++++++++++++ > > kernel/Makefile | 4 + > > libkvm/libkvm-x86.c | 14 +- > > libkvm/libkvm.h | 24 ++ > > qemu/Makefile.target | 1 + > > qemu/hw/apic.c | 2 + > > qemu/hw/isa.h | 2 + > > qemu/hw/pc.c | 4 + > > qemu/hw/pci-passthrough.c | 677 +++++++++++++++++++++++++++++++++++++++++++++ > > qemu/hw/pci-passthrough.h | 102 +++++++ > > qemu/hw/pci.c | 11 + > > qemu/hw/pci.h | 1 + > > qemu/hw/piix_pci.c | 19 ++ > > qemu/vl.c | 16 + > > tools/pci_barsize.c | 53 ++++ > > tools/pci_mmio.c | 82 ++++++ > > 19 files changed, 1260 insertions(+), 5 deletions(-) > > > > > > > > ------------------------------------------------------------------------- > 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 > |
|
From: Marcelo T. <mto...@re...> - 2008-04-14 00:25:53
|
On Sun, Apr 13, 2008 at 11:04:44PM +0200, Gerd von Egidy wrote: > Hi, > > I just tried the virtio block device with the intent > to boost disk throughput for my vm. > > I ran bonnie++ -r 512 -s 2048 -u nobody -d /tmp: > > Version 1.03 ------Sequential Output------ --Sequential Input- --Random- > -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- > Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP > virtio_blk 2G 14274 42 20206 14 22363 37 31116 92 66731 81 140.8 13 > kvm-ide 2G 26065 83 26435 28 24146 33 26587 84 57991 18 91.5 2 > > The host is a Xeon 3040, 1G RAM (I know that that is a bit > few, it's just a test machine...), the vm gets 512MB of that. > The data is stored on two SATA disks, mirrored (RAID1) with > md, lvm running on top of that. > > Host and Client are running 2.6.25-0.200.rc8.git3.i686. This > is a kernel from Fedora-Rawhide with kvm manually enabled by me. > KVM version is 64. > > Especially writing seems to be slower using virtio, but > reading isn't that much faster. > > I thought virtio would improve io speed significantly because > of fewer steps needed to communicate betweeen host and client. > What might be the reason that I can't see a speed boost? > > - Wrong setup (The virtio-client boots from /dev/vda1, > so I think virtio is working) > - virtio_blk is not matured/tuned enough to give a real > speed boost > - I'm missing a patch that is not included into 2.6.26-rc8 > but can be found in kvm-git > - The output of bonnie++ is bogus because timing is not that > accurate within a kvm-client > > Any ideas welcome. virtio-blk is doing synchronous IO which blocks the guest CPU. This is especially bad for write intensive loads where the guest will hang in the host write throttling logic. In the meantime please try the following patch: http://www.mail-archive.com/kvm...@li.../msg14732.html Some larger changes will take place to allow similar behaviour with an API for asynchronous vectored IO. |
|
From: Gerd v. E. <li...@eg...> - 2008-04-13 21:55:56
|
Hi Charles, thanks for the quick reply. > My understanding is that virtio is very latency-sensitive. Do you know > whether your system is configured for high-resolution timer support, and > (more to the point) which clock source KVM is using on your host? On the host: > grep "Clock Event Device" /proc/timer_list Clock Event Device: hpet Clock Event Device: lapic Clock Event Device: lapic Within the vm: > grep "Clock Event Device" /proc/timer_list Clock Event Device: pit Clock Event Device: lapic Host and vm use the same kernel, CONFIG_HIGH_RES_TIMERS=y How do I find out which clock source KVM is using? Kind regards, Gerd -- Address (better: trap) for people I really don't want to get mail from: ja...@ca... |
|
From: Charles D. <Cha...@me...> - 2008-04-13 21:25:00
|
My understanding is that virtio is very latency-sensitive. Do you know whether your system is configured for high-resolution timer support, and (more to the point) which clock source KVM is using on your host? |
|
From: Gerd v. E. <li...@eg...> - 2008-04-13 21:05:07
|
Hi,
I just tried the virtio block device with the intent
to boost disk throughput for my vm.
I ran bonnie++ -r 512 -s 2048 -u nobody -d /tmp:
Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
virtio_blk 2G 14274 42 20206 14 22363 37 31116 92 66731 81 140.8 13
kvm-ide 2G 26065 83 26435 28 24146 33 26587 84 57991 18 91.5 2
The host is a Xeon 3040, 1G RAM (I know that that is a bit
few, it's just a test machine...), the vm gets 512MB of that.
The data is stored on two SATA disks, mirrored (RAID1) with
md, lvm running on top of that.
Host and Client are running 2.6.25-0.200.rc8.git3.i686. This
is a kernel from Fedora-Rawhide with kvm manually enabled by me.
KVM version is 64.
Especially writing seems to be slower using virtio, but
reading isn't that much faster.
I thought virtio would improve io speed significantly because
of fewer steps needed to communicate betweeen host and client.
What might be the reason that I can't see a speed boost?
- Wrong setup (The virtio-client boots from /dev/vda1,
so I think virtio is working)
- virtio_blk is not matured/tuned enough to give a real
speed boost
- I'm missing a patch that is not included into 2.6.26-rc8
but can be found in kvm-git
- The output of bonnie++ is bogus because timing is not that
accurate within a kvm-client
Any ideas welcome.
Kind regards,
Gerd
--
Address (better: trap) for people I really don't want to get mail from:
ja...@ca...
|
157 messages has been excluded from this view by a project administrator.
