Skip to contentSkip to conversation

QEMU KVM target

RFC In review Anthony Liguori 4 participants 12 messages Feb 20, 2007 – Feb 21, 2007 8 messages not in the archive KVM

lore
Share & tools
lore

Anthony Liguori

author
#0 lore raw

RFC 1/1 QEMU KVM target

Howdy,

Here's a tiny patch that adds a i386-kvm target. The main difference between the i386-kvm and i386-softmmu target is that the -kvm target does not have any of the dyngen infrastructure. This means that it will build with gcc-4. I know you can do --cc=gcc to use gcc-4 but quite a few versions of gcc-4 have trouble with compiling dyngen.

I also suspect this may prove useful down the road. What do other people think? I'm not terribly tied to the i386-kvm name for what it's worth.

Regards,

Anthony Liguori

configure +2 -24
diff -r 64fb395dc8f1 configure
@@ -3,8 +3,6 @@ prefix=/usr/kvm
 prefix=/usr/kvm
 kerneldir=/lib/modules/$(uname -r)/build
 want_module=1
-qemu_cc=$(ls /usr/bin/gcc3* /usr/bin/gcc-3* 2>/dev/null | tail -n1)
-disable_gcc_check=
 
 usage() {
     cat <<-EOF

@@ -15,20 +13,11 @@ usage() {
 	    --prefix=PREFIX        where to install things ($prefix)
 	    --with-patched-kernel  don't use external module
 	    --kerneldir=DIR        kernel build directory ($kerneldir)
-	    --qemu-cc="$qemu_cc"   compiler for qemu (needs gcc3.x) ($qemu_cc)
-	    --disable-gcc-check    don't insist on gcc-3.x
                                    - this will break running without kvm
 EOF
     exit 1
 }
 
-
-# prefer gcc if its version is 3.* ( over a compat-gcc )
-# do it before parsing command line arguments to enable the user
-#    to specify a specific gcc he/she likes.
-if gcc -v 2>&1 | grep -q 'gcc *version *3\.[2-4]\.[0-9]'; then
-	qemu_cc=gcc
-fi
 
 while [[ "$1" = -* ]]; do
     opt="$1"; shift

@@ -47,12 +36,6 @@ while [[ "$1" = -* ]]; do
 	--with-patched-kernel)
 	    want_module=
 	    ;;
-	--qemu-cc)
-	    qemu_cc="$arg"
-	    ;;
-	--disable-gcc-check)
-	    disable_gcc_check=1
-	    ;;
 	--help)
 	    usage
 	    ;;

@@ -61,11 +44,6 @@ while [[ "$1" = -* ]]; do
 	    ;;
     esac
 done
-
-if [[ -z "$qemu_cc" ]]; then
-    echo "$0: cannot locate gcc 3.x. please install it or specify with --qemu-cc"
-    exit 1
-fi
 
 libkvm_kerneldir="$kerneldir"
 if (( want_module )); then

@@ -81,12 +59,12 @@ target_cpu() {
 }
 
 (cd user; ./configure --prefix="$prefix" --kerneldir="$libkvm_kerneldir")
-(cd qemu; ./configure --target-list=$(target_cpu)-softmmu --cc="$qemu_cc" \
+(cd qemu; ./configure --target-list=i386-kvm \
     --disable-kqemu --extra-cflags="-I $PWD/../user" \
     --extra-ldflags="-L $PWD/../user" \
     --enable-kvm --kernel-path="$libkvm_kerneldir" \
     --enable-alsa \
-    ${disable_gcc_check:+"--disable-gcc-check"} \
+    --disable-gcc-check \
     --prefix="$prefix"
 )
qemu/Makefile.target +8 -2
diff -r 64fb395dc8f1 qemu/Makefile.target
@@ -52,7 +52,11 @@ QEMU_USER=qemu-$(TARGET_ARCH2)
 # system emulator name
 ifdef CONFIG_SOFTMMU
 ifeq ($(TARGET_ARCH), i386)
+ifdef CONFIG_KVM
+QEMU_SYSTEM=qemu-kvm$(EXESUF)
+else
 QEMU_SYSTEM=qemu$(EXESUF)
+endif
 else
 QEMU_SYSTEM=qemu-system-$(TARGET_ARCH2)$(EXESUF)
 endif

@@ -231,8 +235,10 @@ OBJS+= libqemu.a
 OBJS+= libqemu.a
 
 # cpu emulator library
-LIBOBJS=exec.o kqemu.o qemu-kvm.o translate-op.o translate-all.o cpu-exec.o\
-        translate.o op.o
+LIBOBJS=exec.o kqemu.o qemu-kvm.o cpu-exec.o
+ifndef CONFIG_KVM
+LIBOBJS+=translate.o op.o translate-op.o translate-all.o 
+endif
 ifdef CONFIG_SOFTFLOAT
 LIBOBJS+=fpu/softfloat.o
 else
qemu/configure +9 -0
diff -r 64fb395dc8f1 qemu/configure
@@ -819,6 +819,11 @@ target_user_only="no"
 target_user_only="no"
 if expr $target : '.*-user' > /dev/null ; then
   target_user_only="yes"
+fi
+target_kvm="no"
+if expr $target : '.*-kvm' > /dev/null ; then
+  target_kvm="yes"
+  target_softmmu="yes"
 fi
 
 target_linux_user="no"

@@ -943,6 +948,10 @@ if test "$target_softmmu" = "yes" ; then
   echo "CONFIG_SOFTMMU=yes" >> $config_mak
   echo "#define CONFIG_SOFTMMU 1" >> $config_h
 fi
+if test "$target_kvm" = "yes" ; then
+  echo "CONFIG_KVM=yes" >> $config_mak
+  echo "#define CONFIG_KVM 1" >> $config_h
+fi
 if test "$target_user_only" = "yes" ; then
   echo "CONFIG_USER_ONLY=yes" >> $config_mak
   echo "#define CONFIG_USER_ONLY 1" >> $config_h
qemu/qemu-kvm.c +37 -2
diff -r 64fb395dc8f1 qemu/qemu-kvm.c
@@ -705,5 +705,40 @@ int kvm_update_debugger(CPUState *env)
     return kvm_guest_debug(kvm_context, 0, &dbg);
 }
 
