[COMMIT master] kvm: use new header layout
From: Avi Kivity a...@redhat.com
Signed-off-by: Avi Kivity a...@redhat.com
diff --git a/Makefile.target b/Makefile.target
index 0041a46..ab8 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -134,6 +134,9 @@ endif
kvm.o: CFLAGS+=$(KVM_CFLAGS)
kvm-all.o: CFLAGS+=$(KVM_CFLAGS)
+qemu-kvm.o qemu-kvm-x86.o device-assignment.o ioapic.o i8259.o kvm-tpr-opt.o: \
+ CFLAGS+=$(KVM_CFLAGS)
+
all: $(PROGS)
#
@@ -601,8 +604,7 @@ ifdef CONFIG_CS4231A
SOUND_HW += cs4231a.o
endif
-ifdef CONFIG_KVM_KERNEL_INC
-CFLAGS += -I $(CONFIG_KVM_KERNEL_INC)
+ifdef USE_KVM
DEPLIBS += libkvm.a
endif
@@ -827,7 +829,7 @@ $(QEMU_PROG): $(OBJS) ../libqemu_common.a libqemu.a
$(DEPLIBS)
FORCE:
libkvm.a: FORCE
- $(MAKE) -C ../kvm/libkvm
+ $(MAKE) -C ../kvm/libkvm KVM_CFLAGS=$(KVM_CFLAGS)
if ! cmp -s libkvm.a ../kvm/libkvm/libkvm.a; then \
cp ../kvm/libkvm/libkvm.a . ; \
fi
diff --git a/configure b/configure
index a2b8c0f..fc0fb9b 100755
--- a/configure
+++ b/configure
@@ -199,9 +199,6 @@ signalfd=no
eventfd=no
cpu_emulation=yes
-# qemu-kvm: use local kerneldir
-kerneldir=$(readlink -f kvm/kernel)
-
# OS specific
if check_define __linux__ ; then
targetos=Linux
@@ -815,8 +812,22 @@ fi
##
# KVM probe
+case $cpu in
+i386 | x86_64)
+ kvm_arch=x86
+ ;;
+*)
+ kvm_arch=$cpu
+ ;;
+esac
+
+kvm_cflags=
+
if test $kvm = yes ; then
+kvm_cflags=-I$source_path/kvm/kernel/include
+kvm_cflags=$kvm_cflags -I$source_path/kvm/kernel/arch/$kvm_arch/include
+
# test for KVM_CAP_PIT
cat $TMPC EOF
@@ -826,7 +837,7 @@ cat $TMPC EOF
#endif
int main(void) { return 0; }
EOF
-if $cc $ARCH_CFLAGS $CFLAGS -I$kerneldir/include -o $TMPE ${OS_CFLAGS}
$TMPC 2 /dev/null ; then
+if $cc $ARCH_CFLAGS $CFLAGS $kvm_cflags -o $TMPE ${OS_CFLAGS} $TMPC 2
/dev/null ; then
kvm_cap_pit=yes
fi
@@ -839,7 +850,7 @@ cat $TMPC EOF
#endif
int main(void) { return 0; }
EOF
-if $cc $ARCH_CFLAGS $CFLAGS -I$kerneldir/include -o $TMPE ${OS_CFLAGS}
$TMPC 2 /dev/null ; then
+if $cc $ARCH_CFLAGS $CFLAGS $kvm_cflags -o $TMPE ${OS_CFLAGS} $TMPC 2
/dev/null ; then
kvm_cap_device_assignment=yes
fi
fi
@@ -1168,19 +1179,6 @@ if test $kvm = yes ; then
#endif
int main(void) { return 0; }
EOF
- if test $kerneldir != ; then
- kvm_cflags=-I$kerneldir/include
- if test \( $cpu = i386 -o $cpu = x86_64 \) \
- -a -d $kerneldir/arch/x86/include ; then
-kvm_cflags=$kvm_cflags -I$kerneldir/arch/x86/include
- elif test $cpu = ppc -a -d $kerneldir/arch/powerpc/include ; then
- kvm_cflags=$kvm_cflags -I$kerneldir/arch/powerpc/include
-elif test -d $kerneldir/arch/$cpu/include ; then
-kvm_cflags=$kvm_cflags -I$kerneldir/arch/$cpu/include
- fi
- else
- kvm_cflags=
- fi
if $cc $ARCH_CFLAGS -o $TMPE ${OS_CFLAGS} $kvm_cflags $TMPC \
/dev/null 2/dev/null ; then
:
@@ -1897,7 +1895,7 @@ 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=$kerneldir/include config-host.mak
+echo KVM_CFLAGS=$kvm_cflags $config_mak
if test $kvm_cap_pit = yes ; then
echo USE_KVM_PIT=1 $config_mak
echo #define USE_KVM_PIT 1 $config_h
diff --git a/kvm/libkvm/Makefile b/kvm/libkvm/Makefile
index 8811d84..727ce48 100644
--- a/kvm/libkvm/Makefile
+++ b/kvm/libkvm/Makefile
@@ -12,7 +12,7 @@ cc-option = $(shell if $(CC) $(1) -S -o /dev/null -xc
/dev/null \
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$(CONFIG_KVM_KERNEL_INC)
+CFLAGS += $(KVM_CFLAGS)
LDFLAGS += $(CFLAGS)
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] kvm: Move kernel headers from asm-x86 to arch/x86/include
From: Avi Kivity a...@redhat.com This removes the need for an 'asm' symlink. Signed-off-by: Avi Kivity a...@redhat.com diff --git a/kvm/kernel/include/asm-x86/kvm.h b/kvm/kernel/arch/x86/include/asm/kvm.h similarity index 100% rename from kvm/kernel/include/asm-x86/kvm.h rename to kvm/kernel/arch/x86/include/asm/kvm.h diff --git a/kvm/kernel/include/asm-x86/kvm_host.h b/kvm/kernel/arch/x86/include/asm/kvm_host.h similarity index 100% rename from kvm/kernel/include/asm-x86/kvm_host.h rename to kvm/kernel/arch/x86/include/asm/kvm_host.h diff --git a/kvm/kernel/include/asm-x86/kvm_para.h b/kvm/kernel/arch/x86/include/asm/kvm_para.h similarity index 100% rename from kvm/kernel/include/asm-x86/kvm_para.h rename to kvm/kernel/arch/x86/include/asm/kvm_para.h diff --git a/kvm/kernel/include/asm-x86/kvm_x86_emulate.h b/kvm/kernel/arch/x86/include/asm/kvm_x86_emulate.h similarity index 100% rename from kvm/kernel/include/asm-x86/kvm_x86_emulate.h rename to kvm/kernel/arch/x86/include/asm/kvm_x86_emulate.h diff --git a/kvm/kernel/include/asm-x86/svm.h b/kvm/kernel/arch/x86/include/asm/svm.h similarity index 100% rename from kvm/kernel/include/asm-x86/svm.h rename to kvm/kernel/arch/x86/include/asm/svm.h diff --git a/kvm/kernel/include/asm-x86/virtext.h b/kvm/kernel/arch/x86/include/asm/virtext.h similarity index 100% rename from kvm/kernel/include/asm-x86/virtext.h rename to kvm/kernel/arch/x86/include/asm/virtext.h diff --git a/kvm/kernel/include/asm-x86/vmx.h b/kvm/kernel/arch/x86/include/asm/vmx.h similarity index 100% rename from kvm/kernel/include/asm-x86/vmx.h rename to kvm/kernel/arch/x86/include/asm/vmx.h -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] kvm: add i8254.c to list of files requiring kvm includes
From: Avi Kivity a...@redhat.com Signed-off-by: Avi Kivity a...@redhat.com diff --git a/Makefile.target b/Makefile.target index bc4a0ed..91fa57f 100644 --- a/Makefile.target +++ b/Makefile.target @@ -134,8 +134,8 @@ endif kvm.o: CFLAGS+=$(KVM_CFLAGS) kvm-all.o: CFLAGS+=$(KVM_CFLAGS) -qemu-kvm.o qemu-kvm-x86.o device-assignment.o ioapic.o i8259.o kvm-tpr-opt.o: \ - CFLAGS+=$(KVM_CFLAGS) +qemu-kvm.o qemu-kvm-x86.o device-assignment.o ioapic.o i8259.o i8254.o \ + kvm-tpr-opt.o: CFLAGS+=$(KVM_CFLAGS) all: $(PROGS) -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] device assignment: move memset to after mmap failure check
From: Michael S. Tsirkin m...@redhat.com
By the time we've done a memset, it's too late to
check the pointer for MAP_FAILED value. Let's compare
to MAP_FAILED first.
Signed-off-by: Michael S. Tsikirn m...@redhat.com
Signed-off-by: Avi Kivity a...@redhat.com
diff --git a/hw/device-assignment.c b/hw/device-assignment.c
index 1f0a1a7..0a5f850 100644
--- a/hw/device-assignment.c
+++ b/hw/device-assignment.c
@@ -1087,12 +1087,12 @@ static int
assigned_dev_register_msix_mmio(AssignedDevice *dev)
dev-msix_table_page = mmap(NULL, 0x1000,
PROT_READ|PROT_WRITE,
MAP_ANONYMOUS|MAP_PRIVATE, 0, 0);
-memset(dev-msix_table_page, 0, 0x1000);
if (dev-msix_table_page == MAP_FAILED) {
fprintf(stderr, fail allocate msix_table_page! %s\n,
strerror(errno));
return -EFAULT;
}
+memset(dev-msix_table_page, 0, 0x1000);
dev-mmio_index = cpu_register_io_memory(0,
msix_mmio_read, msix_mmio_write, dev);
return 0;
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] kvm: i8254-kvm.c depends on kvm, not i8254.c
From: Avi Kivity a...@redhat.com Signed-off-by: Avi Kivity a...@redhat.com diff --git a/Makefile.target b/Makefile.target index 91fa57f..d890220 100644 --- a/Makefile.target +++ b/Makefile.target @@ -134,7 +134,7 @@ endif kvm.o: CFLAGS+=$(KVM_CFLAGS) kvm-all.o: CFLAGS+=$(KVM_CFLAGS) -qemu-kvm.o qemu-kvm-x86.o device-assignment.o ioapic.o i8259.o i8254.o \ +qemu-kvm.o qemu-kvm-x86.o device-assignment.o ioapic.o i8259.o i8254-kvm.o \ kvm-tpr-opt.o: CFLAGS+=$(KVM_CFLAGS) all: $(PROGS) -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] Merge commit 'bios/master'
From: Avi Kivity a...@redhat.com * commit 'bios/master': - fixed PCI IRQ router check for legacy BIOS (checking vendor ID only) - removed wrong character from FSF address (converted invisible and useless - implemented MTRR support in the bios. This is a combination of the individual [Bochs-developers] [PATCH] rombios32: fix SMBIOS end address range reporting Deduplicate INT 15h, AX=E820h code by removing some identical parts. - run acpi-dsdt.dsl through cpp before compiling with iasl (to support #ifdef and - the HPET merge from QEMU introduced new structures which need packing (Sebastian Herbszt) - applied 3 patches from the Qemu project Conflicts: kvm/bios/BIOS-bochs-latest kvm/bios/BIOS-bochs-legacy kvm/bios/rombios.c kvm/bios/rombios.h kvm/bios/rombios32.c Signed-off-by: Avi Kivity a...@redhat.com -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] Regenerate bios for bochs bios merge
From: Avi Kivity a...@redhat.com Signed-off-by: Avi Kivity a...@redhat.com diff --git a/pc-bios/bios.bin b/pc-bios/bios.bin index 04c1f86..d5d42f3 100644 Binary files a/pc-bios/bios.bin and b/pc-bios/bios.bin differ -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] qemu-kvm: configure script fixups after qemu-kvm reorg
Make kvm configure script and Makefile work again after things have been
moved around, so that you can do 'cd kvm ./configure' to get a
kvm-enabled qemu.
Also, guard against infinite recursion in case of 'cd' commands failing.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
--
On Thu, Apr 23, 2009 at 06:40:00PM +0300, Avi Kivity wrote:
After a lengthy testing phase, qemu-kvm.git has replaced
kvm-userspace.git as the source repository for kvm userspace development.
This patch makes cd kvm; ./configure work.
Is this the expected mode of operation?
diff --git a/kvm/Makefile b/kvm/Makefile
index 617504c..1ef6493 100644
--- a/kvm/Makefile
+++ b/kvm/Makefile
@@ -7,29 +7,29 @@ rpmrelease = devel
sane-arch = $(subst i386,x86,$(subst x86_64,x86,$(subst s390x,s390,$(ARCH
-.PHONY: kernel user libkvm qemu bios vgabios extboot clean libfdt cscope
+.PHONY: kernel user libkvm ${QEMU_DIR} bios vgabios extboot clean libfdt cscope
-all: libkvm qemu
+all: libkvm ${QEMU_DIR}
ifneq '$(filter $(ARCH), x86_64 i386 ia64)' ''
all: $(if $(WANT_MODULE), kernel) user
endif
kcmd = $(if $(WANT_MODULE),,@\#)
-qemu kernel user libkvm:
+${QEMU_DIR} kernel user libkvm:
$(MAKE) -C $@
-qemu: libkvm
+${QEMU_DIR}: libkvm
ifneq '$(filter $(ARCH), i386 x86_64)' ''
-qemu: extboot
+${QEMU_DIR}: extboot
endif
ifneq '$(filter $(ARCH), powerpc ia64)' ''
-qemu: libfdt
+${QEMU_DIR}: libfdt
endif
user: libkvm
# sync if kernel/Makefile exists and if using --with-patched-kernel
-user libkvm qemu: header-sync-$(if $(wildcard kernel/Makefile),$(if
$(WANT_MODULE),n,y),n)
+user libkvm ${QEMU_DIR}: header-sync-$(if $(wildcard kernel/Makefile),$(if
$(WANT_MODULE),n,y),n)
header-sync-n:
@@ -42,18 +42,18 @@ header-sync-y:
bios:
$(MAKE) -C $@
- cp bios/BIOS-bochs-latest qemu/pc-bios/bios.bin
+ cp bios/BIOS-bochs-latest ${QEMU_DIR}/pc-bios/bios.bin
vgabios:
$(MAKE) -C $@
- cp vgabios/VGABIOS-lgpl-latest.bin qemu/pc-bios/vgabios.bin
- cp vgabios/VGABIOS-lgpl-latest.cirrus.bin
qemu/pc-bios/vgabios-cirrus.bin
+ cp vgabios/VGABIOS-lgpl-latest.bin ${QEMU_DIR}/pc-bios/vgabios.bin
+ cp vgabios/VGABIOS-lgpl-latest.cirrus.bin
${QEMU_DIR}/pc-bios/vgabios-cirrus.bin
extboot:
$(MAKE) -C $@
- if ! [ -f qemu/pc-bios/extboot.bin ] \
- || ! cmp -s qemu/pc-bios/extboot.bin extboot/extboot.bin; then \
- cp extboot/extboot.bin qemu/pc-bios/extboot.bin; \
+ if ! [ -f ${QEMU_DIR}/pc-bios/extboot.bin ] \
+ || ! cmp -s ${QEMU_DIR}/pc-bios/extboot.bin extboot/extboot.bin;
then \
+ cp extboot/extboot.bin ${QEMU_DIR}/pc-bios/extboot.bin; \
fi
libfdt:
$(MAKE) -C $@
@@ -75,7 +75,7 @@ install-rpm:
mkdir -p $(DESTDIR)/$(initdir)
mkdir -p $(DESTDIR)/$(utilsdir)
mkdir -p $(DESTDIR)/etc/udev/rules.d
- make -C qemu DESTDIR=$(DESTDIR)/ install
+ make -C ${QEMU_DIR} DESTDIR=$(DESTDIR)/ install
ln -sf /usr/kvm/bin/qemu-system-x86_64 $(DESTDIR)/$(bin)
install -m 755 kvm_stat $(DESTDIR)/$(bindir)/kvm_stat
cp scripts/kvm $(DESTDIR)/$(initdir)/kvm
@@ -85,7 +85,7 @@ install-rpm:
install:
$(kcmd)make -C kernel DESTDIR=$(DESTDIR) install
make -C libkvm DESTDIR=$(DESTDIR) install
- make -C qemu DESTDIR=$(DESTDIR) install
+ make -C ${QEMU_DIR} DESTDIR=$(DESTDIR) install
tmpspec = .tmp.kvm.spec
RPMTOPDIR = $$(pwd)/rpmtop
@@ -100,7 +100,7 @@ rpm:srpm
srpm:
mkdir -p $(RPMTOPDIR)/{SOURCES,SRPMS}
sed 's/^Release:.*/Release: $(rpmrelease)/' kvm.spec $(tmpspec)
- tar czf $(RPMTOPDIR)/SOURCES/kvm.tar.gz qemu
+ tar czf $(RPMTOPDIR)/SOURCES/kvm.tar.gz ${QEMU_DIR}
tar czf $(RPMTOPDIR)/SOURCES/user.tar.gz user
tar czf $(RPMTOPDIR)/SOURCES/libkvm.tar.gz libkvm
tar czf $(RPMTOPDIR)/SOURCES/kernel.tar.gz kernel
@@ -111,7 +111,7 @@ srpm:
$(RM) $(tmpspec)
clean:
- for i in $(if $(WANT_MODULE), kernel) user libkvm qemu libfdt; do \
+ for i in $(if $(WANT_MODULE), kernel) user libkvm ${QEMU_DIR} libfdt;
do \
make -C $$i clean; \
done
rm -f ./cscope.*
diff --git a/kvm/configure b/kvm/configure
index 249c743..f4873c1 100755
--- a/kvm/configure
+++ b/kvm/configure
@@ -14,6 +14,7 @@ qemu_opts=()
cross_prefix=
arch=`uname -m`
target_exec=
+qemu_directory=$PWD/..
# don't use uname if kerneldir is set
no_uname=
if [ -z TMPDIR ] ; then
@@ -41,8 +42,7 @@ usage() {
Any additional option is given to qemu's configure verbatim; including:
EOF
-cd qemu
-./configure --help | egrep enable-|disable- \
+cd $qemu_directory ./configure --help | egrep enable-|disable- \
| grep -v user | grep -v system | grep -v kqemu | grep -v kvm \
| sed -e s/^ //g \
| sed -es/ enable/enable/g | sed -e s/ disable/disable/g
@@ -117,7 +117,7 @@ processor=${arch#*-}
Re: [PATCH] qemu-kvm: configure script fixups after qemu-kvm reorg
On Sun, Apr 26, 2009 at 10:38:39AM +0300, Michael S. Tsirkin wrote:
Make kvm configure script and Makefile work again after things have been
moved around, so that you can do 'cd kvm ./configure' to get a
kvm-enabled qemu.
Also, guard against infinite recursion in case of 'cd' commands failing.
I suppose changes under kvm/kernel/* are not relevant to this goal. Also
for me running ./configure --kerneldir=/path/to/kernel at top dir works.
(/path/to/kernel should be absolute though, otherwise kernel include path
is incorrect).
Signed-off-by: Michael S. Tsirkin m...@redhat.com
--
On Thu, Apr 23, 2009 at 06:40:00PM +0300, Avi Kivity wrote:
After a lengthy testing phase, qemu-kvm.git has replaced
kvm-userspace.git as the source repository for kvm userspace development.
This patch makes cd kvm; ./configure work.
Is this the expected mode of operation?
diff --git a/kvm/Makefile b/kvm/Makefile
index 617504c..1ef6493 100644
--- a/kvm/Makefile
+++ b/kvm/Makefile
@@ -7,29 +7,29 @@ rpmrelease = devel
sane-arch = $(subst i386,x86,$(subst x86_64,x86,$(subst s390x,s390,$(ARCH
-.PHONY: kernel user libkvm qemu bios vgabios extboot clean libfdt cscope
+.PHONY: kernel user libkvm ${QEMU_DIR} bios vgabios extboot clean libfdt
cscope
-all: libkvm qemu
+all: libkvm ${QEMU_DIR}
ifneq '$(filter $(ARCH), x86_64 i386 ia64)' ''
all: $(if $(WANT_MODULE), kernel) user
endif
kcmd = $(if $(WANT_MODULE),,@\#)
-qemu kernel user libkvm:
+${QEMU_DIR} kernel user libkvm:
$(MAKE) -C $@
-qemu: libkvm
+${QEMU_DIR}: libkvm
ifneq '$(filter $(ARCH), i386 x86_64)' ''
-qemu: extboot
+${QEMU_DIR}: extboot
endif
ifneq '$(filter $(ARCH), powerpc ia64)' ''
-qemu: libfdt
+${QEMU_DIR}: libfdt
endif
user: libkvm
# sync if kernel/Makefile exists and if using --with-patched-kernel
-user libkvm qemu: header-sync-$(if $(wildcard kernel/Makefile),$(if
$(WANT_MODULE),n,y),n)
+user libkvm ${QEMU_DIR}: header-sync-$(if $(wildcard kernel/Makefile),$(if
$(WANT_MODULE),n,y),n)
header-sync-n:
@@ -42,18 +42,18 @@ header-sync-y:
bios:
$(MAKE) -C $@
- cp bios/BIOS-bochs-latest qemu/pc-bios/bios.bin
+ cp bios/BIOS-bochs-latest ${QEMU_DIR}/pc-bios/bios.bin
vgabios:
$(MAKE) -C $@
- cp vgabios/VGABIOS-lgpl-latest.bin qemu/pc-bios/vgabios.bin
- cp vgabios/VGABIOS-lgpl-latest.cirrus.bin
qemu/pc-bios/vgabios-cirrus.bin
+ cp vgabios/VGABIOS-lgpl-latest.bin ${QEMU_DIR}/pc-bios/vgabios.bin
+ cp vgabios/VGABIOS-lgpl-latest.cirrus.bin
${QEMU_DIR}/pc-bios/vgabios-cirrus.bin
extboot:
$(MAKE) -C $@
- if ! [ -f qemu/pc-bios/extboot.bin ] \
- || ! cmp -s qemu/pc-bios/extboot.bin extboot/extboot.bin; then \
- cp extboot/extboot.bin qemu/pc-bios/extboot.bin; \
+ if ! [ -f ${QEMU_DIR}/pc-bios/extboot.bin ] \
+ || ! cmp -s ${QEMU_DIR}/pc-bios/extboot.bin extboot/extboot.bin;
then \
+ cp extboot/extboot.bin ${QEMU_DIR}/pc-bios/extboot.bin; \
fi
libfdt:
$(MAKE) -C $@
@@ -75,7 +75,7 @@ install-rpm:
mkdir -p $(DESTDIR)/$(initdir)
mkdir -p $(DESTDIR)/$(utilsdir)
mkdir -p $(DESTDIR)/etc/udev/rules.d
- make -C qemu DESTDIR=$(DESTDIR)/ install
+ make -C ${QEMU_DIR} DESTDIR=$(DESTDIR)/ install
ln -sf /usr/kvm/bin/qemu-system-x86_64 $(DESTDIR)/$(bin)
install -m 755 kvm_stat $(DESTDIR)/$(bindir)/kvm_stat
cp scripts/kvm $(DESTDIR)/$(initdir)/kvm
@@ -85,7 +85,7 @@ install-rpm:
install:
$(kcmd)make -C kernel DESTDIR=$(DESTDIR) install
make -C libkvm DESTDIR=$(DESTDIR) install
- make -C qemu DESTDIR=$(DESTDIR) install
+ make -C ${QEMU_DIR} DESTDIR=$(DESTDIR) install
tmpspec = .tmp.kvm.spec
RPMTOPDIR = $$(pwd)/rpmtop
@@ -100,7 +100,7 @@ rpm: srpm
srpm:
mkdir -p $(RPMTOPDIR)/{SOURCES,SRPMS}
sed 's/^Release:.*/Release: $(rpmrelease)/' kvm.spec $(tmpspec)
- tar czf $(RPMTOPDIR)/SOURCES/kvm.tar.gz qemu
+ tar czf $(RPMTOPDIR)/SOURCES/kvm.tar.gz ${QEMU_DIR}
tar czf $(RPMTOPDIR)/SOURCES/user.tar.gz user
tar czf $(RPMTOPDIR)/SOURCES/libkvm.tar.gz libkvm
tar czf $(RPMTOPDIR)/SOURCES/kernel.tar.gz kernel
@@ -111,7 +111,7 @@ srpm:
$(RM) $(tmpspec)
clean:
- for i in $(if $(WANT_MODULE), kernel) user libkvm qemu libfdt; do \
+ for i in $(if $(WANT_MODULE), kernel) user libkvm ${QEMU_DIR} libfdt;
do \
make -C $$i clean; \
done
rm -f ./cscope.*
diff --git a/kvm/configure b/kvm/configure
index 249c743..f4873c1 100755
--- a/kvm/configure
+++ b/kvm/configure
@@ -14,6 +14,7 @@ qemu_opts=()
cross_prefix=
arch=`uname -m`
target_exec=
+qemu_directory=$PWD/..
# don't use uname if kerneldir is set
no_uname=
if [ -z TMPDIR ] ; then
@@ -41,8 +42,7 @@ usage() {
Any additional option is given to qemu's configure verbatim; including:
Re: [PATCH] qemu-kvm: configure script fixups after qemu-kvm reorg
On Sun, Apr 26, 2009 at 10:48:20AM +0300, Gleb Natapov wrote:
On Sun, Apr 26, 2009 at 10:38:39AM +0300, Michael S. Tsirkin wrote:
Make kvm configure script and Makefile work again after things have been
moved around, so that you can do 'cd kvm ./configure' to get a
kvm-enabled qemu.
Also, guard against infinite recursion in case of 'cd' commands failing.
I suppose changes under kvm/kernel/* are not relevant to this goal.
I don't really understand how they got there.
Is configure script overwriting files under version control?
Also
for me running ./configure --kerneldir=/path/to/kernel at top dir works.
(/path/to/kernel should be absolute though, otherwise kernel include path
is incorrect).
I'm using --with-patched-kernel which does not seem to be available
there.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
--
On Thu, Apr 23, 2009 at 06:40:00PM +0300, Avi Kivity wrote:
After a lengthy testing phase, qemu-kvm.git has replaced
kvm-userspace.git as the source repository for kvm userspace development.
This patch makes cd kvm; ./configure work.
Is this the expected mode of operation?
diff --git a/kvm/Makefile b/kvm/Makefile
index 617504c..1ef6493 100644
--- a/kvm/Makefile
+++ b/kvm/Makefile
@@ -7,29 +7,29 @@ rpmrelease = devel
sane-arch = $(subst i386,x86,$(subst x86_64,x86,$(subst
s390x,s390,$(ARCH
-.PHONY: kernel user libkvm qemu bios vgabios extboot clean libfdt cscope
+.PHONY: kernel user libkvm ${QEMU_DIR} bios vgabios extboot clean libfdt
cscope
-all: libkvm qemu
+all: libkvm ${QEMU_DIR}
ifneq '$(filter $(ARCH), x86_64 i386 ia64)' ''
all: $(if $(WANT_MODULE), kernel) user
endif
kcmd = $(if $(WANT_MODULE),,@\#)
-qemu kernel user libkvm:
+${QEMU_DIR} kernel user libkvm:
$(MAKE) -C $@
-qemu: libkvm
+${QEMU_DIR}: libkvm
ifneq '$(filter $(ARCH), i386 x86_64)' ''
-qemu: extboot
+${QEMU_DIR}: extboot
endif
ifneq '$(filter $(ARCH), powerpc ia64)' ''
-qemu: libfdt
+${QEMU_DIR}: libfdt
endif
user: libkvm
# sync if kernel/Makefile exists and if using --with-patched-kernel
-user libkvm qemu: header-sync-$(if $(wildcard kernel/Makefile),$(if
$(WANT_MODULE),n,y),n)
+user libkvm ${QEMU_DIR}: header-sync-$(if $(wildcard kernel/Makefile),$(if
$(WANT_MODULE),n,y),n)
header-sync-n:
@@ -42,18 +42,18 @@ header-sync-y:
bios:
$(MAKE) -C $@
- cp bios/BIOS-bochs-latest qemu/pc-bios/bios.bin
+ cp bios/BIOS-bochs-latest ${QEMU_DIR}/pc-bios/bios.bin
vgabios:
$(MAKE) -C $@
- cp vgabios/VGABIOS-lgpl-latest.bin qemu/pc-bios/vgabios.bin
- cp vgabios/VGABIOS-lgpl-latest.cirrus.bin
qemu/pc-bios/vgabios-cirrus.bin
+ cp vgabios/VGABIOS-lgpl-latest.bin ${QEMU_DIR}/pc-bios/vgabios.bin
+ cp vgabios/VGABIOS-lgpl-latest.cirrus.bin
${QEMU_DIR}/pc-bios/vgabios-cirrus.bin
extboot:
$(MAKE) -C $@
- if ! [ -f qemu/pc-bios/extboot.bin ] \
- || ! cmp -s qemu/pc-bios/extboot.bin extboot/extboot.bin; then \
- cp extboot/extboot.bin qemu/pc-bios/extboot.bin; \
+ if ! [ -f ${QEMU_DIR}/pc-bios/extboot.bin ] \
+ || ! cmp -s ${QEMU_DIR}/pc-bios/extboot.bin
extboot/extboot.bin; then \
+ cp extboot/extboot.bin ${QEMU_DIR}/pc-bios/extboot.bin; \
fi
libfdt:
$(MAKE) -C $@
@@ -75,7 +75,7 @@ install-rpm:
mkdir -p $(DESTDIR)/$(initdir)
mkdir -p $(DESTDIR)/$(utilsdir)
mkdir -p $(DESTDIR)/etc/udev/rules.d
- make -C qemu DESTDIR=$(DESTDIR)/ install
+ make -C ${QEMU_DIR} DESTDIR=$(DESTDIR)/ install
ln -sf /usr/kvm/bin/qemu-system-x86_64 $(DESTDIR)/$(bin)
install -m 755 kvm_stat $(DESTDIR)/$(bindir)/kvm_stat
cp scripts/kvm $(DESTDIR)/$(initdir)/kvm
@@ -85,7 +85,7 @@ install-rpm:
install:
$(kcmd)make -C kernel DESTDIR=$(DESTDIR) install
make -C libkvm DESTDIR=$(DESTDIR) install
- make -C qemu DESTDIR=$(DESTDIR) install
+ make -C ${QEMU_DIR} DESTDIR=$(DESTDIR) install
tmpspec = .tmp.kvm.spec
RPMTOPDIR = $$(pwd)/rpmtop
@@ -100,7 +100,7 @@ rpm:srpm
srpm:
mkdir -p $(RPMTOPDIR)/{SOURCES,SRPMS}
sed 's/^Release:.*/Release: $(rpmrelease)/' kvm.spec $(tmpspec)
- tar czf $(RPMTOPDIR)/SOURCES/kvm.tar.gz qemu
+ tar czf $(RPMTOPDIR)/SOURCES/kvm.tar.gz ${QEMU_DIR}
tar czf $(RPMTOPDIR)/SOURCES/user.tar.gz user
tar czf $(RPMTOPDIR)/SOURCES/libkvm.tar.gz libkvm
tar czf $(RPMTOPDIR)/SOURCES/kernel.tar.gz kernel
@@ -111,7 +111,7 @@ srpm:
$(RM) $(tmpspec)
clean:
- for i in $(if $(WANT_MODULE), kernel) user libkvm qemu libfdt; do \
+ for i in $(if $(WANT_MODULE), kernel) user libkvm ${QEMU_DIR} libfdt;
do \
make -C $$i clean; \
done
rm -f ./cscope.*
diff --git a/kvm/configure b/kvm/configure
index 249c743..f4873c1 100755
--- a/kvm/configure
+++
Re: [PATCH] qemu-kvm: configure script fixups after qemu-kvm reorg
Also for me running ./configure --kerneldir=/path/to/kernel at top dir works. (/path/to/kernel should be absolute though, otherwise kernel include path is incorrect). Ah, I didn't realise kvm/cofigure is obsolete. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-kvm.git now live
Cam Macdonell wrote: When I run configure on a clean copy I get this error: KVM support no - (field 'arch' has incomplete type, field 'arch' has incomplete type) I think it's caused by the include/asm and include-compat/asm symlinks not being created until the kvm/configure script runs. Should configure call the qemu-kvm/kvm configure script? There was a big mix-up in this area. I just pushed changes to make everything work as expected (./configure make - builds qemu) Is make supposed to build the host kernel module? No, the external module build will be moved to a different repository. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-kvm.git now live
Liu Yu-B13201 wrote: git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git Is there a http interface? http://www.kernel.org/pub/scm/virt/kvm/qemu-kvm.git -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: patch for virtual machine oriented scheduling(1)
alex wrote: Just wondering, was it not possible to introduce a new scheduling class in the current scheduler? My impression was that the current scheduler was fairly modular and should allow this. -Andrew The reasons are: 1. I am afraid that modifications to the Linux scheduler might cause unexpected effects, because it is a global one. True, extra care is needed. 2. an extra execution control solution like mine is the simplest one to implement. But it results in an overall more complex system. 3. As far as I can see, the benefit of replacing Linux scheduler only lies that as soon as a scheduling decision is made, it can be put into practice immediately. I think this benefit is neglectable. It also make maintenance easier, and brings the benefits to ordinary (non-kvm) processes. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kvm: x86: Fix MMU auditing code
Jan Kiszka wrote: Fix build breakage of hpa lookup in audit_mappings_page. Moreover, make this function robust against shadow_notrap_nonpresent_pte entries. Applied, thanks. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm-85 won't boot guests with virtio block device
Pauline Middelink wrote: Hi, To follow up on the issues with kvm-85 and libvirt I discovered the following issue: libvirt detects from the help of qemu which options it can give to qemu. (in this case obviously /usr/kvm/bin/qemu-system-x86_64 -help) If you look carefully to the output of the -help of qemu from kvm-84 and kvm-85, you will notice the boot flag to the -drive option has disappeared! Hence letting libvirt believe it isnt allowed to use it, hence the unable to boot error. A small patch which fixes the problem for me, is attached. It's missing the sacred signoff, can you add it please? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm-85 won't boot guests with virtio block device
Anthony Liguori wrote: Marcelo Tosatti wrote: Pauline, Good catch. Anthony, what is the reason for extboot not being upstream? Paul Brook nacked it. He didn't like that it was so x86 specific. Which part? The guest/host interface, or the option rom part? I think a better approach that would be mergable is something based on the FW config interface with the driver code living as a patch to the Bochs BIOS. The firmware interface is for reading configuration information. It's an idempotent, zero-latency interface. Let's not mix it with disk sector read/writes which is a completely different thing. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Debugging an inconsistent shadow page table
Jan Kiszka wrote: Hi, turning on MMU_DEBUG and AUDIT in arch/x86/kvm/mmu.c (and fixing a build error, patch will follow) I got this (and then a #GP :( - patch will follow): ... kvm_mmu_get_page: looking gfn 0 role f0120 kvm_mmu_get_page: found kvm_mmu_get_page: looking gfn 0 role f0220 kvm_mmu_get_page: found kvm_mmu_get_page: looking gfn 0 role f0320 kvm_mmu_get_page: found kvm_mmu_get_page: looking gfn e1f role e0044 kvm_mmu_get_page: adding gfn e1f role e0044 rmap_write_protect: spte 8100660a60f8 7ca98067 paging64_page_fault: addr 100105 err 19 audit_write_protection: (pre page fault) shadow page has writable mappings: gfn e1f role e0044 audit: (pre page fault) nontrapping pte in nonleaf level: levels 4 gva 80 level 4 pte 0 Is the last message indicating a problem? I get it very early during guest boot. oos_shadow is disabled. Yes. It means the guest will receive a page fault if is accesses anything this pte points to. Theoretically we could have made this work, but we never did. But the message is self-contradictory. Level 4 PTEs map 0.5TB each, and the gva mentioned isn't 0.5TB aligned. I'm currently trying to understand an obvious inconsistency in the pte describing a page of the virtio-net rx ring. On some guests with some qemu (upstream) command lines I can trigger this with '-smb /some/path' and then doing smbclient -L in the guest. Once the inconsistency slipped in, host and guest see different page contents and virtio-net stops to work. Very strange, but fortunately easily reproducible here. Any hints or debugging suggestions welcome! What type of inconsistency? pfn or flags? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] qemu-kvm: build system Add link to qemu
Jan Kiszka wrote: I'm getting closer to a working qemu-kvm, but there are still a few messy parts. The magic dance goes like this: Try a fresh fetch. ./configure make ought to work. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unable to boot guest on kernel 2.6.29.1 with kvm-84 or kvm-85
Kenni Lund wrote: Ok, but as I write in my message, I'm using the KVM modules from the latest upstream kernel, not the kvm-85 modules. According to the KVM download page, http://www.linux-kvm.org/page/Downloads, any kernel above 2.6.25 should work with the latest KVM userspace. This has been true until now in my case, but it breaks with 2.6.29.1 and that's the reason why I'm posting this bug report. Can you try a bisect? If you bisect only kvm patches it should be pretty fast. The following commands should do it: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6-stable.git (if you already have a linux git tree somewhere, do 'git remote add -f stable git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6-stable.git' instead) git bisect start v2.6.29.1 v2.6.28 -- arch/x86/kvm virt/kvm git will check out a test version, build it and test, and respond with 'git bisect bad' or 'git bisect good'. Rinse and repeat. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm-77 Excessive Disk Access causes real time clock hang!
Erik Rull wrote: Hi all, I'm running kvm-77 and windows xp as guest. When I start the defragmentation of the virtualized drive within the windows guest (well this is not a fine way, but it should work :-)), the real time clock starts hanging - I recognized that because some underlying hardware with own timers began to run out of synchronization. I did some research, took a stopwatch and measured against the system time. During the measurement of ~ 30 seconds I got a difference to the linux time (I just called watch -n 1 date which should come from the mainboard system time, doesn't it?) of ~10 seconds! This was the biggest difference I could measure, sometimes it was a little bit less. What's happening here? I reduced the io priority and the guest process priority to a very low one - it didn't help! Oh - I'm running the stuff on an Intel Core2Duo T5600 @ 1.83GHz with 2 Gig of RAM (Windows gets 1.5 Gig), the disk is an SATA with 40 Gigs. Are you using qcow2? In some cases qcow2 will stall the guest cpu. Note that defragmenting the guest drive may cause the qcow2 file to fragment even more, and will certainly increase its size. I recommend only defragmenting when using raw storage. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Makefile.target: remove second addition of msmouse.o to OBJS
Sebastian Herbszt wrote: msmouse.o is added twice to OBJS. Applied, thanks. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Assign the correct pci id range to virtio_pci
Pantelis Koukousoulas wrote: According to the file pci-ids.txt in qemu sources, the range of PCI device IDs assigned to virtio_pci is 0x1000 to 0x10ff, with a few subranges that have different rules regarding who can get an ID there and how. Nevertheless, the full range should be assigned to the generic virtio_pci driver, so that all corresponding devices, including the experimental/unreleased ones just work. Please copy the virtio maintainer (Rusty Russell ru...@rustcorp.com.au) on virtio guest patches. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Debugging an inconsistent shadow page table
Avi Kivity wrote: Jan Kiszka wrote: Hi, turning on MMU_DEBUG and AUDIT in arch/x86/kvm/mmu.c (and fixing a build error, patch will follow) I got this (and then a #GP :( - patch will follow): ... kvm_mmu_get_page: looking gfn 0 role f0120 kvm_mmu_get_page: found kvm_mmu_get_page: looking gfn 0 role f0220 kvm_mmu_get_page: found kvm_mmu_get_page: looking gfn 0 role f0320 kvm_mmu_get_page: found kvm_mmu_get_page: looking gfn e1f role e0044 kvm_mmu_get_page: adding gfn e1f role e0044 rmap_write_protect: spte 8100660a60f8 7ca98067 paging64_page_fault: addr 100105 err 19 audit_write_protection: (pre page fault) shadow page has writable mappings: gfn e1f role e0044 audit: (pre page fault) nontrapping pte in nonleaf level: levels 4 gva 80 level 4 pte 0 Is the last message indicating a problem? I get it very early during guest boot. oos_shadow is disabled. Yes. It means the guest will receive a page fault if is accesses anything this pte points to. Theoretically we could have made this work, but we never did. But the message is self-contradictory. Level 4 PTEs map 0.5TB each, and the gva mentioned isn't 0.5TB aligned. I'm currently trying to understand an obvious inconsistency in the pte describing a page of the virtio-net rx ring. On some guests with some qemu (upstream) command lines I can trigger this with '-smb /some/path' and then doing smbclient -L in the guest. Once the inconsistency slipped in, host and guest see different page contents and virtio-net stops to work. Very strange, but fortunately easily reproducible here. Any hints or debugging suggestions welcome! What type of inconsistency? pfn or flags? The former. Here is a before-after walk of the shadow and the host page table (format: entry address (entry value) ): [good] gva=88001ef22000: 2fc57000 - 2fc57880 (3d119027) - 3d119000 (5d9bf027) - 5d9bf7b8 (3d159027) - 3d159910 (2fbce063) - 2fbce000 = 01 00 07 00 hva=7f4665cac000: 701f4000 - 701f47f0 (5d925067) - 5d9258c8 (5d8c5067) - 5d8c5970 (3d2b4067) - 3d2b4560 (80002fbce067) - 80002fbce000 = 01 00 07 00 [bad] gva=88001ef22000: 2fc57000 - 2fc57880 (3d119027) - 3d119000 (5d9bf027) - 5d9bf7b8 (3d159027) - 3d159910 (2fbce063) - 2fbce000 = 01 00 0a 00 hva=7f4665cac000: 701f4000 - 701f47f0 (5d925067) - 5d9258c8 (5d8c5067) - 5d8c5970 (3d2b4067) - 3d2b4560 (80006576d067) - 80006576d000 = 01 00 10 00 That raise a question for a kvm-mmu newbie like me: If a page of the qemu process gets pushed around (here likely due to fork()-exec(smbd)-COW), how will kvm's shadow table catch up? Via MMU_NOTIFIER? I'm on a 2.6.25 kernel, and that means without CONFIG_MMU_NOTIFIER. So far I assumed that kernels without this feature do not work optimally, but they won't break my guests... Jan signature.asc Description: OpenPGP digital signature
Re: [PATCH] qemu-kvm: build system Add link to qemu
Avi Kivity wrote: Jan Kiszka wrote: I'm getting closer to a working qemu-kvm, but there are still a few messy parts. The magic dance goes like this: Try a fresh fetch. ./configure make ought to work. It's different, but not yet better: ... CCx86_64-softmmu/extboot.o CCx86_64-softmmu/i8254-kvm.o /data/qemu-kvm/hw/i8254-kvm.c: In function ‘kvm_pit_save’: /data/qemu-kvm/hw/i8254-kvm.c:36: error: storage size of ‘pit’ isn’t known /data/qemu-kvm/hw/i8254-kvm.c:41: warning: implicit declaration of function ‘kvm_get_pit’ /data/qemu-kvm/hw/i8254-kvm.c:46: error: dereferencing pointer to incomplete type ... with more verbosity: # make V=1 make -C x86_64-softmmu V=1 TARGET_DIR=x86_64-softmmu/ all make[1]: Entering directory `/data/qemu-kvm/x86_64-softmmu' gcc -I. -I.. -I/data/qemu-kvm/target-i386 -I/data/qemu-kvm -MMD -MT i8254-kvm.o -MP -DNEED_CPU_H -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D__user= -I/data/qemu-kvm/tcg -I/data/qemu-kvm/tcg/x86_64 -I/data/qemu-kvm/fpu -DHAS_AUDIO -DHAS_AUDIO_CHOICE -I/data/qemu-kvm/slirp -O2 -g -fno-strict-aliasing -Wall -Wundef -Wendif-labels -Wwrite-strings -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -I/data/qemu-kvm/kvm/libkvm -m64 -c -o i8254-kvm.o /data/qemu-kvm/hw/i8254-kvm.c /data/qemu-kvm/hw/i8254-kvm.c: In function ‘kvm_pit_save’: /data/qemu-kvm/hw/i8254-kvm.c:36: error: storage size of ‘pit’ isn’t known /data/qemu-kvm/hw/i8254-kvm.c:41: warning: implicit declaration of function ‘kvm_get_pit’ /data/qemu-kvm/hw/i8254-kvm.c:46: error: dereferencing pointer to incomplete type I bet it still picks up the host's kernel headers instead of the included ones... (you know, my host is ld :) ) Jan signature.asc Description: OpenPGP digital signature
Re: [PATCH] KVM: Enable snooping control for supported hardware
On Saturday 25 April 2009 06:37:17 Marcelo Tosatti wrote:
Sheng,
On Thu, Apr 23, 2009 at 04:43:02PM +0800, Sheng Yang wrote:
Memory aliases with different memory type is a problem for guest. For the
guest without assigned device, the memory type of guest memory would
always been the same as host(WB); but for the assigned device, some part
of memory may be used as DMA and then set to uncacheable memory
type(UC/WC), which would be a conflict of host memory type then be a
potential issue.
So the issue arises when the host attempts to access the DMA memory
(which is typed as uncached by the guest) with its WB typing (MTRR).
That would mean that host accesses of such memory are potentially stale?
(sorry, resend, HTML is enabled by mistake.)
Yes. In fact it's usually usable, though we still have to deal with some
exceptions.
Because 24.3.2 Creating and Using Cached Translation Information
mentions that with EPT enabled the guest will only use translations that
are EPTP-tagged, therefore with the correct (UC) typing, which you set
in the EPT pagetable?
With snooping control, we set it to be WB, as the same of host, for IOMMU
engine would deal with the cache issue if it used a DMA address. So direct
accessing to the memory also won't cause trouble.
Guest can set any memory as UC or WC, but we think the only purpose for this
is DMA/MMIO. MMIO address can be tell, and we ignored the setting to
DMA(that's means WB, and explained above), for it would handled by IOMMU
engine with snooping control feature.
More comments below.
Snooping control can guarantee the cache correctness of accessing the DMA
engine of VT-d.
Signed-off-by: Sheng Yang sh...@linux.intel.com
---
arch/x86/include/asm/kvm_host.h | 2 ++
arch/x86/kvm/mmu.c | 23 ---
virt/kvm/iommu.c | 27 ---
3 files changed, 46 insertions(+), 6 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h
b/arch/x86/include/asm/kvm_host.h index 3fc4623..d2da40f 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -397,6 +397,8 @@ struct kvm_arch{
struct list_head assigned_dev_head;
struct list_head oos_global_pages;
struct iommu_domain *iommu_domain;
+#define KVM_IOMMU_CACHE_COHERENCY 0x1
+ int iommu_flags;
struct kvm_pic *vpic;
struct kvm_ioapic *vioapic;
struct kvm_pit *vpit;
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 409d08e..1e63a87 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1713,10 +1713,27 @@ static int set_spte(struct kvm_vcpu *vcpu, u64
*shadow_pte, if (largepage)
spte |= PT_PAGE_SIZE_MASK;
if (mt_mask) {
+ /* For VT-d and EPT combination
+ * 1. MMIO: always map as UC
+ * 2. EPT without VT-d: always map as WB and set IGMT=1 to
+ * keep consistent with host MTRR
+ * 3. EPT with VT-d:
+ * a. VT-d with snooping control feature: keep consistent
+ * with host MTRR can guarantee the correctness
+ * b. VT-d without snooping control feature: can't
+ * guarantee the result, try to trust guest.
+ */
if (!kvm_is_mmio_pfn(pfn)) {
- mt_mask = get_memory_type(vcpu, gfn)
- kvm_x86_ops-get_mt_mask_shift();
- mt_mask |= VMX_EPT_IGMT_BIT;
+ if (vcpu-kvm-arch.iommu_domain
+ !(vcpu-kvm-arch.iommu_flags
+ KVM_IOMMU_CACHE_COHERENCY)) {
+ mt_mask = get_memory_type(vcpu, gfn)
+ kvm_x86_ops-get_mt_mask_shift();
+ } else {
+ mt_mask = MTRR_TYPE_WRBACK
+ kvm_x86_ops-get_mt_mask_shift();
+ mt_mask |= VMX_EPT_IGMT_BIT;
+ }
} else
mt_mask = MTRR_TYPE_UNCACHABLE
kvm_x86_ops-get_mt_mask_shift();
Can you move this to subarch code?
Perhaps replace get_mt_mask_shift with
u64 (*get_spte_mt_mask)(bool is_iommu_page);
And then just do
if (mt_mask)
spte |= kvm_x86_ops-get_spte_mt_mask();
Yeah. And sorry, I now remembered that you mentioned it before...
diff --git a/virt/kvm/iommu.c b/virt/kvm/iommu.c
index 4c40375..1514758 100644
--- a/virt/kvm/iommu.c
+++ b/virt/kvm/iommu.c
@@ -39,11 +39,16 @@ int kvm_iommu_map_pages(struct kvm *kvm,
pfn_t pfn;
int i, r = 0;
struct iommu_domain *domain = kvm-arch.iommu_domain;
+ int flags;
/* check if iommu exists and in use */
if (!domain)
return 0;
+ flags = IOMMU_READ | IOMMU_WRITE;
+ if (kvm-arch.iommu_flags KVM_IOMMU_CACHE_COHERENCY)
+ flags |= IOMMU_CACHE;
+
for (i = 0; i npages; i++) {
/* check if already mapped */
if (iommu_iova_to_phys(domain, gfn_to_gpa(gfn)))
@@ -53,8 +58,7 @@ int kvm_iommu_map_pages(struct kvm *kvm,
r = iommu_map_range(domain,
gfn_to_gpa(gfn),
pfn_to_hpa(pfn),
- PAGE_SIZE,
- IOMMU_READ | IOMMU_WRITE);
+ PAGE_SIZE, flags);
if (r) {
printk(KERN_ERR kvm_iommu_map_address:
iommu failed to map pfn=%lx\n, pfn);
@@ -88,7 +92,7 @@ int kvm_assign_device(struct kvm *kvm,
{
Re: Debugging an inconsistent shadow page table
On Sun, Apr 26, 2009 at 01:11:40PM +0200, Jan Kiszka wrote: That raise a question for a kvm-mmu newbie like me: If a page of the qemu process gets pushed around (here likely due to fork()-exec(smbd)-COW), how will kvm's shadow table catch up? Via MMU_NOTIFIER? I'm on a 2.6.25 kernel, and that means without CONFIG_MMU_NOTIFIER. So far I assumed that kernels without this feature do not work optimally, but they won't break my guests... Guest memory is not COWed on fork (madvise(MADV_DONTFORK)) -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] qemu-kvm: build system Add link to qemu
On Sun, Apr 26, 2009 at 01:33:37PM +0300, Avi Kivity wrote: Jan Kiszka wrote: I'm getting closer to a working qemu-kvm, but there are still a few messy parts. The magic dance goes like this: Try a fresh fetch. ./configure make ought to work. Works for me now. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Debugging an inconsistent shadow page table
Gleb Natapov wrote: On Sun, Apr 26, 2009 at 01:11:40PM +0200, Jan Kiszka wrote: That raise a question for a kvm-mmu newbie like me: If a page of the qemu process gets pushed around (here likely due to fork()-exec(smbd)-COW), how will kvm's shadow table catch up? Via MMU_NOTIFIER? I'm on a 2.6.25 kernel, and that means without CONFIG_MMU_NOTIFIER. So far I assumed that kernels without this feature do not work optimally, but they won't break my guests... Guest memory is not COWed on fork (madvise(MADV_DONTFORK)) Which isn't present in upstream. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Debugging an inconsistent shadow page table
Gleb Natapov wrote: On Sun, Apr 26, 2009 at 01:11:40PM +0200, Jan Kiszka wrote: That raise a question for a kvm-mmu newbie like me: If a page of the qemu process gets pushed around (here likely due to fork()-exec(smbd)-COW), how will kvm's shadow table catch up? Via MMU_NOTIFIER? I'm on a 2.6.25 kernel, and that means without CONFIG_MMU_NOTIFIER. So far I assumed that kernels without this feature do not work optimally, but they won't break my guests... Guest memory is not COWed on fork (madvise(MADV_DONTFORK)) Yeah... but that's missing upstream! Will cross-check and then post a fix for qemu. Out of curiosity: What's the mechanism to update the shadow table after swap-out/swap-in? Jan signature.asc Description: OpenPGP digital signature
Re: [PATCH] qemu-kvm: build system Add link to qemu
Jan Kiszka wrote: with more verbosity: # make V=1 make -C x86_64-softmmu V=1 TARGET_DIR=x86_64-softmmu/ all make[1]: Entering directory `/data/qemu-kvm/x86_64-softmmu' gcc -I. -I.. -I/data/qemu-kvm/target-i386 -I/data/qemu-kvm -MMD -MT i8254-kvm.o -MP -DNEED_CPU_H -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D__user= -I/data/qemu-kvm/tcg -I/data/qemu-kvm/tcg/x86_64 -I/data/qemu-kvm/fpu -DHAS_AUDIO -DHAS_AUDIO_CHOICE -I/data/qemu-kvm/slirp -O2 -g -fno-strict-aliasing -Wall -Wundef -Wendif-labels -Wwrite-strings -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -I/data/qemu-kvm/kvm/libkvm -m64 -c -o i8254-kvm.o /data/qemu-kvm/hw/i8254-kvm.c /data/qemu-kvm/hw/i8254-kvm.c: In function ‘kvm_pit_save’: /data/qemu-kvm/hw/i8254-kvm.c:36: error: storage size of ‘pit’ isn’t known /data/qemu-kvm/hw/i8254-kvm.c:41: warning: implicit declaration of function ‘kvm_get_pit’ /data/qemu-kvm/hw/i8254-kvm.c:46: error: dereferencing pointer to incomplete type I bet it still picks up the host's kernel headers instead of the included ones... (you know, my host is ld :) ) Yes. Pull again, I added i8254.c to the list of files which have their #includes hacked to add kvm/kernel/... . -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Debugging an inconsistent shadow page table
On Sun, Apr 26, 2009 at 01:36:22PM +0200, Jan Kiszka wrote: Gleb Natapov wrote: On Sun, Apr 26, 2009 at 01:11:40PM +0200, Jan Kiszka wrote: That raise a question for a kvm-mmu newbie like me: If a page of the qemu process gets pushed around (here likely due to fork()-exec(smbd)-COW), how will kvm's shadow table catch up? Via MMU_NOTIFIER? I'm on a 2.6.25 kernel, and that means without CONFIG_MMU_NOTIFIER. So far I assumed that kernels without this feature do not work optimally, but they won't break my guests... Guest memory is not COWed on fork (madvise(MADV_DONTFORK)) Yeah... but that's missing upstream! Will cross-check and then post a fix for qemu. Out of curiosity: What's the mechanism to update the shadow table after swap-out/swap-in? I don't think guest memory is swappable without mmu notifiers. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Debugging an inconsistent shadow page table
Gleb Natapov wrote: On Sun, Apr 26, 2009 at 01:36:22PM +0200, Jan Kiszka wrote: Gleb Natapov wrote: On Sun, Apr 26, 2009 at 01:11:40PM +0200, Jan Kiszka wrote: That raise a question for a kvm-mmu newbie like me: If a page of the qemu process gets pushed around (here likely due to fork()-exec(smbd)-COW), how will kvm's shadow table catch up? Via MMU_NOTIFIER? I'm on a 2.6.25 kernel, and that means without CONFIG_MMU_NOTIFIER. So far I assumed that kernels without this feature do not work optimally, but they won't break my guests... Guest memory is not COWed on fork (madvise(MADV_DONTFORK)) Yeah... but that's missing upstream! Will cross-check and then post a fix for qemu. Out of curiosity: What's the mechanism to update the shadow table after swap-out/swap-in? I don't think guest memory is swappable without mmu notifiers. Given the experience with COW: How is this ensured, or where is this done upstream? Jan signature.asc Description: OpenPGP digital signature
Re: Debugging an inconsistent shadow page table
Jan Kiszka wrote: Out of curiosity: What's the mechanism to update the shadow table after swap-out/swap-in? With mmu notifiers, the kernel informs kvm that a host pte has been invalidated, kvm looks in its reverse mappings and drops any sptes that correspond to the same hva. Without mmu notifiers, the page reference count is kept elevated, so the kernel can't swap anything which has an spte pointing to it. In both cases, the spte is reestablished on first guest access (which may or may not be immediately after swapin). -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] thinko fix: move memset to after mmap failure check
By the time we've done a memset, it's too late to
check the pointer for MAP_FAILED value. Let's compare
to MAP_FAILED first.
Signed-off-by: Michael S. Tsikirn m...@redhat.com
---
Noticed this when reading the code.
Makes sense, does it not?
hw/device-assignment.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/device-assignment.c b/hw/device-assignment.c
index 1f0a1a7..0a5f850 100644
--- a/hw/device-assignment.c
+++ b/hw/device-assignment.c
@@ -1087,12 +1087,12 @@ static int
assigned_dev_register_msix_mmio(AssignedDevice *dev)
dev-msix_table_page = mmap(NULL, 0x1000,
PROT_READ|PROT_WRITE,
MAP_ANONYMOUS|MAP_PRIVATE, 0, 0);
-memset(dev-msix_table_page, 0, 0x1000);
if (dev-msix_table_page == MAP_FAILED) {
fprintf(stderr, fail allocate msix_table_page! %s\n,
strerror(errno));
return -EFAULT;
}
+memset(dev-msix_table_page, 0, 0x1000);
dev-mmio_index = cpu_register_io_memory(0,
msix_mmio_read, msix_mmio_write, dev);
return 0;
--
1.6.0.6
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] thinko fix: move memset to after mmap failure check
Michael S. Tsirkin wrote: By the time we've done a memset, it's too late to check the pointer for MAP_FAILED value. Let's compare to MAP_FAILED first. Applied, thanks. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] qemu-kvm: build system Add link to qemu
Avi Kivity wrote: Jan Kiszka wrote: with more verbosity: # make V=1 make -C x86_64-softmmu V=1 TARGET_DIR=x86_64-softmmu/ all make[1]: Entering directory `/data/qemu-kvm/x86_64-softmmu' gcc -I. -I.. -I/data/qemu-kvm/target-i386 -I/data/qemu-kvm -MMD -MT i8254-kvm.o -MP -DNEED_CPU_H -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D__user= -I/data/qemu-kvm/tcg -I/data/qemu-kvm/tcg/x86_64 -I/data/qemu-kvm/fpu -DHAS_AUDIO -DHAS_AUDIO_CHOICE -I/data/qemu-kvm/slirp -O2 -g -fno-strict-aliasing -Wall -Wundef -Wendif-labels -Wwrite-strings -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -I/data/qemu-kvm/kvm/libkvm -m64 -c -o i8254-kvm.o /data/qemu-kvm/hw/i8254-kvm.c /data/qemu-kvm/hw/i8254-kvm.c: In function ‘kvm_pit_save’: /data/qemu-kvm/hw/i8254-kvm.c:36: error: storage size of ‘pit’ isn’t known /data/qemu-kvm/hw/i8254-kvm.c:41: warning: implicit declaration of function ‘kvm_get_pit’ /data/qemu-kvm/hw/i8254-kvm.c:46: error: dereferencing pointer to incomplete type I bet it still picks up the host's kernel headers instead of the included ones... (you know, my host is ld :) ) Yes. Pull again, I added i8254.c to the list of files which have their #includes hacked to add kvm/kernel/... . No change here. Jan signature.asc Description: OpenPGP digital signature
Re: [PATCH] qemu-kvm: build system Add link to qemu
Jan Kiszka wrote: Yes. Pull again, I added i8254.c to the list of files which have their #includes hacked to add kvm/kernel/... . No change here. Drat, it's i8254-kvm.c, not i8254.c. Please try again. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] qemu-kvm: build system Add link to qemu
Avi Kivity wrote: Jan Kiszka wrote: Yes. Pull again, I added i8254.c to the list of files which have their #includes hacked to add kvm/kernel/... . No change here. Drat, it's i8254-kvm.c, not i8254.c. Please try again. OK, works now, thanks. Next topic: for kernel module build, I need to cd to kvm/kernel, run configure and then make, right? What's the kvm/configure now for? Looks at least broken ATM. Jan signature.asc Description: OpenPGP digital signature
Re: [PATCH] Assign the correct pci id range to virtio_pci
Please copy the virtio maintainer (Rusty Russell ru...@rustcorp.com.au) on virtio guest patches. Well, for now the issue is whether my understanding of qemu/pci-ids.txt and the comment in virtio_pci.c that both say that the full 0x1000 - 0x10ff range of PCI device IDs is donated for virtio_pci devices is correct. If that is true, virtio_pci only claiming 0x1000 - 0x103f doesn't make much sense to me and looks more like a typo, because there is no explicit justification (perhaps in a comment) either. (3f does not even show up in pci-ids.txt). The ranges mentioned there are: 1000 - 10ef (one needs to contact Gerd to reserve an unallocated ID in that range) and 10f0 - 10ff (available for experimental devices, a random ID in that range can be used during private development without asking anyone as long as you are not shipping anything using it) the range ef - f0 (exclusive) is reserved. From the above, my understanding is that virtio_pci should definitely claim at least 00 - ef and most likely it should claim f0-ff too. The only reason not to claim some IDs is to allow someone to have virtio PCI devices that do *not* use the virtio_pci infrastructure but why would we want that? The reason I asked here (I guess qemu-devel would be just as relevant or more, but it has more traffic) is because Anthony is the author of virtio_pci.c (at least it looks like it) so hopefully he knows if that 3f was a typo or not and Gerd is responsible for the PCI ID namespace management so he knows if pci-ids.txt is correct or not. Once this issue is clarified I 'm happy to resend the same or an improved version of the patch as appropriate. Thanks, Pantelis -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] qemu-kvm: build system Add link to qemu
Jan Kiszka wrote: Next topic: for kernel module build, I need to cd to kvm/kernel, run configure and then make, right? What's the kvm/configure now for? Looks at least broken ATM. I'm going to split the external kernel module support code into its own repository, which will include kvm.git by means of gitmodules(5). So we will have: qemu-kvm.git: standalone repo for qemu kvm-kmod.git: standalone repo for kvm external module The only time these repos will interact is when I generate kvm-xx tarballs. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
qemu-kvm: Fix some libkvm warnings
Signed-off-by: Jan Kiszka jan.kis...@web.de
diff --git a/kvm/libkvm/kvm-common.h b/kvm/libkvm/kvm-common.h
index 96361e8..591fb53 100644
--- a/kvm/libkvm/kvm-common.h
+++ b/kvm/libkvm/kvm-common.h
@@ -22,7 +22,7 @@
#define KVM_MAX_NUM_MEM_REGIONS 1u
#define MAX_VCPUS 64
#define LIBKVM_S390_ORIGIN (0UL)
-#elif __ia64__
+#elif defined(__ia64__)
#define KVM_MAX_NUM_MEM_REGIONS 32u
#define MAX_VCPUS 256
#else
diff --git a/kvm/libkvm/libkvm-x86.c b/kvm/libkvm/libkvm-x86.c
index 2fc4fce..df8cc81 100644
--- a/kvm/libkvm/libkvm-x86.c
+++ b/kvm/libkvm/libkvm-x86.c
@@ -52,7 +52,7 @@ static int kvm_init_tss(kvm_context_t kvm)
return 0;
}
-int kvm_create_pit(kvm_context_t kvm)
+static int kvm_create_pit(kvm_context_t kvm)
{
#ifdef KVM_CAP_PIT
int r;
diff --git a/kvm/libkvm/libkvm.c b/kvm/libkvm/libkvm.c
index 0610e3f..6751dc5 100644
--- a/kvm/libkvm/libkvm.c
+++ b/kvm/libkvm/libkvm.c
@@ -1158,6 +1158,19 @@ static int kvm_old_assign_irq(kvm_context_t kvm,
return ret;
}
+int kvm_destroy_memory_region_works(kvm_context_t kvm)
+{
+ int ret = 0;
+
+#ifdef KVM_CAP_DESTROY_MEMORY_REGION_WORKS
+ ret = ioctl(kvm-fd, KVM_CHECK_EXTENSION,
+ KVM_CAP_DESTROY_MEMORY_REGION_WORKS);
+ if (ret = 0)
+ ret = 0;
+#endif
+ return ret;
+}
+
#ifdef KVM_CAP_ASSIGN_DEV_IRQ
int kvm_assign_irq(kvm_context_t kvm,
struct kvm_assigned_irq *assigned_irq)
@@ -1209,19 +1222,7 @@ int kvm_deassign_pci_device(kvm_context_t kvm,
}
#endif
-int kvm_destroy_memory_region_works(kvm_context_t kvm)
-{
- int ret = 0;
-
-#ifdef KVM_CAP_DESTROY_MEMORY_REGION_WORKS
- ret = ioctl(kvm-fd, KVM_CHECK_EXTENSION,
- KVM_CAP_DESTROY_MEMORY_REGION_WORKS);
- if (ret = 0)
- ret = 0;
-#endif
- return ret;
-}
-
+#ifdef KVM_CAP_PIT
int kvm_reinject_control(kvm_context_t kvm, int pit_reinject)
{
#ifdef KVM_CAP_REINJECT_CONTROL
@@ -1240,6 +1241,7 @@ int kvm_reinject_control(kvm_context_t kvm, int
pit_reinject)
#endif
return -ENOSYS;
}
+#endif
int kvm_has_gsi_routing(kvm_context_t kvm)
{
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] Assign the correct pci id range to virtio_pci
Pantelis Koukousoulas wrote: Please copy the virtio maintainer (Rusty Russell ru...@rustcorp.com.au) on virtio guest patches. Well, for now the issue is whether my understanding of qemu/pci-ids.txt and the comment in virtio_pci.c that both say that the full 0x1000 - 0x10ff range of PCI device IDs is donated for virtio_pci devices is correct. 0x1000-0x10ff is correct. I don't know where the 0x103f came from. Rusty? If that is true, virtio_pci only claiming 0x1000 - 0x103f doesn't make much sense to me and looks more like a typo, because there is no explicit justification (perhaps in a comment) either. (3f does not even show up in pci-ids.txt). The ranges mentioned there are: 1000 - 10ef (one needs to contact Gerd to reserve an unallocated ID in that range) and 10f0 - 10ff (available for experimental devices, a random ID in that range can be used during private development without asking anyone as long as you are not shipping anything using it) the range ef - f0 (exclusive) is reserved. From the above, my understanding is that virtio_pci should definitely claim at least 00 - ef and most likely it should claim f0-ff too. The only reason not to claim some IDs is to allow someone to have virtio PCI devices that do *not* use the virtio_pci infrastructure but why would we want that? We wouldn't. If it isn't a virtio-pci device, it should leech an ID from someone else. The reason I asked here (I guess qemu-devel would be just as relevant or more, but it has more traffic) is because Anthony is the author of virtio_pci.c (at least it looks like it) Added cc. so hopefully he knows if that 3f was a typo or not and Gerd is responsible for the PCI ID namespace management so he knows if pci-ids.txt is correct or not. Once this issue is clarified I 'm happy to resend the same or an improved version of the patch as appropriate. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OT: Intel-Matrix for VT-capability?
On Friday 24 April 2009, Oliver Rath wrote: Hi, Im looking for an abillity seeing vt-capability of Intel-processors by there name :-/ I.e. T7200 has vt, T3400 has not. Exists a rule for the naming scheme seeing vt-capability? Alternatively, exists a matrix anywhere in the net for this? Im tired searching for vt-capability for every new OEM-intel-processor. On intel-site _did_ exist a pdf-table (not all processors, but most of T-series), but it seems to be removed. http://en.wikipedia.org/wiki/List_of_Intel_Core_2_microprocessors is quite good here. As a rule of thumb, anything higher than 6000 will have VT, anything below 6000 will not. Interesting exceptions are Doesn't have VT: E7300, Q8200, Q8400, E8190 Does have VT: T5600, U2xxx, SU3xxx, Celeron 900 (?) May have VT[1]: T5500, Q8300, E7400, E7500, E5300, E5400 Interestingly, when you look at the price list, you will see that *all* processors that are not being obviously phased out (i.e. have the same or higher price as a superior model) and carry a Pentium or Core 2 name come with VT enabled. I think it's very unlikely that they will come out with anything new that does not run KVM. Arnd [1] http://www.heise.de/newsticker/Auch-billigere-Intel-Prozessoren-bald-mit-Virtualisierungsbefehlen--/meldung/136306 [2] http://www.intc.com/priceList.cfm -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unable to boot guest on kernel 2.6.29.1 with kvm-84 or kvm-85
Can you try a bisect? I confirm having the same trouble with kvm. Bisect with the vanilla kernel gave the following result: (f438349...|BISECTING)$ git bisect log # bad: [8d7bff2d72660d9d60aa371ae3d1356bbf329a09] Linux 2.6.29.1 # good: [8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84] Linux 2.6.29 git bisect start 'v2.6.29.1' 'v2.6.29' '--' 'arch/x86/kvm/' 'virt/kvm/' # bad: [f438349efb8247cd0c1d453a4131b1f801bf5691] KVM: VMX: Don't allow uninhibited access to EFER on i386 git bisect bad f438349efb8247cd0c1d453a4131b1f801bf5691 Are the commits splitted more precisely in kvm.git? -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm-77 Excessive Disk Access causes real time clock hang!
Hi Avi, Avi Kivity wrote: Are you using qcow2? In some cases qcow2 will stall the guest cpu. Note that defragmenting the guest drive may cause the qcow2 file to fragment even more, and will certainly increase its size. I recommend only defragmenting when using raw storage. I don't think so. I created a partition on my host real harddrive and provided this partition to my windows guest. If you have an idea, which virtualized drive system could be the fastest (except giving a complete disk to the guest), your comments are welcome :-) Best regards, Erik -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Assign the correct pci id range to virtio_pci
On Sun, 26 Apr 2009 10:19:16 pm Avi Kivity wrote: Pantelis Koukousoulas wrote: Please copy the virtio maintainer (Rusty Russell ru...@rustcorp.com.au) on virtio guest patches. Well, for now the issue is whether my understanding of qemu/pci-ids.txt and the comment in virtio_pci.c that both say that the full 0x1000 - 0x10ff range of PCI device IDs is donated for virtio_pci devices is correct. 0x1000-0x10ff is correct. I don't know where the 0x103f came from. Rusty? We decided to hedge our bets in case we broke the ABI. AFAICT there's no reason to claim the full range until we need it. Wake me when device #32 is used :) Rusty. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Assign the correct pci id range to virtio_pci
Rusty Russell wrote:
On Sun, 26 Apr 2009 10:19:16 pm Avi Kivity wrote:
Pantelis Koukousoulas wrote:
Please copy the virtio maintainer (Rusty Russell ru...@rustcorp.com.au) on
virtio guest patches.
Well, for now the issue is whether my understanding of qemu/pci-ids.txt and the
comment in virtio_pci.c that both say that the full 0x1000 - 0x10ff range of PCI
device IDs is donated for virtio_pci devices is correct.
0x1000-0x10ff is correct. I don't know where the 0x103f came from. Rusty?
We decided to hedge our bets in case we broke the ABI.
AFAICT there's no reason to claim the full range until we need it. Wake me
when device #32 is used :)
Would be good to at least include the experiment range in case people
are making third-party virtio modules and want to play around without
replacing virtio-{pci,*}.
Regards,
Anthony Liguori
Rusty.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Re: Is guest OS oriented scheduling welcome?
alex wrote: On Fri, Apr 24, 2009 at 3:49 PM, alex tomorrowanew...@gmail.com wrote: I tested the CFS in detail, according to Documentation/sched-design-CFS.txt I found it does not work. Is this a bug to CFS? I reviewed my experiment, and found a mistake there. The CFS is OK. But the information shown from 'top' reveals that the jitter is somewhat great. And I found CFS does not reserve cpu usage. That is to say, when none else is active, the active one can take all the cpu time. this statement holds. From this threads: http://markmail.org/message/rmww5bbxkdcpoqjm https://lists.linux-foundation.org/pipermail/containers/2008-August/012128.html http://lkml.indiana.edu/hypermail/linux/kernel/0606.1/2270.html CFS doesn't support hard-cpu-limit, like cap in credit scheduler. There are some patches posted in LKML http://markmail.org/message/fuiq2dn3h74yj4zg, but applied on ooold scheduler. Will you add hard-cpu-limit feature into CFS?:) I think it's usefull. Best Regards, Disheng, Su-- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Assign the correct pci id range to virtio_pci
On Mon, Apr 27, 2009 at 3:44 AM, Anthony Liguori anth...@codemonkey.ws wrote:
Rusty Russell wrote:
On Sun, 26 Apr 2009 10:19:16 pm Avi Kivity wrote:
0x1000-0x10ff is correct. I don't know where the 0x103f came from.
Rusty?
We decided to hedge our bets in case we broke the ABI.
AFAICT there's no reason to claim the full range until we need it. Wake
me
when device #32 is used :)
Would be good to at least include the experiment range in case people are
making third-party virtio modules and want to play around without replacing
virtio-{pci,*}.
I 'd be happy with a simple comment explaining the 0x103f (e.g.,
/* Not yet using the full 0x1000 - 0x10ef to hedge our bets in case we
broke the ABI.*/
as explained above)
plus including the experimental range as Anthony proposed.
The reason I came across this was I was playing with such a simple third party
module and after reading pci-ids.txt I decided to choose 0x10f5 for myself
only to find out that virtio_pci (and therefore my driver too) would
not load any more.
Thanks,
Pantelis
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] qemu-kvm: configure script fixups after qemu-kvm reorg
Make kvm configure script and Makefile work again after things have been
moved around, so that you can do 'cd kvm ./configure' to get a
kvm-enabled qemu.
Also, guard against infinite recursion in case of 'cd' commands failing.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
--
On Thu, Apr 23, 2009 at 06:40:00PM +0300, Avi Kivity wrote:
After a lengthy testing phase, qemu-kvm.git has replaced
kvm-userspace.git as the source repository for kvm userspace development.
This patch makes cd kvm; ./configure work.
Is this the expected mode of operation?
diff --git a/kvm/Makefile b/kvm/Makefile
index 617504c..1ef6493 100644
--- a/kvm/Makefile
+++ b/kvm/Makefile
@@ -7,29 +7,29 @@ rpmrelease = devel
sane-arch = $(subst i386,x86,$(subst x86_64,x86,$(subst s390x,s390,$(ARCH
-.PHONY: kernel user libkvm qemu bios vgabios extboot clean libfdt cscope
+.PHONY: kernel user libkvm ${QEMU_DIR} bios vgabios extboot clean libfdt cscope
-all: libkvm qemu
+all: libkvm ${QEMU_DIR}
ifneq '$(filter $(ARCH), x86_64 i386 ia64)' ''
all: $(if $(WANT_MODULE), kernel) user
endif
kcmd = $(if $(WANT_MODULE),,@\#)
-qemu kernel user libkvm:
+${QEMU_DIR} kernel user libkvm:
$(MAKE) -C $@
-qemu: libkvm
+${QEMU_DIR}: libkvm
ifneq '$(filter $(ARCH), i386 x86_64)' ''
-qemu: extboot
+${QEMU_DIR}: extboot
endif
ifneq '$(filter $(ARCH), powerpc ia64)' ''
-qemu: libfdt
+${QEMU_DIR}: libfdt
endif
user: libkvm
# sync if kernel/Makefile exists and if using --with-patched-kernel
-user libkvm qemu: header-sync-$(if $(wildcard kernel/Makefile),$(if
$(WANT_MODULE),n,y),n)
+user libkvm ${QEMU_DIR}: header-sync-$(if $(wildcard kernel/Makefile),$(if
$(WANT_MODULE),n,y),n)
header-sync-n:
@@ -42,18 +42,18 @@ header-sync-y:
bios:
$(MAKE) -C $@
- cp bios/BIOS-bochs-latest qemu/pc-bios/bios.bin
+ cp bios/BIOS-bochs-latest ${QEMU_DIR}/pc-bios/bios.bin
vgabios:
$(MAKE) -C $@
- cp vgabios/VGABIOS-lgpl-latest.bin qemu/pc-bios/vgabios.bin
- cp vgabios/VGABIOS-lgpl-latest.cirrus.bin
qemu/pc-bios/vgabios-cirrus.bin
+ cp vgabios/VGABIOS-lgpl-latest.bin ${QEMU_DIR}/pc-bios/vgabios.bin
+ cp vgabios/VGABIOS-lgpl-latest.cirrus.bin
${QEMU_DIR}/pc-bios/vgabios-cirrus.bin
extboot:
$(MAKE) -C $@
- if ! [ -f qemu/pc-bios/extboot.bin ] \
- || ! cmp -s qemu/pc-bios/extboot.bin extboot/extboot.bin; then \
- cp extboot/extboot.bin qemu/pc-bios/extboot.bin; \
+ if ! [ -f ${QEMU_DIR}/pc-bios/extboot.bin ] \
+ || ! cmp -s ${QEMU_DIR}/pc-bios/extboot.bin extboot/extboot.bin;
then \
+ cp extboot/extboot.bin ${QEMU_DIR}/pc-bios/extboot.bin; \
fi
libfdt:
$(MAKE) -C $@
@@ -75,7 +75,7 @@ install-rpm:
mkdir -p $(DESTDIR)/$(initdir)
mkdir -p $(DESTDIR)/$(utilsdir)
mkdir -p $(DESTDIR)/etc/udev/rules.d
- make -C qemu DESTDIR=$(DESTDIR)/ install
+ make -C ${QEMU_DIR} DESTDIR=$(DESTDIR)/ install
ln -sf /usr/kvm/bin/qemu-system-x86_64 $(DESTDIR)/$(bin)
install -m 755 kvm_stat $(DESTDIR)/$(bindir)/kvm_stat
cp scripts/kvm $(DESTDIR)/$(initdir)/kvm
@@ -85,7 +85,7 @@ install-rpm:
install:
$(kcmd)make -C kernel DESTDIR=$(DESTDIR) install
make -C libkvm DESTDIR=$(DESTDIR) install
- make -C qemu DESTDIR=$(DESTDIR) install
+ make -C ${QEMU_DIR} DESTDIR=$(DESTDIR) install
tmpspec = .tmp.kvm.spec
RPMTOPDIR = $$(pwd)/rpmtop
@@ -100,7 +100,7 @@ rpm:srpm
srpm:
mkdir -p $(RPMTOPDIR)/{SOURCES,SRPMS}
sed 's/^Release:.*/Release: $(rpmrelease)/' kvm.spec $(tmpspec)
- tar czf $(RPMTOPDIR)/SOURCES/kvm.tar.gz qemu
+ tar czf $(RPMTOPDIR)/SOURCES/kvm.tar.gz ${QEMU_DIR}
tar czf $(RPMTOPDIR)/SOURCES/user.tar.gz user
tar czf $(RPMTOPDIR)/SOURCES/libkvm.tar.gz libkvm
tar czf $(RPMTOPDIR)/SOURCES/kernel.tar.gz kernel
@@ -111,7 +111,7 @@ srpm:
$(RM) $(tmpspec)
clean:
- for i in $(if $(WANT_MODULE), kernel) user libkvm qemu libfdt; do \
+ for i in $(if $(WANT_MODULE), kernel) user libkvm ${QEMU_DIR} libfdt;
do \
make -C $$i clean; \
done
rm -f ./cscope.*
diff --git a/kvm/configure b/kvm/configure
index 249c743..f4873c1 100755
--- a/kvm/configure
+++ b/kvm/configure
@@ -14,6 +14,7 @@ qemu_opts=()
cross_prefix=
arch=`uname -m`
target_exec=
+qemu_directory=$PWD/..
# don't use uname if kerneldir is set
no_uname=
if [ -z TMPDIR ] ; then
@@ -41,8 +42,7 @@ usage() {
Any additional option is given to qemu's configure verbatim; including:
EOF
-cd qemu
-./configure --help | egrep enable-|disable- \
+cd $qemu_directory ./configure --help | egrep enable-|disable- \
| grep -v user | grep -v system | grep -v kqemu | grep -v kvm \
| sed -e s/^ //g \
| sed -es/ enable/enable/g | sed -e s/ disable/disable/g
@@ -117,7 +117,7 @@ processor=${arch#*-}
Re: [PATCH] qemu-kvm: configure script fixups after qemu-kvm reorg
On Sun, Apr 26, 2009 at 10:38:39AM +0300, Michael S. Tsirkin wrote:
Make kvm configure script and Makefile work again after things have been
moved around, so that you can do 'cd kvm ./configure' to get a
kvm-enabled qemu.
Also, guard against infinite recursion in case of 'cd' commands failing.
I suppose changes under kvm/kernel/* are not relevant to this goal. Also
for me running ./configure --kerneldir=/path/to/kernel at top dir works.
(/path/to/kernel should be absolute though, otherwise kernel include path
is incorrect).
Signed-off-by: Michael S. Tsirkin m...@redhat.com
--
On Thu, Apr 23, 2009 at 06:40:00PM +0300, Avi Kivity wrote:
After a lengthy testing phase, qemu-kvm.git has replaced
kvm-userspace.git as the source repository for kvm userspace development.
This patch makes cd kvm; ./configure work.
Is this the expected mode of operation?
diff --git a/kvm/Makefile b/kvm/Makefile
index 617504c..1ef6493 100644
--- a/kvm/Makefile
+++ b/kvm/Makefile
@@ -7,29 +7,29 @@ rpmrelease = devel
sane-arch = $(subst i386,x86,$(subst x86_64,x86,$(subst s390x,s390,$(ARCH
-.PHONY: kernel user libkvm qemu bios vgabios extboot clean libfdt cscope
+.PHONY: kernel user libkvm ${QEMU_DIR} bios vgabios extboot clean libfdt
cscope
-all: libkvm qemu
+all: libkvm ${QEMU_DIR}
ifneq '$(filter $(ARCH), x86_64 i386 ia64)' ''
all: $(if $(WANT_MODULE), kernel) user
endif
kcmd = $(if $(WANT_MODULE),,@\#)
-qemu kernel user libkvm:
+${QEMU_DIR} kernel user libkvm:
$(MAKE) -C $@
-qemu: libkvm
+${QEMU_DIR}: libkvm
ifneq '$(filter $(ARCH), i386 x86_64)' ''
-qemu: extboot
+${QEMU_DIR}: extboot
endif
ifneq '$(filter $(ARCH), powerpc ia64)' ''
-qemu: libfdt
+${QEMU_DIR}: libfdt
endif
user: libkvm
# sync if kernel/Makefile exists and if using --with-patched-kernel
-user libkvm qemu: header-sync-$(if $(wildcard kernel/Makefile),$(if
$(WANT_MODULE),n,y),n)
+user libkvm ${QEMU_DIR}: header-sync-$(if $(wildcard kernel/Makefile),$(if
$(WANT_MODULE),n,y),n)
header-sync-n:
@@ -42,18 +42,18 @@ header-sync-y:
bios:
$(MAKE) -C $@
- cp bios/BIOS-bochs-latest qemu/pc-bios/bios.bin
+ cp bios/BIOS-bochs-latest ${QEMU_DIR}/pc-bios/bios.bin
vgabios:
$(MAKE) -C $@
- cp vgabios/VGABIOS-lgpl-latest.bin qemu/pc-bios/vgabios.bin
- cp vgabios/VGABIOS-lgpl-latest.cirrus.bin
qemu/pc-bios/vgabios-cirrus.bin
+ cp vgabios/VGABIOS-lgpl-latest.bin ${QEMU_DIR}/pc-bios/vgabios.bin
+ cp vgabios/VGABIOS-lgpl-latest.cirrus.bin
${QEMU_DIR}/pc-bios/vgabios-cirrus.bin
extboot:
$(MAKE) -C $@
- if ! [ -f qemu/pc-bios/extboot.bin ] \
- || ! cmp -s qemu/pc-bios/extboot.bin extboot/extboot.bin; then \
- cp extboot/extboot.bin qemu/pc-bios/extboot.bin; \
+ if ! [ -f ${QEMU_DIR}/pc-bios/extboot.bin ] \
+ || ! cmp -s ${QEMU_DIR}/pc-bios/extboot.bin extboot/extboot.bin;
then \
+ cp extboot/extboot.bin ${QEMU_DIR}/pc-bios/extboot.bin; \
fi
libfdt:
$(MAKE) -C $@
@@ -75,7 +75,7 @@ install-rpm:
mkdir -p $(DESTDIR)/$(initdir)
mkdir -p $(DESTDIR)/$(utilsdir)
mkdir -p $(DESTDIR)/etc/udev/rules.d
- make -C qemu DESTDIR=$(DESTDIR)/ install
+ make -C ${QEMU_DIR} DESTDIR=$(DESTDIR)/ install
ln -sf /usr/kvm/bin/qemu-system-x86_64 $(DESTDIR)/$(bin)
install -m 755 kvm_stat $(DESTDIR)/$(bindir)/kvm_stat
cp scripts/kvm $(DESTDIR)/$(initdir)/kvm
@@ -85,7 +85,7 @@ install-rpm:
install:
$(kcmd)make -C kernel DESTDIR=$(DESTDIR) install
make -C libkvm DESTDIR=$(DESTDIR) install
- make -C qemu DESTDIR=$(DESTDIR) install
+ make -C ${QEMU_DIR} DESTDIR=$(DESTDIR) install
tmpspec = .tmp.kvm.spec
RPMTOPDIR = $$(pwd)/rpmtop
@@ -100,7 +100,7 @@ rpm: srpm
srpm:
mkdir -p $(RPMTOPDIR)/{SOURCES,SRPMS}
sed 's/^Release:.*/Release: $(rpmrelease)/' kvm.spec $(tmpspec)
- tar czf $(RPMTOPDIR)/SOURCES/kvm.tar.gz qemu
+ tar czf $(RPMTOPDIR)/SOURCES/kvm.tar.gz ${QEMU_DIR}
tar czf $(RPMTOPDIR)/SOURCES/user.tar.gz user
tar czf $(RPMTOPDIR)/SOURCES/libkvm.tar.gz libkvm
tar czf $(RPMTOPDIR)/SOURCES/kernel.tar.gz kernel
@@ -111,7 +111,7 @@ srpm:
$(RM) $(tmpspec)
clean:
- for i in $(if $(WANT_MODULE), kernel) user libkvm qemu libfdt; do \
+ for i in $(if $(WANT_MODULE), kernel) user libkvm ${QEMU_DIR} libfdt;
do \
make -C $$i clean; \
done
rm -f ./cscope.*
diff --git a/kvm/configure b/kvm/configure
index 249c743..f4873c1 100755
--- a/kvm/configure
+++ b/kvm/configure
@@ -14,6 +14,7 @@ qemu_opts=()
cross_prefix=
arch=`uname -m`
target_exec=
+qemu_directory=$PWD/..
# don't use uname if kerneldir is set
no_uname=
if [ -z TMPDIR ] ; then
@@ -41,8 +42,7 @@ usage() {
Any additional option is given to qemu's configure verbatim; including:
Re: [Lguest] powerpc64 port anyone?
On 22.04.2009, at 23:41, Hollis Blanchard wrote: On Thu, 2009-04-23 at 01:19 +0400, Wartan Hachaturow wrote: On Wed, Apr 22, 2009 at 7:41 PM, Hollis Blanchard holl...@us.ibm.com wrote: KVM supports embedded PowerPC (440 and e500 at the moment), and there has been some work to port it to ppc64 cores like 970 (without using the hardware extensions, since these are unavailable on shipping systems). If you're interested, you should check out the trees at http://powerkvm.org . Wow, didn't know about that port. I'll have a look. The main port was PowerPC 440, and that and e500 support are already upstream in KVM. Some details are available here: http://www.linux-kvm.org/page/PowerPC The 970/Cell stuff Alex is doing is only loosely connected to that (ppc64 supervisor mode is very different from 440/e500), and that's the first URL I gave you. Actually my 970 stuff virtualizes ppc32 on ppc64, so we don't have to mess with conflicting kernel address rooms. The architecture as is however should allow you to easily add ppc32 host support as well as ppc64 guest support, as long as you prevent the memory segments to collide (BAT for ppc32, 0xc/0xd SLB entries for ppc64). So I for my part would welcome any help I can get to have KVM run smoothly on non-embedded POWER :-). Alex -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] qemu-kvm: configure script fixups after qemu-kvm reorg
Also for me running ./configure --kerneldir=/path/to/kernel at top dir works. (/path/to/kernel should be absolute though, otherwise kernel include path is incorrect). Ah, I didn't realise kvm/cofigure is obsolete. -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-kvm.git now live
Liu Yu-B13201 wrote: git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git Is there a http interface? http://www.kernel.org/pub/scm/virt/kvm/qemu-kvm.git -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