-
-#endif
+#ifdef CONFIG_KVM
+
+CCTable cc_table[CC_OP_NB];
+
+int code_copy_enabled;
+
+static int nop_flags(void)
+{
+    return 0;
+}
+
+int cpu_gen_code(CPUState *env, TranslationBlock *tb,
+		 int max_code_size, int *gen_code_size_ptr)
+{
+    return -1;
+}
+
+int cpu_restore_state(TranslationBlock *tb,
+		      CPUState *env, unsigned long searched_pc,
+		      void *puc)
+{
+    return -1;
+}
+
+void optimize_flags_init(void)
+{
+    int i;
+
+    for (i = 0; i < CC_OP_NB; i++) {
+	cc_table[i].compute_c = nop_flags;
+	cc_table[i].compute_all = nop_flags;
+    }
+}
+
+#endif
+
+#endif
qemu/target-i386/helper.c +8 -0
diff -r 64fb395dc8f1 qemu/target-i386/helper.c
@@ -1594,6 +1594,9 @@ void helper_idivl_EAX_T0(void)
     EDX = (uint32_t)r;
 }
 
+/* GCC 4 has a hard time with this helper */
+
+#ifndef CONFIG_KVM
 void helper_cmpxchg8b(void)
 {
     uint64_t d;

@@ -1611,6 +1614,7 @@ void helper_cmpxchg8b(void)
     }
     CC_SRC = eflags;
 }
+#endif
 
 void helper_cpuid(void)
 {

@@ -2968,6 +2972,9 @@ void helper_verw(void)
     CC_SRC = eflags | CC_Z;
 }
 
+/* GCC 4 has a hard time with the FPU helpers */
+#ifndef CONFIG_KVM
+
 /* FPU helpers */
 
 void helper_fldt_ST0_A0(void)

@@ -3485,6 +3492,7 @@ void helper_fxrstor(target_ulong ptr, in
         }
     }
 }
+#endif
 
 #ifndef USE_X86LDOUBLE
qemu/vl.c +5 -0
diff -r 64fb395dc8f1 qemu/vl.c
@@ -7341,8 +7341,13 @@ int main(int argc, char **argv)
 #if USE_KVM
     if (kvm_allowed) {
 	if (kvm_qemu_init() < 0) {
+#ifdef CONFIG_KVM
+	    fprintf(stderr, "Could not initialize KVM\n");
+	    exit(1);
+#else
 	    fprintf(stderr, "Could not initialize KVM, will disable KVM support\n");
 	    kvm_allowed = 0;
+#endif
 	}
     }
 #endif

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

_______________________________________________
kvm-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel

#2 lore raw
In reply to a message not in the archive

Howdy Anthony,

Quoted 5 lines

Here's a tiny patch that adds a i386-kvm target. The main difference between the i386-kvm and i386-softmmu target is that the -kvm target does not have any of the dyngen infrastructure. This means that it will build with gcc-4. I know you can do --cc=gcc to use gcc-4 but quite a few versions of gcc-4 have trouble with compiling dyngen.

I understand that your approach is to remove the "binary translation" part of the vanilla qemu, because we dont need it. We only need the device emulation code of qemu for kvm. Do I understand correctly?

If so, we do not need to depend on gcc3 tricks anymore. Removing the dependent on gcc3 is really an important achievement.

Thanks,
Jun

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

author
#4 lore raw
In reply to a message not in the archive
Quoted 11 lines · Jun Koi

Howdy Anthony,

Quoted 5 lines

Here's a tiny patch that adds a i386-kvm target. The main difference between the i386-kvm and i386-softmmu target is that the -kvm target does not have any of the dyngen infrastructure. This means that it will build with gcc-4. I know you can do --cc=gcc to use gcc-4 but quite a few versions of gcc-4 have trouble with compiling dyngen.

I understand that your approach is to remove the "binary translation" part of the vanilla qemu, because we dont need it. We only need the device emulation code of qemu for kvm. Do I understand correctly?

Yup.

Regards,

Anthony Liguori

Quoted 6 lines

If so, we do not need to depend on gcc3 tricks anymore. Removing the dependent on gcc3 is really an important achievement.

Thanks,
Jun

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

#8 lore raw
In reply to a message not in the archive
Quoted 8 lines · Anthony Liguori

Howdy,

Here's a tiny patch that adds a i386-kvm target. The main difference between the i386-kvm and i386-softmmu target is that the -kvm target does not have any of the dyngen infrastructure. This means that it will build with gcc-4. I know you can do --cc=gcc to use gcc-4 but quite a few versions of gcc-4 have trouble with compiling dyngen.

Quoted 4 lines

I also suspect this may prove useful down the road. What do other people think? I'm not terribly tied to the i386-kvm name for what it's worth.

That kills the -no-kvm switch, which allows a single binary to be used both with and without kvm. Or do you think both target-i386+kvm and target-kvm ought to be kept?

My thinking about qemu integration is that kqemu/kvm code needs to be abstracted into an API to reduce the #ifdefing in qemu, and that API could call kqemu or kvm as appropriate.

Signature · 8 lines
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
#10 lore raw
In reply to a message not in the archive
Quoted 16 lines · Avi Kivity
Quoted 8 lines · Anthony Liguori

Howdy,

Here's a tiny patch that adds a i386-kvm target. The main difference between the i386-kvm and i386-softmmu target is that the -kvm target does not have any of the dyngen infrastructure. This means that it will build with gcc-4. I know you can do --cc=gcc to use gcc-4 but quite a few versions of gcc-4 have trouble with compiling dyngen.

Quoted 5 lines

I also suspect this may prove useful down the road. What do other people think? I'm not terribly tied to the i386-kvm name for what it's worth.

Quoted 5 lines

That kills the -no-kvm switch, which allows a single binary to be used both with and without kvm. Or do you think both target-i386+kvm and target-kvm ought to be kept?

I meant here: target-i386 (with kvm support) and target-i386-kvm.

Quoted 6 lines

My thinking about qemu integration is that kqemu/kvm code needs to be abstracted into an API to reduce the #ifdefing in qemu, and that API could call kqemu or kvm as appropriate.

Signature · 8 lines
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
author
#19 lore raw
In reply to a message not in the archive
Quoted 9 lines · Avi Kivity
Quoted 8 lines · Anthony Liguori

Howdy,

Here's a tiny patch that adds a i386-kvm target. The main difference between the i386-kvm and i386-softmmu target is that the -kvm target does not have any of the dyngen infrastructure. This means that it will build with gcc-4. I know you can do --cc=gcc to use gcc-4 but quite a few versions of gcc-4 have trouble with compiling dyngen.

Quoted 8 lines
Quoted 4 lines

I also suspect this may prove useful down the road. What do other people think? I'm not terribly tied to the i386-kvm name for what it's worth.

That kills the -no-kvm switch, which allows a single binary to be used both with and without kvm. Or do you think both target-i386+kvm and target-kvm ought to be kept?

I think both should be kept. I think configure ought to be smart enough to figure out if gcc-3 is available and build the appropriate targets. Adding the new target is a small enough patch that it won't be offensive and should make a lot of users happy.

Quoted 3 lines

My thinking about qemu integration is that kqemu/kvm code needs to be abstracted into an API to reduce the #ifdefing in qemu, and that API could call kqemu or kvm as appropriate.

That's definitely not a bad idea.

Regards,

Anthony Liguori

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

author
#12 lore raw
In reply to a message not in the archive
Quoted 18 lines · Avi Kivity
Quoted 17 lines · Avi Kivity
Quoted 14 lines · Anthony Liguori

Howdy,

Here's a tiny patch that adds a i386-kvm target. The main difference between the i386-kvm and i386-softmmu target is that the -kvm target does not have any of the dyngen infrastructure. This means that it will build with gcc-4. I know you can do --cc=gcc to use gcc-4 but quite a few versions of gcc-4 have trouble with compiling dyngen.

I also suspect this may prove useful down the road. What do other people think? I'm not terribly tied to the i386-kvm name for what it's worth.

Quoted 7 lines
Quoted 5 lines

That kills the -no-kvm switch, which allows a single binary to be used both with and without kvm. Or do you think both target-i386+kvm and target-kvm ought to be kept?

I meant here: target-i386 (with kvm support) and target-i386-kvm.

target-i386 is an architecture. It can currently generate i386-softmmu, i386-user, x86_64-softmmu, x86_64-user. We're simply adding the ability to generate i386-kvm and x86_64-kvm. I'd like to find another name.

I still want to be able to support kvm/qemu in the normal i386-softmmu.

Regards,

Anthony Liguori

Quoted 8 lines
Quoted 6 lines

My thinking about qemu integration is that kqemu/kvm code needs to be abstracted into an API to reduce the #ifdefing in qemu, and that API could call kqemu or kvm as appropriate.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

#14 lore raw
In reply to a message not in the archive
Quoted 7 lines · Anthony Liguori
Quoted 7 lines
Quoted 6 lines

That kills the -no-kvm switch, which allows a single binary to be used both with and without kvm. Or do you think both target-i386+kvm and target-kvm ought to be kept?

Quoted 8 lines
Quoted 1 line

I meant here: target-i386 (with kvm support) and target-i386-kvm.

target-i386 is an architecture. It can currently generate i386-softmmu, i386-user, x86_64-softmmu, x86_64-user. We're simply adding the ability to generate i386-kvm and x86_64-kvm. I'd like to find another name.

I still want to be able to support kvm/qemu in the normal i386-softmmu.

Thanks, that clears it up. I'll apply the patch.

Signature · 8 lines
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
author
#16 lore raw
In reply to a message not in the archive
Quoted 10 lines · Avi Kivity
Quoted 9 lines · Anthony Liguori
Quoted 8 lines
Quoted 6 lines

That kills the -no-kvm switch, which allows a single binary to be used both with and without kvm. Or do you think both target-i386+kvm and target-kvm ought to be kept?

I meant here: target-i386 (with kvm support) and target-i386-kvm.

Quoted 8 lines
Quoted 6 lines

target-i386 is an architecture. It can currently generate i386-softmmu, i386-user, x86_64-softmmu, x86_64-user. We're simply adding the ability to generate i386-kvm and x86_64-kvm. I'd like to find another name.

I still want to be able to support kvm/qemu in the normal i386-softmmu.

Thanks, that clears it up. I'll apply the patch.

Can you wait on that? I'll submit a better one tonight. It was just an RFC :-)

Regards,

Anthony Liguori

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

#18 lore raw
In reply to a message not in the archive
Quoted 4 lines · Anthony Liguori

Can you wait on that? I'll submit a better one tonight. It was just an RFC :-)

Ok.

Signature · 8 lines
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
#5 lore raw
In reply to a message not in the archive
Quoted 8 lines · Jun Koi

Howdy Anthony,

Quoted 5 lines

Here's a tiny patch that adds a i386-kvm target. The main difference between the i386-kvm and i386-softmmu target is that the -kvm target does not have any of the dyngen infrastructure. This means that it will build with gcc-4. I know you can do --cc=gcc to use gcc-4 but quite a few versions of gcc-4 have trouble with compiling dyngen.

Quoted 6 lines

I understand that your approach is to remove the "binary translation" part of the vanilla qemu, because we dont need it. We only need the device emulation code of qemu for kvm. Do I understand correctly?

If so, we do not need to depend on gcc3 tricks anymore. Removing the dependent on gcc3 is really an important achievement.

Does your patch still call the binary qemu? It'd be nice for distributions to have a real qemu still available as 'qemu', and the kvm-specific one as something else.

Cheers,
Rusty.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

author
#7 lore raw
In reply to a message not in the archive
Quoted 15 lines · Rusty Russell
Quoted 13 lines · Jun Koi

Howdy Anthony,

Quoted 6 lines

Here's a tiny patch that adds a i386-kvm target. The main difference between the i386-kvm and i386-softmmu target is that the -kvm target does not have any of the dyngen infrastructure. This means that it will build with gcc-4. I know you can do --cc=gcc to use gcc-4 but quite a few versions of gcc-4 have trouble with compiling dyngen.

I understand that your approach is to remove the "binary translation" part of the vanilla qemu, because we dont need it. We only need the device emulation code of qemu for kvm. Do I understand correctly?

Quoted 8 lines
Quoted 3 lines

If so, we do not need to depend on gcc3 tricks anymore. Removing the dependent on gcc3 is really an important achievement.

Does your patch still call the binary qemu? It'd be nice for distributions to have a real qemu still available as 'qemu', and the kvm-specific one as something else.

It calls it qemu-kvm (or qemu-system-x86_64-kvm). I'd like to find a better name, perhaps qemu-system-i386-accel or something.

Regards,

Anthony Liguori

Quoted 5 lines

Cheers,
Rusty.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV