All of lore.kernel.org
 help / color / mirror / Atom feed
* [Qemu-devel] [PATCH] remove pieces of source code
@ 2009-05-28 23:03 Glauber Costa
  2009-05-29  5:50 ` Anthony Liguori
  0 siblings, 1 reply; 25+ messages in thread
From: Glauber Costa @ 2009-05-28 23:03 UTC (permalink / raw)
  To: qemu-devel; +Cc: aliguori

Have you ever seen a girl so beautiful that you, geeky,
think: "I'll never stand a chance"?

But sometimes, you decide to make your move anyway. There's
always the chance that in that very day she'll be specially
in good mood, and you'll get what you want.

With the exception of the fact that qemu is not a girl,
that's more or less what I'm trying to do here: Hopefully,
nobody will notice what I'm trying to do, and will commmit it.
Later, when realizing, it will be too late. Victory will be mine.

Or maybe people will even agree. For that, I'll try briefly
to arguee my point, without disclosing to much, avoiding
jeopardizing the strategy I explained above:

  This patch removes a piece of code that is unmaintaned,
  that does not receive an update for years,
  that get bug reports on the list that nobody fixes, because
  nobody really understands,
  that places some artificial constraints on other subsystems

Signed-off-by: Glauber Costa <glommer@redhat.com>
---
 Makefile.target         |    3 -
 configure               |   36 --
 cpu-all.h               |    9 -
 cpu-common.h            |    5 -
 cpu-exec.c              |   43 +--
 exec-all.h              |   35 --
 exec.c                  |   91 +-----
 hw/pc.c                 |   12 +-
 hw/virtio-pci.c         |    2 +-
 hw/virtio.c             |    2 +-
 kqemu.c                 |  999 -----------------------------------------------
 kqemu.h                 |  154 --------
 monitor.c               |   53 ---
 osdep.c                 |  117 ------
 qemu-doc.texi           |    2 -
 qemu-options.hx         |   19 -
 qemu-tech.texi          |    4 +-
 softmmu_template.h      |    6 -
 sysemu.h                |    4 -
 target-i386/TODO        |    1 -
 target-i386/cpu.h       |   14 -
 target-i386/helper.c    |   21 +-
 target-i386/op_helper.c |   42 --
 vl.c                    |   75 +----
 24 files changed, 12 insertions(+), 1737 deletions(-)
 delete mode 100644 kqemu.c
 delete mode 100644 kqemu.h

diff --git a/Makefile.target b/Makefile.target
index 445d55f..2ded52f 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -135,9 +135,6 @@ all: $(PROGS)
 # cpu emulator library
 LIBOBJS=exec.o translate-all.o cpu-exec.o\
         translate.o host-utils.o
-ifdef CONFIG_KQEMU
-LIBOBJS+= kqemu.o
-endif
 # TCG code generator
 LIBOBJS+= tcg/tcg.o tcg/tcg-runtime.o
 CPPFLAGS+=-I$(SRC_PATH)/tcg -I$(SRC_PATH)/tcg/$(ARCH)
diff --git a/configure b/configure
index b6d18d1..7d4e226 100755
--- a/configure
+++ b/configure
@@ -172,7 +172,6 @@ vnc_sasl="yes"
 bsd="no"
 linux="no"
 solaris="no"
-kqemu="no"
 profiler="no"
 cocoa="no"
 softmmu="yes"
@@ -215,40 +214,25 @@ case $targetos in
 CYGWIN*)
 mingw32="yes"
 OS_CFLAGS="-mno-cygwin"
-if [ "$cpu" = "i386" ] ; then
-    kqemu="yes"
-fi
 audio_possible_drivers="sdl"
 ;;
 MINGW32*)
 mingw32="yes"
-if [ "$cpu" = "i386" ] ; then
-    kqemu="yes"
-fi
 audio_possible_drivers="dsound sdl fmod"
 ;;
 GNU/kFreeBSD)
 audio_drv_list="oss"
 audio_possible_drivers="oss sdl esd pa"
-if [ "$cpu" = "i386" -o "$cpu" = "x86_64" ] ; then
-    kqemu="yes"
-fi
 ;;
 FreeBSD)
 bsd="yes"
 audio_drv_list="oss"
 audio_possible_drivers="oss sdl esd pa"
-if [ "$cpu" = "i386" -o "$cpu" = "x86_64" ] ; then
-    kqemu="yes"
-fi
 ;;
 DragonFly)
 bsd="yes"
 audio_drv_list="oss"
 audio_possible_drivers="oss sdl esd pa"
-if [ "$cpu" = "i386" -o "$cpu" = "x86_64" ] ; then
-    kqemu="yes"
-fi
 aio="no"
 ;;
 NetBSD)
@@ -309,9 +293,6 @@ SunOS)
                 exit 1
             fi
         fi
-        if test "$solarisrev" -ge 9 ; then
-            kqemu="yes"
-        fi
     fi
     if test -f /usr/include/sys/soundcard.h ; then
         audio_drv_list="oss"
@@ -330,7 +311,6 @@ linux="yes"
 linux_user="yes"
 usb="linux"
 if [ "$cpu" = "i386" -o "$cpu" = "x86_64" ] ; then
-    kqemu="yes"
     audio_possible_drivers="$audio_possible_drivers fmod"
 fi
 ;;
@@ -425,8 +405,6 @@ for opt do
   ;;
   --disable-vde) vde="no"
   ;;
-  --disable-kqemu) kqemu="no"
-  ;;
   --disable-xen) xen="no"
   ;;
   --disable-brlapi) brlapi="no"
@@ -574,9 +552,6 @@ echo "  --interp-prefix=PREFIX   where to find shared libraries, etc."
 echo "                           use %M for cpu name [$interp_prefix]"
 echo "  --target-list=LIST       set target list [$target_list]"
 echo ""
-echo "kqemu kernel acceleration support:"
-echo "  --disable-kqemu          disable kqemu support"
-echo ""
 echo "Advanced options (experts only):"
 echo "  --source-path=PATH       path of source code [$source_path]"
 echo "  --cross-prefix=PREFIX    use PREFIX for compile tools [$cross_prefix]"
@@ -1351,7 +1326,6 @@ fi
 if test -n "$sparc_cpu"; then
     echo "Target Sparc Arch $sparc_cpu"
 fi
-echo "kqemu support     $kqemu"
 echo "xen support       $xen"
 echo "brlapi support    $brlapi"
 echo "Documentation     $build_docs"
@@ -1862,11 +1836,6 @@ case "$target_cpu" in
     echo "TARGET_ARCH=i386" >> $config_mak
     echo "#define TARGET_ARCH \"i386\"" >> $config_h
     echo "#define TARGET_I386 1" >> $config_h
-    if test $kqemu = "yes" -a "$target_softmmu" = "yes"
-    then
-      echo "CONFIG_KQEMU=yes" >> $config_mak
-      echo "#define CONFIG_KQEMU 1" >> $config_h
-    fi
     if test "$kvm" = "yes" ; then
       echo "CONFIG_KVM=yes" >> $config_mak
       echo "KVM_CFLAGS=$kvm_cflags" >> $config_mak
@@ -1884,11 +1853,6 @@ case "$target_cpu" in
     echo "#define TARGET_ARCH \"x86_64\"" >> $config_h
     echo "#define TARGET_I386 1" >> $config_h
     echo "#define TARGET_X86_64 1" >> $config_h
-    if test $kqemu = "yes" -a "$target_softmmu" = "yes" -a $cpu = "x86_64"
-    then
-      echo "CONFIG_KQEMU=yes" >> $config_mak
-      echo "#define CONFIG_KQEMU 1" >> $config_h
-    fi
     if test "$kvm" = "yes" ; then
       echo "CONFIG_KVM=yes" >> $config_mak
       echo "KVM_CFLAGS=$kvm_cflags" >> $config_mak
diff --git a/cpu-all.h b/cpu-all.h
index dc9b034..8eeef05 100644
--- a/cpu-all.h
+++ b/cpu-all.h
@@ -873,7 +873,6 @@ int cpu_memory_rw_debug(CPUState *env, target_ulong addr,
 
 #define VGA_DIRTY_FLAG       0x01
 #define CODE_DIRTY_FLAG      0x02
-#define KQEMU_DIRTY_FLAG     0x04
 #define MIGRATION_DIRTY_FLAG 0x08
 
 /* read dirty bit (return 0 or 1) */
@@ -1056,14 +1055,6 @@ static inline int64_t profile_getclock(void)
     return cpu_get_real_ticks();
 }
 
-extern int64_t kqemu_time, kqemu_time_start;
-extern int64_t qemu_time, qemu_time_start;
-extern int64_t tlb_flush_time;
-extern int64_t kqemu_exec_count;
-extern int64_t dev_time;
-extern int64_t kqemu_ret_int_count;
-extern int64_t kqemu_ret_excp_count;
-extern int64_t kqemu_ret_intr_count;
 #endif
 
 #endif /* CPU_ALL_H */
diff --git a/cpu-common.h b/cpu-common.h
index 4640924..2ce8448 100644
--- a/cpu-common.h
+++ b/cpu-common.h
@@ -10,12 +10,7 @@
 #include "bswap.h"
 
 /* address in the RAM (different from a physical address) */
-#ifdef CONFIG_KQEMU
-/* FIXME: This is wrong.  */
-typedef uint32_t ram_addr_t;
-#else
 typedef unsigned long ram_addr_t;
-#endif
 
 /* memory API */
 
diff --git a/cpu-exec.c b/cpu-exec.c
index 8734337..a88d50d 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -322,32 +322,6 @@ int cpu_exec(CPUState *env1)
                 }
                 env->exception_index = -1;
             }
-#ifdef CONFIG_KQEMU
-            if (kqemu_is_ok(env) && env->interrupt_request == 0 && env->exit_request == 0) {
-                int ret;
-                env->eflags = env->eflags | helper_cc_compute_all(CC_OP) | (DF & DF_MASK);
-                ret = kqemu_cpu_exec(env);
-                /* put eflags in CPU temporary format */
-                CC_SRC = env->eflags & (CC_O | CC_S | CC_Z | CC_A | CC_P | CC_C);
-                DF = 1 - (2 * ((env->eflags >> 10) & 1));
-                CC_OP = CC_OP_EFLAGS;
-                env->eflags &= ~(DF_MASK | CC_O | CC_S | CC_Z | CC_A | CC_P | CC_C);
-                if (ret == 1) {
-                    /* exception */
-                    longjmp(env->jmp_env, 1);
-                } else if (ret == 2) {
-                    /* softmmu execution needed */
-                } else {
-                    if (env->interrupt_request != 0 || env->exit_request != 0) {
-                        /* hardware interrupt will be executed just after */
-                    } else {
-                        /* otherwise, we restart */
-                        longjmp(env->jmp_env, 1);
-                    }
-                }
-            }
-#endif
-
             if (kvm_enabled()) {
                 kvm_cpu_exec(env);
                 longjmp(env->jmp_env, 1);
@@ -612,15 +586,9 @@ int cpu_exec(CPUState *env1)
                 /* see if we can patch the calling TB. When the TB
                    spans two pages, we cannot safely do a direct
                    jump. */
-                {
-                    if (next_tb != 0 &&
-#ifdef CONFIG_KQEMU
-                        (env->kqemu_enabled != 2) &&
-#endif
-                        tb->page_addr[1] == -1) {
+                if (next_tb != 0 && tb->page_addr[1] == -1) {
                     tb_add_jump((TranslationBlock *)(next_tb & ~3), next_tb & 3, tb);
                 }
-                }
                 spin_unlock(&tb_lock);
                 env->current_tb = tb;
 
@@ -669,15 +637,6 @@ int cpu_exec(CPUState *env1)
                         }
                     }
                 }
-                /* reset soft MMU for next block (it can currently
-                   only be set by a memory fault) */
-#if defined(CONFIG_KQEMU)
-#define MIN_CYCLE_BEFORE_SWITCH (100 * 1000)
-                if (kqemu_is_ok(env) &&
-                    (cpu_get_time_fast() - env->last_io_time) >= MIN_CYCLE_BEFORE_SWITCH) {
-                    cpu_loop_exit();
-                }
-#endif
             } /* for(;;) */
         } else {
             env_to_regs();
diff --git a/exec-all.h b/exec-all.h
index f91e646..7f8a786 100644
--- a/exec-all.h
+++ b/exec-all.h
@@ -352,41 +352,6 @@ static inline int can_do_io(CPUState *env)
 }
 #endif
 
-#ifdef CONFIG_KQEMU
-#define KQEMU_MODIFY_PAGE_MASK (0xff & ~(VGA_DIRTY_FLAG | CODE_DIRTY_FLAG))
-
-#define MSR_QPI_COMMBASE 0xfabe0010
-
-int kqemu_init(CPUState *env);
-int kqemu_cpu_exec(CPUState *env);
-void kqemu_flush_page(CPUState *env, target_ulong addr);
-void kqemu_flush(CPUState *env, int global);
-void kqemu_set_notdirty(CPUState *env, ram_addr_t ram_addr);
-void kqemu_modify_page(CPUState *env, ram_addr_t ram_addr);
-void kqemu_set_phys_mem(uint64_t start_addr, ram_addr_t size, 
-                        ram_addr_t phys_offset);
-void kqemu_cpu_interrupt(CPUState *env);
-void kqemu_record_dump(void);
-
-extern uint32_t kqemu_comm_base;
-
-extern ram_addr_t kqemu_phys_ram_size;
-extern uint8_t *kqemu_phys_ram_base;
-
-static inline int kqemu_is_ok(CPUState *env)
-{
-    return(env->kqemu_enabled &&
-           (env->cr[0] & CR0_PE_MASK) &&
-           !(env->hflags & HF_INHIBIT_IRQ_MASK) &&
-           (env->eflags & IF_MASK) &&
-           !(env->eflags & VM_MASK) &&
-           (env->kqemu_enabled == 2 ||
-            ((env->hflags & HF_CPL_MASK) == 3 &&
-             (env->eflags & IOPL_MASK) != IOPL_MASK)));
-}
-
-#endif
-
 typedef void (CPUDebugExcpHandler)(CPUState *env);
 
 CPUDebugExcpHandler *cpu_set_debug_excp_handler(CPUDebugExcpHandler *handler);
diff --git a/exec.c b/exec.c
index 723de89..a4e5111 100644
--- a/exec.c
+++ b/exec.c
@@ -71,12 +71,11 @@
 #define TARGET_VIRT_ADDR_SPACE_BITS 42
 #elif defined(TARGET_PPC64)
 #define TARGET_PHYS_ADDR_SPACE_BITS 42
-#elif defined(TARGET_X86_64) && !defined(CONFIG_KQEMU)
+#elif defined(TARGET_X86_64)
 #define TARGET_PHYS_ADDR_SPACE_BITS 42
-#elif defined(TARGET_I386) && !defined(CONFIG_KQEMU)
+#elif defined(TARGET_I386)
 #define TARGET_PHYS_ADDR_SPACE_BITS 36
 #else
-/* Note: for compatibility with kqemu, we use 32 bits for x86_64 */
 #define TARGET_PHYS_ADDR_SPACE_BITS 32
 #endif
 
@@ -1775,11 +1774,6 @@ void tlb_flush(CPUState *env, int flush_global)
 
     memset (env->tb_jmp_cache, 0, TB_JMP_CACHE_SIZE * sizeof (void *));
 
-#ifdef CONFIG_KQEMU
-    if (env->kqemu_enabled) {
-        kqemu_flush(env, flush_global);
-    }
-#endif
     tlb_flush_count++;
 }
 
@@ -1823,12 +1817,6 @@ void tlb_flush_page(CPUState *env, target_ulong addr)
 #endif
 
     tlb_flush_jmp_cache(env, addr);
-
-#ifdef CONFIG_KQEMU
-    if (env->kqemu_enabled) {
-        kqemu_flush_page(env, addr);
-    }
-#endif
 }
 
 /* update the TLBs so that writes to code in the virtual page 'addr'
@@ -1876,18 +1864,6 @@ void cpu_physical_memory_reset_dirty(ram_addr_t start, ram_addr_t end,
     if (length == 0)
         return;
     len = length >> TARGET_PAGE_BITS;
-#ifdef CONFIG_KQEMU
-    /* XXX: should not depend on cpu context */
-    env = first_cpu;
-    if (env->kqemu_enabled) {
-        ram_addr_t addr;
-        addr = start;
-        for(i = 0; i < len; i++) {
-            kqemu_set_notdirty(env, addr);
-            addr += TARGET_PAGE_SIZE;
-        }
-    }
-#endif
     mask = ~dirty_flags;
     p = phys_ram_dirty + (start >> TARGET_PAGE_BITS);
     for(i = 0; i < len; i++)
@@ -2350,13 +2326,6 @@ void cpu_register_physical_memory_offset(target_phys_addr_t start_addr,
     ram_addr_t orig_size = size;
     void *subpage;
 
-#ifdef CONFIG_KQEMU
-    /* XXX: should not depend on cpu context */
-    env = first_cpu;
-    if (env->kqemu_enabled) {
-        kqemu_set_phys_mem(start_addr, size, phys_offset);
-    }
-#endif
     if (kvm_enabled())
         kvm_set_phys_mem(start_addr, size, phys_offset);
 
@@ -2451,32 +2420,10 @@ void qemu_unregister_coalesced_mmio(target_phys_addr_t addr, ram_addr_t size)
         kvm_uncoalesce_mmio_region(addr, size);
 }
 
-#ifdef CONFIG_KQEMU
-/* XXX: better than nothing */
-static ram_addr_t kqemu_ram_alloc(ram_addr_t size)
-{
-    ram_addr_t addr;
-    if ((last_ram_offset + size) > kqemu_phys_ram_size) {
-        fprintf(stderr, "Not enough memory (requested_size = %" PRIu64 ", max memory = %" PRIu64 ")\n",
-                (uint64_t)size, (uint64_t)kqemu_phys_ram_size);
-        abort();
-    }
-    addr = last_ram_offset;
-    last_ram_offset = TARGET_PAGE_ALIGN(last_ram_offset + size);
-    return addr;
-}
-#endif
-
 ram_addr_t qemu_ram_alloc(ram_addr_t size)
 {
     RAMBlock *new_block;
 
-#ifdef CONFIG_KQEMU
-    if (kqemu_phys_ram_base) {
-        return kqemu_ram_alloc(size);
-    }
-#endif
-
     size = TARGET_PAGE_ALIGN(size);
     new_block = qemu_malloc(sizeof(*new_block));
 
@@ -2519,12 +2466,6 @@ void *qemu_get_ram_ptr(ram_addr_t addr)
     RAMBlock **prevp;
     RAMBlock *block;
 
-#ifdef CONFIG_KQEMU
-    if (kqemu_phys_ram_base) {
-        return kqemu_phys_ram_base + addr;
-    }
-#endif
-
     prev = NULL;
     prevp = &ram_blocks;
     block = ram_blocks;
@@ -2557,12 +2498,6 @@ ram_addr_t qemu_ram_addr_from_host(void *ptr)
     RAMBlock *block;
     uint8_t *host = ptr;
 
-#ifdef CONFIG_KQEMU
-    if (kqemu_phys_ram_base) {
-        return host - kqemu_phys_ram_base;
-    }
-#endif
-
     prev = NULL;
     prevp = &ram_blocks;
     block = ram_blocks;
@@ -2667,11 +2602,6 @@ static void notdirty_mem_writeb(void *opaque, target_phys_addr_t ram_addr,
 #endif
     }
     stb_p(qemu_get_ram_ptr(ram_addr), val);
-#ifdef CONFIG_KQEMU
-    if (cpu_single_env->kqemu_enabled &&
-        (dirty_flags & KQEMU_MODIFY_PAGE_MASK) != KQEMU_MODIFY_PAGE_MASK)
-        kqemu_modify_page(cpu_single_env, ram_addr);
-#endif
     dirty_flags |= (0xff & ~CODE_DIRTY_FLAG);
     phys_ram_dirty[ram_addr >> TARGET_PAGE_BITS] = dirty_flags;
     /* we remove the notdirty callback only if the code has been
@@ -2692,11 +2622,6 @@ static void notdirty_mem_writew(void *opaque, target_phys_addr_t ram_addr,
 #endif
     }
     stw_p(qemu_get_ram_ptr(ram_addr), val);
-#ifdef CONFIG_KQEMU
-    if (cpu_single_env->kqemu_enabled &&
-        (dirty_flags & KQEMU_MODIFY_PAGE_MASK) != KQEMU_MODIFY_PAGE_MASK)
-        kqemu_modify_page(cpu_single_env, ram_addr);
-#endif
     dirty_flags |= (0xff & ~CODE_DIRTY_FLAG);
     phys_ram_dirty[ram_addr >> TARGET_PAGE_BITS] = dirty_flags;
     /* we remove the notdirty callback only if the code has been
@@ -2717,11 +2642,6 @@ static void notdirty_mem_writel(void *opaque, target_phys_addr_t ram_addr,
 #endif
     }
     stl_p(qemu_get_ram_ptr(ram_addr), val);
-#ifdef CONFIG_KQEMU
-    if (cpu_single_env->kqemu_enabled &&
-        (dirty_flags & KQEMU_MODIFY_PAGE_MASK) != KQEMU_MODIFY_PAGE_MASK)
-        kqemu_modify_page(cpu_single_env, ram_addr);
-#endif
     dirty_flags |= (0xff & ~CODE_DIRTY_FLAG);
     phys_ram_dirty[ram_addr >> TARGET_PAGE_BITS] = dirty_flags;
     /* we remove the notdirty callback only if the code has been
@@ -3018,13 +2938,6 @@ static void io_mem_init(void)
 
     io_mem_watch = cpu_register_io_memory(0, watch_mem_read,
                                           watch_mem_write, NULL);
-#ifdef CONFIG_KQEMU
-    if (kqemu_phys_ram_base) {
-        /* alloc dirty bits array */
-        phys_ram_dirty = qemu_vmalloc(kqemu_phys_ram_size >> TARGET_PAGE_BITS);
-        memset(phys_ram_dirty, 0xff, kqemu_phys_ram_size >> TARGET_PAGE_BITS);
-    }
-#endif
 }
 
 /* mem_read and mem_write are arrays of functions containing the
diff --git a/hw/pc.c b/hw/pc.c
index 66cc780..43c0657 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -104,17 +104,7 @@ static void ioportF0_write(void *opaque, uint32_t addr, uint32_t data)
 /* TSC handling */
 uint64_t cpu_get_tsc(CPUX86State *env)
 {
-    /* Note: when using kqemu, it is more logical to return the host TSC
-       because kqemu does not trap the RDTSC instruction for
-       performance reasons */
-#ifdef CONFIG_KQEMU
-    if (env->kqemu_enabled) {
-        return cpu_get_real_ticks();
-    } else
-#endif
-    {
-        return cpu_get_ticks();
-    }
+    return cpu_get_ticks();
 }
 
 /* SMM support */
diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
index c072423..06b6077 100644
--- a/hw/virtio-pci.c
+++ b/hw/virtio-pci.c
@@ -58,7 +58,7 @@
 
 /* QEMU doesn't strictly need write barriers since everything runs in
  * lock-step.  We'll leave the calls to wmb() in though to make it obvious for
- * KVM or if kqemu gets SMP support.
+ * KVM if gets SMP support.
  */
 #define wmb() do { } while (0)
 
diff --git a/hw/virtio.c b/hw/virtio.c
index 45a49fa..bd95cfc 100644
--- a/hw/virtio.c
+++ b/hw/virtio.c
@@ -22,7 +22,7 @@
 
 /* QEMU doesn't strictly need write barriers since everything runs in
  * lock-step.  We'll leave the calls to wmb() in though to make it obvious for
- * KVM or if kqemu gets SMP support.
+ * KVM if gets SMP support.
  */
 #define wmb() do { } while (0)
 
diff --git a/kqemu.c b/kqemu.c
deleted file mode 100644
index 1718498..0000000
--- a/kqemu.c
+++ /dev/null
@@ -1,999 +0,0 @@
-/*
- *  KQEMU support
- *
- *  Copyright (c) 2005-2008 Fabrice Bellard
- *
- * This library is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation; either
- * version 2 of the License, or (at your option) any later version.
- *
- * This library is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with this library; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston MA  02110-1301 USA
- */
-#include "config.h"
-#ifdef _WIN32
-#include <windows.h>
-#include <winioctl.h>
-#else
-#include <sys/types.h>
-#include <sys/mman.h>
-#include <sys/ioctl.h>
-#endif
-#ifdef HOST_SOLARIS
-#include <sys/ioccom.h>
-#endif
-#include <stdlib.h>
-#include <stdio.h>
-#include <stdarg.h>
-#include <string.h>
-#include <errno.h>
-#include <unistd.h>
-#include <inttypes.h>
-
-#include "cpu.h"
-#include "exec-all.h"
-#include "qemu-common.h"
-
-#ifdef CONFIG_KQEMU
-
-#define DEBUG
-//#define PROFILE
-
-
-#ifdef DEBUG
-#  define LOG_INT(...) qemu_log_mask(CPU_LOG_INT, ## __VA_ARGS__)
-#  define LOG_INT_STATE(env) log_cpu_state_mask(CPU_LOG_INT, (env), 0)
-#else
-#  define LOG_INT(...) do { } while (0)
-#  define LOG_INT_STATE(env) do { } while (0)
-#endif
-
-#include <unistd.h>
-#include <fcntl.h>
-#include "kqemu.h"
-
-#ifdef _WIN32
-#define KQEMU_DEVICE "\\\\.\\kqemu"
-#else
-#define KQEMU_DEVICE "/dev/kqemu"
-#endif
-
-static void qpi_init(void);
-
-#ifdef _WIN32
-#define KQEMU_INVALID_FD INVALID_HANDLE_VALUE
-HANDLE kqemu_fd = KQEMU_INVALID_FD;
-#define kqemu_closefd(x) CloseHandle(x)
-#else
-#define KQEMU_INVALID_FD -1
-int kqemu_fd = KQEMU_INVALID_FD;
-#define kqemu_closefd(x) close(x)
-#endif
-
-/* 0 = not allowed
-   1 = user kqemu
-   2 = kernel kqemu
-*/
-int kqemu_allowed = 1;
-uint64_t *pages_to_flush;
-unsigned int nb_pages_to_flush;
-uint64_t *ram_pages_to_update;
-unsigned int nb_ram_pages_to_update;
-uint64_t *modified_ram_pages;
-unsigned int nb_modified_ram_pages;
-uint8_t *modified_ram_pages_table;
-int qpi_io_memory;
-uint32_t kqemu_comm_base; /* physical address of the QPI communication page */
-ram_addr_t kqemu_phys_ram_size;
-uint8_t *kqemu_phys_ram_base;
-
-#define cpuid(index, eax, ebx, ecx, edx) \
-  asm volatile ("cpuid" \
-                : "=a" (eax), "=b" (ebx), "=c" (ecx), "=d" (edx) \
-                : "0" (index))
-
-#ifdef __x86_64__
-static int is_cpuid_supported(void)
-{
-    return 1;
-}
-#else
-static int is_cpuid_supported(void)
-{
-    int v0, v1;
-    asm volatile ("pushf\n"
-                  "popl %0\n"
-                  "movl %0, %1\n"
-                  "xorl $0x00200000, %0\n"
-                  "pushl %0\n"
-                  "popf\n"
-                  "pushf\n"
-                  "popl %0\n"
-                  : "=a" (v0), "=d" (v1)
-                  :
-                  : "cc");
-    return (v0 != v1);
-}
-#endif
-
-static void kqemu_update_cpuid(CPUState *env)
-{
-    int critical_features_mask, features, ext_features, ext_features_mask;
-    uint32_t eax, ebx, ecx, edx;
-
-    /* the following features are kept identical on the host and
-       target cpus because they are important for user code. Strictly
-       speaking, only SSE really matters because the OS must support
-       it if the user code uses it. */
-    critical_features_mask =
-        CPUID_CMOV | CPUID_CX8 |
-        CPUID_FXSR | CPUID_MMX | CPUID_SSE |
-        CPUID_SSE2 | CPUID_SEP;
-    ext_features_mask = CPUID_EXT_SSE3 | CPUID_EXT_MONITOR;
-    if (!is_cpuid_supported()) {
-        features = 0;
-        ext_features = 0;
-    } else {
-        cpuid(1, eax, ebx, ecx, edx);
-        features = edx;
-        ext_features = ecx;
-    }
-#ifdef __x86_64__
-    /* NOTE: on x86_64 CPUs, SYSENTER is not supported in
-       compatibility mode, so in order to have the best performances
-       it is better not to use it */
-    features &= ~CPUID_SEP;
-#endif
-    env->cpuid_features = (env->cpuid_features & ~critical_features_mask) |
-        (features & critical_features_mask);
-    env->cpuid_ext_features = (env->cpuid_ext_features & ~ext_features_mask) |
-        (ext_features & ext_features_mask);
-    /* XXX: we could update more of the target CPUID state so that the
-       non accelerated code sees exactly the same CPU features as the
-       accelerated code */
-}
-
-int kqemu_init(CPUState *env)
-{
-    struct kqemu_init kinit;
-    int ret, version;
-#ifdef _WIN32
-    DWORD temp;
-#endif
-
-    if (!kqemu_allowed)
-        return -1;
-
-#ifdef _WIN32
-    kqemu_fd = CreateFile(KQEMU_DEVICE, GENERIC_WRITE | GENERIC_READ,
-                          FILE_SHARE_READ | FILE_SHARE_WRITE,
-                          NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL,
-                          NULL);
-    if (kqemu_fd == KQEMU_INVALID_FD) {
-        fprintf(stderr, "Could not open '%s' - QEMU acceleration layer not activated: %lu\n",
-                KQEMU_DEVICE, GetLastError());
-        return -1;
-    }
-#else
-    kqemu_fd = open(KQEMU_DEVICE, O_RDWR);
-    if (kqemu_fd == KQEMU_INVALID_FD) {
-        fprintf(stderr, "Could not open '%s' - QEMU acceleration layer not activated: %s\n",
-                KQEMU_DEVICE, strerror(errno));
-        return -1;
-    }
-#endif
-    version = 0;
-#ifdef _WIN32
-    DeviceIoControl(kqemu_fd, KQEMU_GET_VERSION, NULL, 0,
-                    &version, sizeof(version), &temp, NULL);
-#else
-    ioctl(kqemu_fd, KQEMU_GET_VERSION, &version);
-#endif
-    if (version != KQEMU_VERSION) {
-        fprintf(stderr, "Version mismatch between kqemu module and qemu (%08x %08x) - disabling kqemu use\n",
-                version, KQEMU_VERSION);
-        goto fail;
-    }
-
-    pages_to_flush = qemu_vmalloc(KQEMU_MAX_PAGES_TO_FLUSH *
-                                  sizeof(uint64_t));
-    if (!pages_to_flush)
-        goto fail;
-
-    ram_pages_to_update = qemu_vmalloc(KQEMU_MAX_RAM_PAGES_TO_UPDATE *
-                                       sizeof(uint64_t));
-    if (!ram_pages_to_update)
-        goto fail;
-
-    modified_ram_pages = qemu_vmalloc(KQEMU_MAX_MODIFIED_RAM_PAGES *
-                                      sizeof(uint64_t));
-    if (!modified_ram_pages)
-        goto fail;
-    modified_ram_pages_table =
-        qemu_mallocz(kqemu_phys_ram_size >> TARGET_PAGE_BITS);
-    if (!modified_ram_pages_table)
-        goto fail;
-
-    memset(&kinit, 0, sizeof(kinit)); /* set the paddings to zero */
-    kinit.ram_base = kqemu_phys_ram_base;
-    kinit.ram_size = kqemu_phys_ram_size;
-    kinit.ram_dirty = phys_ram_dirty;
-    kinit.pages_to_flush = pages_to_flush;
-    kinit.ram_pages_to_update = ram_pages_to_update;
-    kinit.modified_ram_pages = modified_ram_pages;
-#ifdef _WIN32
-    ret = DeviceIoControl(kqemu_fd, KQEMU_INIT, &kinit, sizeof(kinit),
-                          NULL, 0, &temp, NULL) == TRUE ? 0 : -1;
-#else
-    ret = ioctl(kqemu_fd, KQEMU_INIT, &kinit);
-#endif
-    if (ret < 0) {
-        fprintf(stderr, "Error %d while initializing QEMU acceleration layer - disabling it for now\n", ret);
-    fail:
-        kqemu_closefd(kqemu_fd);
-        kqemu_fd = KQEMU_INVALID_FD;
-        return -1;
-    }
-    kqemu_update_cpuid(env);
-    env->kqemu_enabled = kqemu_allowed;
-    nb_pages_to_flush = 0;
-    nb_ram_pages_to_update = 0;
-
-    qpi_init();
-    return 0;
-}
-
-void kqemu_flush_page(CPUState *env, target_ulong addr)
-{
-    LOG_INT("kqemu_flush_page: addr=" TARGET_FMT_lx "\n", addr);
-    if (nb_pages_to_flush >= KQEMU_MAX_PAGES_TO_FLUSH)
-        nb_pages_to_flush = KQEMU_FLUSH_ALL;
-    else
-        pages_to_flush[nb_pages_to_flush++] = addr;
-}
-
-void kqemu_flush(CPUState *env, int global)
-{
-    LOG_INT("kqemu_flush:\n");
-    nb_pages_to_flush = KQEMU_FLUSH_ALL;
-}
-
-void kqemu_set_notdirty(CPUState *env, ram_addr_t ram_addr)
-{
-    LOG_INT("kqemu_set_notdirty: addr=%08lx\n", 
-                (unsigned long)ram_addr);
-    /* we only track transitions to dirty state */
-    if (phys_ram_dirty[ram_addr >> TARGET_PAGE_BITS] != 0xff)
-        return;
-    if (nb_ram_pages_to_update >= KQEMU_MAX_RAM_PAGES_TO_UPDATE)
-        nb_ram_pages_to_update = KQEMU_RAM_PAGES_UPDATE_ALL;
-    else
-        ram_pages_to_update[nb_ram_pages_to_update++] = ram_addr;
-}
-
-static void kqemu_reset_modified_ram_pages(void)
-{
-    int i;
-    unsigned long page_index;
-
-    for(i = 0; i < nb_modified_ram_pages; i++) {
-        page_index = modified_ram_pages[i] >> TARGET_PAGE_BITS;
-        modified_ram_pages_table[page_index] = 0;
-    }
-    nb_modified_ram_pages = 0;
-}
-
-void kqemu_modify_page(CPUState *env, ram_addr_t ram_addr)
-{
-    unsigned long page_index;
-    int ret;
-#ifdef _WIN32
-    DWORD temp;
-#endif
-
-    page_index = ram_addr >> TARGET_PAGE_BITS;
-    if (!modified_ram_pages_table[page_index]) {
-#if 0
-        printf("%d: modify_page=%08lx\n", nb_modified_ram_pages, ram_addr);
-#endif
-        modified_ram_pages_table[page_index] = 1;
-        modified_ram_pages[nb_modified_ram_pages++] = ram_addr;
-        if (nb_modified_ram_pages >= KQEMU_MAX_MODIFIED_RAM_PAGES) {
-            /* flush */
-#ifdef _WIN32
-            ret = DeviceIoControl(kqemu_fd, KQEMU_MODIFY_RAM_PAGES,
-                                  &nb_modified_ram_pages,
-                                  sizeof(nb_modified_ram_pages),
-                                  NULL, 0, &temp, NULL);
-#else
-            ret = ioctl(kqemu_fd, KQEMU_MODIFY_RAM_PAGES,
-                        &nb_modified_ram_pages);
-#endif
-            kqemu_reset_modified_ram_pages();
-        }
-    }
-}
-
-void kqemu_set_phys_mem(uint64_t start_addr, ram_addr_t size, 
-                        ram_addr_t phys_offset)
-{
-    struct kqemu_phys_mem kphys_mem1, *kphys_mem = &kphys_mem1;
-    uint64_t end;
-    int ret, io_index;
-
-    end = (start_addr + size + TARGET_PAGE_SIZE - 1) & TARGET_PAGE_MASK;
-    start_addr &= TARGET_PAGE_MASK;
-    kphys_mem->phys_addr = start_addr;
-    kphys_mem->size = end - start_addr;
-    kphys_mem->ram_addr = phys_offset & TARGET_PAGE_MASK;
-    io_index = phys_offset & ~TARGET_PAGE_MASK;
-    switch(io_index) {
-    case IO_MEM_RAM:
-        kphys_mem->io_index = KQEMU_IO_MEM_RAM;
-        break;
-    case IO_MEM_ROM:
-        kphys_mem->io_index = KQEMU_IO_MEM_ROM;
-        break;
-    default:
-        if (qpi_io_memory == io_index) {
-            kphys_mem->io_index = KQEMU_IO_MEM_COMM;
-        } else {
-            kphys_mem->io_index = KQEMU_IO_MEM_UNASSIGNED;
-        }
-        break;
-    }
-#ifdef _WIN32
-    {
-        DWORD temp;
-        ret = DeviceIoControl(kqemu_fd, KQEMU_SET_PHYS_MEM, 
-                              kphys_mem, sizeof(*kphys_mem),
-                              NULL, 0, &temp, NULL) == TRUE ? 0 : -1;
-    }
-#else
-    ret = ioctl(kqemu_fd, KQEMU_SET_PHYS_MEM, kphys_mem);
-#endif
-    if (ret < 0) {
-        fprintf(stderr, "kqemu: KQEMU_SET_PHYS_PAGE error=%d: start_addr=0x%016" PRIx64 " size=0x%08lx phys_offset=0x%08lx\n",
-                ret, start_addr, 
-                (unsigned long)size, (unsigned long)phys_offset);
-    }
-}
-
-struct fpstate {
-    uint16_t fpuc;
-    uint16_t dummy1;
-    uint16_t fpus;
-    uint16_t dummy2;
-    uint16_t fptag;
-    uint16_t dummy3;
-
-    uint32_t fpip;
-    uint32_t fpcs;
-    uint32_t fpoo;
-    uint32_t fpos;
-    uint8_t fpregs1[8 * 10];
-};
-
-struct fpxstate {
-    uint16_t fpuc;
-    uint16_t fpus;
-    uint16_t fptag;
-    uint16_t fop;
-    uint32_t fpuip;
-    uint16_t cs_sel;
-    uint16_t dummy0;
-    uint32_t fpudp;
-    uint16_t ds_sel;
-    uint16_t dummy1;
-    uint32_t mxcsr;
-    uint32_t mxcsr_mask;
-    uint8_t fpregs1[8 * 16];
-    uint8_t xmm_regs[16 * 16];
-    uint8_t dummy2[96];
-};
-
-static struct fpxstate fpx1 __attribute__((aligned(16)));
-
-static void restore_native_fp_frstor(CPUState *env)
-{
-    int fptag, i, j;
-    struct fpstate fp1, *fp = &fp1;
-
-    fp->fpuc = env->fpuc;
-    fp->fpus = (env->fpus & ~0x3800) | (env->fpstt & 0x7) << 11;
-    fptag = 0;
-    for (i=7; i>=0; i--) {
-	fptag <<= 2;
-	if (env->fptags[i]) {
-            fptag |= 3;
-        } else {
-            /* the FPU automatically computes it */
-        }
-    }
-    fp->fptag = fptag;
-    j = env->fpstt;
-    for(i = 0;i < 8; i++) {
-        memcpy(&fp->fpregs1[i * 10], &env->fpregs[j].d, 10);
-        j = (j + 1) & 7;
-    }
-    asm volatile ("frstor %0" : "=m" (*fp));
-}
-
-static void save_native_fp_fsave(CPUState *env)
-{
-    int fptag, i, j;
-    uint16_t fpuc;
-    struct fpstate fp1, *fp = &fp1;
-
-    asm volatile ("fsave %0" : : "m" (*fp));
-    env->fpuc = fp->fpuc;
-    env->fpstt = (fp->fpus >> 11) & 7;
-    env->fpus = fp->fpus & ~0x3800;
-    fptag = fp->fptag;
-    for(i = 0;i < 8; i++) {
-        env->fptags[i] = ((fptag & 3) == 3);
-        fptag >>= 2;
-    }
-    j = env->fpstt;
-    for(i = 0;i < 8; i++) {
-        memcpy(&env->fpregs[j].d, &fp->fpregs1[i * 10], 10);
-        j = (j + 1) & 7;
-    }
-    /* we must restore the default rounding state */
-    fpuc = 0x037f | (env->fpuc & (3 << 10));
-    asm volatile("fldcw %0" : : "m" (fpuc));
-}
-
-static void restore_native_fp_fxrstor(CPUState *env)
-{
-    struct fpxstate *fp = &fpx1;
-    int i, j, fptag;
-
-    fp->fpuc = env->fpuc;
-    fp->fpus = (env->fpus & ~0x3800) | (env->fpstt & 0x7) << 11;
-    fptag = 0;
-    for(i = 0; i < 8; i++)
-        fptag |= (env->fptags[i] << i);
-    fp->fptag = fptag ^ 0xff;
-
-    j = env->fpstt;
-    for(i = 0;i < 8; i++) {
-        memcpy(&fp->fpregs1[i * 16], &env->fpregs[j].d, 10);
-        j = (j + 1) & 7;
-    }
-    if (env->cpuid_features & CPUID_SSE) {
-        fp->mxcsr = env->mxcsr;
-        /* XXX: check if DAZ is not available */
-        fp->mxcsr_mask = 0xffff;
-        memcpy(fp->xmm_regs, env->xmm_regs, CPU_NB_REGS * 16);
-    }
-    asm volatile ("fxrstor %0" : "=m" (*fp));
-}
-
-static void save_native_fp_fxsave(CPUState *env)
-{
-    struct fpxstate *fp = &fpx1;
-    int fptag, i, j;
-    uint16_t fpuc;
-
-    asm volatile ("fxsave %0" : : "m" (*fp));
-    env->fpuc = fp->fpuc;
-    env->fpstt = (fp->fpus >> 11) & 7;
-    env->fpus = fp->fpus & ~0x3800;
-    fptag = fp->fptag ^ 0xff;
-    for(i = 0;i < 8; i++) {
-        env->fptags[i] = (fptag >> i) & 1;
-    }
-    j = env->fpstt;
-    for(i = 0;i < 8; i++) {
-        memcpy(&env->fpregs[j].d, &fp->fpregs1[i * 16], 10);
-        j = (j + 1) & 7;
-    }
-    if (env->cpuid_features & CPUID_SSE) {
-        env->mxcsr = fp->mxcsr;
-        memcpy(env->xmm_regs, fp->xmm_regs, CPU_NB_REGS * 16);
-    }
-
-    /* we must restore the default rounding state */
-    asm volatile ("fninit");
-    fpuc = 0x037f | (env->fpuc & (3 << 10));
-    asm volatile("fldcw %0" : : "m" (fpuc));
-}
-
-static int do_syscall(CPUState *env,
-                      struct kqemu_cpu_state *kenv)
-{
-    int selector;
-
-    selector = (env->star >> 32) & 0xffff;
-#ifdef TARGET_X86_64
-    if (env->hflags & HF_LMA_MASK) {
-        int code64;
-
-        env->regs[R_ECX] = kenv->next_eip;
-        env->regs[11] = env->eflags;
-
-        code64 = env->hflags & HF_CS64_MASK;
-
-        cpu_x86_set_cpl(env, 0);
-        cpu_x86_load_seg_cache(env, R_CS, selector & 0xfffc,
-                               0, 0xffffffff,
-                               DESC_G_MASK | DESC_P_MASK |
-                               DESC_S_MASK |
-                               DESC_CS_MASK | DESC_R_MASK | DESC_A_MASK | DESC_L_MASK);
-        cpu_x86_load_seg_cache(env, R_SS, (selector + 8) & 0xfffc,
-                               0, 0xffffffff,
-                               DESC_G_MASK | DESC_B_MASK | DESC_P_MASK |
-                               DESC_S_MASK |
-                               DESC_W_MASK | DESC_A_MASK);
-        env->eflags &= ~env->fmask;
-        if (code64)
-            env->eip = env->lstar;
-        else
-            env->eip = env->cstar;
-    } else
-#endif
-    {
-        env->regs[R_ECX] = (uint32_t)kenv->next_eip;
-
-        cpu_x86_set_cpl(env, 0);
-        cpu_x86_load_seg_cache(env, R_CS, selector & 0xfffc,
-                           0, 0xffffffff,
-                               DESC_G_MASK | DESC_B_MASK | DESC_P_MASK |
-                               DESC_S_MASK |
-                               DESC_CS_MASK | DESC_R_MASK | DESC_A_MASK);
-        cpu_x86_load_seg_cache(env, R_SS, (selector + 8) & 0xfffc,
-                               0, 0xffffffff,
-                               DESC_G_MASK | DESC_B_MASK | DESC_P_MASK |
-                               DESC_S_MASK |
-                               DESC_W_MASK | DESC_A_MASK);
-        env->eflags &= ~(IF_MASK | RF_MASK | VM_MASK);
-        env->eip = (uint32_t)env->star;
-    }
-    return 2;
-}
-
-#ifdef CONFIG_PROFILER
-
-#define PC_REC_SIZE 1
-#define PC_REC_HASH_BITS 16
-#define PC_REC_HASH_SIZE (1 << PC_REC_HASH_BITS)
-
-typedef struct PCRecord {
-    unsigned long pc;
-    int64_t count;
-    struct PCRecord *next;
-} PCRecord;
-
-static PCRecord *pc_rec_hash[PC_REC_HASH_SIZE];
-static int nb_pc_records;
-
-static void kqemu_record_pc(unsigned long pc)
-{
-    unsigned long h;
-    PCRecord **pr, *r;
-
-    h = pc / PC_REC_SIZE;
-    h = h ^ (h >> PC_REC_HASH_BITS);
-    h &= (PC_REC_HASH_SIZE - 1);
-    pr = &pc_rec_hash[h];
-    for(;;) {
-        r = *pr;
-        if (r == NULL)
-            break;
-        if (r->pc == pc) {
-            r->count++;
-            return;
-        }
-        pr = &r->next;
-    }
-    r = malloc(sizeof(PCRecord));
-    r->count = 1;
-    r->pc = pc;
-    r->next = NULL;
-    *pr = r;
-    nb_pc_records++;
-}
-
-static int pc_rec_cmp(const void *p1, const void *p2)
-{
-    PCRecord *r1 = *(PCRecord **)p1;
-    PCRecord *r2 = *(PCRecord **)p2;
-    if (r1->count < r2->count)
-        return 1;
-    else if (r1->count == r2->count)
-        return 0;
-    else
-        return -1;
-}
-
-static void kqemu_record_flush(void)
-{
-    PCRecord *r, *r_next;
-    int h;
-
-    for(h = 0; h < PC_REC_HASH_SIZE; h++) {
-        for(r = pc_rec_hash[h]; r != NULL; r = r_next) {
-            r_next = r->next;
-            free(r);
-        }
-        pc_rec_hash[h] = NULL;
-    }
-    nb_pc_records = 0;
-}
-
-void kqemu_record_dump(void)
-{
-    PCRecord **pr, *r;
-    int i, h;
-    FILE *f;
-    int64_t total, sum;
-
-    pr = malloc(sizeof(PCRecord *) * nb_pc_records);
-    i = 0;
-    total = 0;
-    for(h = 0; h < PC_REC_HASH_SIZE; h++) {
-        for(r = pc_rec_hash[h]; r != NULL; r = r->next) {
-            pr[i++] = r;
-            total += r->count;
-        }
-    }
-    qsort(pr, nb_pc_records, sizeof(PCRecord *), pc_rec_cmp);
-
-    f = fopen("/tmp/kqemu.stats", "w");
-    if (!f) {
-        perror("/tmp/kqemu.stats");
-        exit(1);
-    }
-    fprintf(f, "total: %" PRId64 "\n", total);
-    sum = 0;
-    for(i = 0; i < nb_pc_records; i++) {
-        r = pr[i];
-        sum += r->count;
-        fprintf(f, "%08lx: %" PRId64 " %0.2f%% %0.2f%%\n",
-                r->pc,
-                r->count,
-                (double)r->count / (double)total * 100.0,
-                (double)sum / (double)total * 100.0);
-    }
-    fclose(f);
-    free(pr);
-
-    kqemu_record_flush();
-}
-#endif
-
-static inline void kqemu_load_seg(struct kqemu_segment_cache *ksc,
-                                  const SegmentCache *sc)
-{
-    ksc->selector = sc->selector;
-    ksc->flags = sc->flags;
-    ksc->limit = sc->limit;
-    ksc->base = sc->base;
-}
-
-static inline void kqemu_save_seg(SegmentCache *sc,
-                                  const struct kqemu_segment_cache *ksc)
-{
-    sc->selector = ksc->selector;
-    sc->flags = ksc->flags;
-    sc->limit = ksc->limit;
-    sc->base = ksc->base;
-}
-
-int kqemu_cpu_exec(CPUState *env)
-{
-    struct kqemu_cpu_state kcpu_state, *kenv = &kcpu_state;
-    int ret, cpl, i;
-#ifdef CONFIG_PROFILER
-    int64_t ti;
-#endif
-#ifdef _WIN32
-    DWORD temp;
-#endif
-
-#ifdef CONFIG_PROFILER
-    ti = profile_getclock();
-#endif
-    LOG_INT("kqemu: cpu_exec: enter\n");
-    LOG_INT_STATE(env);
-    for(i = 0; i < CPU_NB_REGS; i++)
-        kenv->regs[i] = env->regs[i];
-    kenv->eip = env->eip;
-    kenv->eflags = env->eflags;
-    for(i = 0; i < 6; i++)
-        kqemu_load_seg(&kenv->segs[i], &env->segs[i]);
-    kqemu_load_seg(&kenv->ldt, &env->ldt);
-    kqemu_load_seg(&kenv->tr, &env->tr);
-    kqemu_load_seg(&kenv->gdt, &env->gdt);
-    kqemu_load_seg(&kenv->idt, &env->idt);
-    kenv->cr0 = env->cr[0];
-    kenv->cr2 = env->cr[2];
-    kenv->cr3 = env->cr[3];
-    kenv->cr4 = env->cr[4];
-    kenv->a20_mask = env->a20_mask;
-    kenv->efer = env->efer;
-    kenv->tsc_offset = 0;
-    kenv->star = env->star;
-    kenv->sysenter_cs = env->sysenter_cs;
-    kenv->sysenter_esp = env->sysenter_esp;
-    kenv->sysenter_eip = env->sysenter_eip;
-#ifdef TARGET_X86_64
-    kenv->lstar = env->lstar;
-    kenv->cstar = env->cstar;
-    kenv->fmask = env->fmask;
-    kenv->kernelgsbase = env->kernelgsbase;
-#endif
-    if (env->dr[7] & 0xff) {
-        kenv->dr7 = env->dr[7];
-        kenv->dr0 = env->dr[0];
-        kenv->dr1 = env->dr[1];
-        kenv->dr2 = env->dr[2];
-        kenv->dr3 = env->dr[3];
-    } else {
-        kenv->dr7 = 0;
-    }
-    kenv->dr6 = env->dr[6];
-    cpl = (env->hflags & HF_CPL_MASK);
-    kenv->cpl = cpl;
-    kenv->nb_pages_to_flush = nb_pages_to_flush;
-    kenv->user_only = (env->kqemu_enabled == 1);
-    kenv->nb_ram_pages_to_update = nb_ram_pages_to_update;
-    nb_ram_pages_to_update = 0;
-    kenv->nb_modified_ram_pages = nb_modified_ram_pages;
-
-    kqemu_reset_modified_ram_pages();
-
-    if (env->cpuid_features & CPUID_FXSR)
-        restore_native_fp_fxrstor(env);
-    else
-        restore_native_fp_frstor(env);
-
-#ifdef _WIN32
-    if (DeviceIoControl(kqemu_fd, KQEMU_EXEC,
-                        kenv, sizeof(struct kqemu_cpu_state),
-                        kenv, sizeof(struct kqemu_cpu_state),
-                        &temp, NULL)) {
-        ret = kenv->retval;
-    } else {
-        ret = -1;
-    }
-#else
-    ioctl(kqemu_fd, KQEMU_EXEC, kenv);
-    ret = kenv->retval;
-#endif
-    if (env->cpuid_features & CPUID_FXSR)
-        save_native_fp_fxsave(env);
-    else
-        save_native_fp_fsave(env);
-
-    for(i = 0; i < CPU_NB_REGS; i++)
-        env->regs[i] = kenv->regs[i];
-    env->eip = kenv->eip;
-    env->eflags = kenv->eflags;
-    for(i = 0; i < 6; i++)
-        kqemu_save_seg(&env->segs[i], &kenv->segs[i]);
-    cpu_x86_set_cpl(env, kenv->cpl);
-    kqemu_save_seg(&env->ldt, &kenv->ldt);
-    env->cr[0] = kenv->cr0;
-    env->cr[4] = kenv->cr4;
-    env->cr[3] = kenv->cr3;
-    env->cr[2] = kenv->cr2;
-    env->dr[6] = kenv->dr6;
-#ifdef TARGET_X86_64
-    env->kernelgsbase = kenv->kernelgsbase;
-#endif
-
-    /* flush pages as indicated by kqemu */
-    if (kenv->nb_pages_to_flush >= KQEMU_FLUSH_ALL) {
-        tlb_flush(env, 1);
-    } else {
-        for(i = 0; i < kenv->nb_pages_to_flush; i++) {
-            tlb_flush_page(env, pages_to_flush[i]);
-        }
-    }
-    nb_pages_to_flush = 0;
-
-#ifdef CONFIG_PROFILER
-    kqemu_time += profile_getclock() - ti;
-    kqemu_exec_count++;
-#endif
-
-    if (kenv->nb_ram_pages_to_update > 0) {
-        cpu_tlb_update_dirty(env);
-    }
-
-    if (kenv->nb_modified_ram_pages > 0) {
-        for(i = 0; i < kenv->nb_modified_ram_pages; i++) {
-            unsigned long addr;
-            addr = modified_ram_pages[i];
-            tb_invalidate_phys_page_range(addr, addr + TARGET_PAGE_SIZE, 0);
-        }
-    }
-
-    /* restore the hidden flags */
-    {
-        unsigned int new_hflags;
-#ifdef TARGET_X86_64
-        if ((env->hflags & HF_LMA_MASK) &&
-            (env->segs[R_CS].flags & DESC_L_MASK)) {
-            /* long mode */
-            new_hflags = HF_CS32_MASK | HF_SS32_MASK | HF_CS64_MASK;
-        } else
-#endif
-        {
-            /* legacy / compatibility case */
-            new_hflags = (env->segs[R_CS].flags & DESC_B_MASK)
-                >> (DESC_B_SHIFT - HF_CS32_SHIFT);
-            new_hflags |= (env->segs[R_SS].flags & DESC_B_MASK)
-                >> (DESC_B_SHIFT - HF_SS32_SHIFT);
-            if (!(env->cr[0] & CR0_PE_MASK) ||
-                   (env->eflags & VM_MASK) ||
-                   !(env->hflags & HF_CS32_MASK)) {
-                /* XXX: try to avoid this test. The problem comes from the
-                   fact that is real mode or vm86 mode we only modify the
-                   'base' and 'selector' fields of the segment cache to go
-                   faster. A solution may be to force addseg to one in
-                   translate-i386.c. */
-                new_hflags |= HF_ADDSEG_MASK;
-            } else {
-                new_hflags |= ((env->segs[R_DS].base |
-                                env->segs[R_ES].base |
-                                env->segs[R_SS].base) != 0) <<
-                    HF_ADDSEG_SHIFT;
-            }
-        }
-        env->hflags = (env->hflags &
-           ~(HF_CS32_MASK | HF_SS32_MASK | HF_CS64_MASK | HF_ADDSEG_MASK)) |
-            new_hflags;
-    }
-    /* update FPU flags */
-    env->hflags = (env->hflags & ~(HF_MP_MASK | HF_EM_MASK | HF_TS_MASK)) |
-        ((env->cr[0] << (HF_MP_SHIFT - 1)) & (HF_MP_MASK | HF_EM_MASK | HF_TS_MASK));
-    if (env->cr[4] & CR4_OSFXSR_MASK)
-        env->hflags |= HF_OSFXSR_MASK;
-    else
-        env->hflags &= ~HF_OSFXSR_MASK;
-
-    LOG_INT("kqemu: kqemu_cpu_exec: ret=0x%x\n", ret);
-    if (ret == KQEMU_RET_SYSCALL) {
-        /* syscall instruction */
-        return do_syscall(env, kenv);
-    } else
-    if ((ret & 0xff00) == KQEMU_RET_INT) {
-        env->exception_index = ret & 0xff;
-        env->error_code = 0;
-        env->exception_is_int = 1;
-        env->exception_next_eip = kenv->next_eip;
-#ifdef CONFIG_PROFILER
-        kqemu_ret_int_count++;
-#endif
-        LOG_INT("kqemu: interrupt v=%02x:\n", env->exception_index);
-        LOG_INT_STATE(env);
-        return 1;
-    } else if ((ret & 0xff00) == KQEMU_RET_EXCEPTION) {
-        env->exception_index = ret & 0xff;
-        env->error_code = kenv->error_code;
-        env->exception_is_int = 0;
-        env->exception_next_eip = 0;
-#ifdef CONFIG_PROFILER
-        kqemu_ret_excp_count++;
-#endif
-        LOG_INT("kqemu: exception v=%02x e=%04x:\n",
-                    env->exception_index, env->error_code);
-        LOG_INT_STATE(env);
-        return 1;
-    } else if (ret == KQEMU_RET_INTR) {
-#ifdef CONFIG_PROFILER
-        kqemu_ret_intr_count++;
-#endif
-        LOG_INT_STATE(env);
-        return 0;
-    } else if (ret == KQEMU_RET_SOFTMMU) {
-#ifdef CONFIG_PROFILER
-        {
-            unsigned long pc = env->eip + env->segs[R_CS].base;
-            kqemu_record_pc(pc);
-        }
-#endif
-        LOG_INT_STATE(env);
-        return 2;
-    } else {
-        cpu_dump_state(env, stderr, fprintf, 0);
-        fprintf(stderr, "Unsupported return value: 0x%x\n", ret);
-        exit(1);
-    }
-    return 0;
-}
-
-void kqemu_cpu_interrupt(CPUState *env)
-{
-#if defined(_WIN32)
-    /* cancelling the I/O request causes KQEMU to finish executing the
-       current block and successfully returning. */
-    CancelIo(kqemu_fd);
-#endif
-}
-
-/* 
-   QEMU paravirtualization interface. The current interface only
-   allows to modify the IF and IOPL flags when running in
-   kqemu.
-
-   At this point it is not very satisfactory. I leave it for reference
-   as it adds little complexity.
-*/
-
-#define QPI_COMM_PAGE_PHYS_ADDR 0xff000000
-
-static uint32_t qpi_mem_readb(void *opaque, target_phys_addr_t addr)
-{
-    return 0;
-}
-
-static uint32_t qpi_mem_readw(void *opaque, target_phys_addr_t addr)
-{
-    return 0;
-}
-
-static void qpi_mem_writeb(void *opaque, target_phys_addr_t addr, uint32_t val)
-{
-}
-
-static void qpi_mem_writew(void *opaque, target_phys_addr_t addr, uint32_t val)
-{
-}
-
-static uint32_t qpi_mem_readl(void *opaque, target_phys_addr_t addr)
-{
-    CPUState *env;
-
-    env = cpu_single_env;
-    if (!env)
-        return 0;
-    return env->eflags & (IF_MASK | IOPL_MASK);
-}
-
-/* Note: after writing to this address, the guest code must make sure
-   it is exiting the current TB. pushf/popf can be used for that
-   purpose. */
-static void qpi_mem_writel(void *opaque, target_phys_addr_t addr, uint32_t val)
-{
-    CPUState *env;
-
-    env = cpu_single_env;
-    if (!env)
-        return;
-    env->eflags = (env->eflags & ~(IF_MASK | IOPL_MASK)) | 
-        (val & (IF_MASK | IOPL_MASK));
-}
-
-static CPUReadMemoryFunc *qpi_mem_read[3] = {
-    qpi_mem_readb,
-    qpi_mem_readw,
-    qpi_mem_readl,
-};
-
-static CPUWriteMemoryFunc *qpi_mem_write[3] = {
-    qpi_mem_writeb,
-    qpi_mem_writew,
-    qpi_mem_writel,
-};
-
-static void qpi_init(void)
-{
-    kqemu_comm_base = 0xff000000 | 1;
-    qpi_io_memory = cpu_register_io_memory(0, 
-                                           qpi_mem_read, 
-                                           qpi_mem_write, NULL);
-    cpu_register_physical_memory(kqemu_comm_base & ~0xfff, 
-                                 0x1000, qpi_io_memory);
-}
-#endif
diff --git a/kqemu.h b/kqemu.h
deleted file mode 100644
index ed25c75..0000000
--- a/kqemu.h
+++ /dev/null
@@ -1,154 +0,0 @@
-/*
- * KQEMU header
- * 
- * Copyright (c) 2004-2008 Fabrice Bellard
- * 
- * Permission is hereby granted, free of charge, to any person obtaining a copy
- * of this software and associated documentation files (the "Software"), to deal
- * in the Software without restriction, including without limitation the rights
- * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
- * copies of the Software, and to permit persons to whom the Software is
- * furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice shall be included in
- * all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
- * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
- * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
- * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
- * THE SOFTWARE.
- */
-#ifndef KQEMU_H
-#define KQEMU_H
-
-#if defined(__i386__)
-#define KQEMU_PAD32(x) x
-#else
-#define KQEMU_PAD32(x)
-#endif
-
-#define KQEMU_VERSION 0x010400
-
-struct kqemu_segment_cache {
-    uint16_t selector;
-    uint16_t padding1;
-    uint32_t flags;
-    uint64_t base;
-    uint32_t limit;
-    uint32_t padding2;
-};
-
-struct kqemu_cpu_state {
-    uint64_t regs[16];
-    uint64_t eip;
-    uint64_t eflags;
-
-    struct kqemu_segment_cache segs[6]; /* selector values */
-    struct kqemu_segment_cache ldt;
-    struct kqemu_segment_cache tr;
-    struct kqemu_segment_cache gdt; /* only base and limit are used */
-    struct kqemu_segment_cache idt; /* only base and limit are used */
-
-    uint64_t cr0;
-    uint64_t cr2;
-    uint64_t cr3;
-    uint64_t cr4;
-    uint64_t a20_mask;
-
-    /* sysenter registers */
-    uint64_t sysenter_cs;
-    uint64_t sysenter_esp;
-    uint64_t sysenter_eip;
-    uint64_t efer;
-    uint64_t star;
-    
-    uint64_t lstar;
-    uint64_t cstar;
-    uint64_t fmask;
-    uint64_t kernelgsbase;
-
-    uint64_t tsc_offset;
-
-    uint64_t dr0;
-    uint64_t dr1;
-    uint64_t dr2;
-    uint64_t dr3;
-    uint64_t dr6;
-    uint64_t dr7;
-
-    uint8_t cpl;
-    uint8_t user_only;
-    uint16_t padding1;
-
-    uint32_t error_code; /* error_code when exiting with an exception */
-    uint64_t next_eip; /* next eip value when exiting with an interrupt */
-    uint32_t nb_pages_to_flush; /* number of pages to flush,
-                                       KQEMU_FLUSH_ALL means full flush */
-#define KQEMU_MAX_PAGES_TO_FLUSH 512
-#define KQEMU_FLUSH_ALL (KQEMU_MAX_PAGES_TO_FLUSH + 1)
-
-    int32_t retval;
-
-    /* number of ram_dirty entries to update */
-    uint32_t nb_ram_pages_to_update; 
-#define KQEMU_MAX_RAM_PAGES_TO_UPDATE 512
-#define KQEMU_RAM_PAGES_UPDATE_ALL (KQEMU_MAX_RAM_PAGES_TO_UPDATE + 1)
-
-#define KQEMU_MAX_MODIFIED_RAM_PAGES 512
-    uint32_t nb_modified_ram_pages;
-};
-
-struct kqemu_init {
-    uint8_t *ram_base; /* must be page aligned */
-    KQEMU_PAD32(uint32_t padding1;)
-    uint64_t ram_size; /* must be multiple of 4 KB */
-    uint8_t *ram_dirty; /* must be page aligned */
-    KQEMU_PAD32(uint32_t padding2;)
-    uint64_t *pages_to_flush; /* must be page aligned */
-    KQEMU_PAD32(uint32_t padding4;)
-    uint64_t *ram_pages_to_update; /* must be page aligned */
-    KQEMU_PAD32(uint32_t padding5;)
-    uint64_t *modified_ram_pages; /* must be page aligned */
-    KQEMU_PAD32(uint32_t padding6;)
-};
-
-#define KQEMU_IO_MEM_RAM        0
-#define KQEMU_IO_MEM_ROM        1
-#define KQEMU_IO_MEM_COMM       2 /* kqemu communication page */
-#define KQEMU_IO_MEM_UNASSIGNED 3 /* any device: return to application */
-
-struct kqemu_phys_mem {
-    uint64_t phys_addr; /* physical address range: phys_addr,
-                           phys_addr + size */
-    uint64_t size;        
-    uint64_t ram_addr;  /* corresponding ram address */
-    uint32_t io_index;  /* memory type: see KQEMU_IO_MEM_xxx */
-    uint32_t padding1;
-};
-
-#define KQEMU_RET_ABORT    (-1)
-#define KQEMU_RET_EXCEPTION 0x0000 /* 8 low order bit are the exception */
-#define KQEMU_RET_INT       0x0100 /* 8 low order bit are the interrupt */
-#define KQEMU_RET_SOFTMMU   0x0200 /* emulation needed (I/O or
-                                      unsupported INSN) */
-#define KQEMU_RET_INTR      0x0201 /* interrupted by a signal */
-#define KQEMU_RET_SYSCALL   0x0300 /* syscall insn */
-
-#ifdef _WIN32
-#define KQEMU_EXEC             CTL_CODE(FILE_DEVICE_UNKNOWN, 1, METHOD_BUFFERED, FILE_READ_ACCESS | FILE_WRITE_ACCESS)
-#define KQEMU_INIT             CTL_CODE(FILE_DEVICE_UNKNOWN, 2, METHOD_BUFFERED, FILE_WRITE_ACCESS)
-#define KQEMU_GET_VERSION      CTL_CODE(FILE_DEVICE_UNKNOWN, 3, METHOD_BUFFERED, FILE_READ_ACCESS)
-#define KQEMU_MODIFY_RAM_PAGES CTL_CODE(FILE_DEVICE_UNKNOWN, 4, METHOD_BUFFERED, FILE_WRITE_ACCESS)
-#define KQEMU_SET_PHYS_MEM     CTL_CODE(FILE_DEVICE_UNKNOWN, 5, METHOD_BUFFERED, FILE_WRITE_ACCESS)
-#else
-#define KQEMU_EXEC             _IOWR('q', 1, struct kqemu_cpu_state)
-#define KQEMU_INIT             _IOW('q', 2, struct kqemu_init)
-#define KQEMU_GET_VERSION      _IOR('q', 3, int)
-#define KQEMU_MODIFY_RAM_PAGES _IOW('q', 4, int)
-#define KQEMU_SET_PHYS_MEM     _IOW('q', 5, struct kqemu_phys_mem)
-#endif
-
-#endif /* KQEMU_H */
diff --git a/monitor.c b/monitor.c
index 55b09c3..f28879a 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1372,35 +1372,6 @@ static void tlb_info(Monitor *mon)
 
 #endif
 
-static void do_info_kqemu(Monitor *mon)
-{
-#ifdef CONFIG_KQEMU
-    CPUState *env;
-    int val;
-    val = 0;
-    env = mon_get_cpu();
-    if (!env) {
-        monitor_printf(mon, "No cpu initialized yet");
-        return;
-    }
-    val = env->kqemu_enabled;
-    monitor_printf(mon, "kqemu support: ");
-    switch(val) {
-    default:
-    case 0:
-        monitor_printf(mon, "disabled\n");
-        break;
-    case 1:
-        monitor_printf(mon, "enabled for user code\n");
-        break;
-    case 2:
-        monitor_printf(mon, "enabled for user and kernel code\n");
-        break;
-    }
-#else
-    monitor_printf(mon, "kqemu support: not compiled\n");
-#endif
-}
 
 static void do_info_kvm(Monitor *mon)
 {
@@ -1436,13 +1407,8 @@ static void do_info_numa(Monitor *mon)
 
 #ifdef CONFIG_PROFILER
 
-int64_t kqemu_time;
 int64_t qemu_time;
-int64_t kqemu_exec_count;
 int64_t dev_time;
-int64_t kqemu_ret_int_count;
-int64_t kqemu_ret_excp_count;
-int64_t kqemu_ret_intr_count;
 
 static void do_info_profile(Monitor *mon)
 {
@@ -1454,25 +1420,8 @@ static void do_info_profile(Monitor *mon)
                    dev_time, dev_time / (double)ticks_per_sec);
     monitor_printf(mon, "qemu time   %" PRId64 " (%0.3f)\n",
                    qemu_time, qemu_time / (double)ticks_per_sec);
-    monitor_printf(mon, "kqemu time  %" PRId64 " (%0.3f %0.1f%%) count=%"
-                        PRId64 " int=%" PRId64 " excp=%" PRId64 " intr=%"
-                        PRId64 "\n",
-                   kqemu_time, kqemu_time / (double)ticks_per_sec,
-                   kqemu_time / (double)total * 100.0,
-                   kqemu_exec_count,
-                   kqemu_ret_int_count,
-                   kqemu_ret_excp_count,
-                   kqemu_ret_intr_count);
     qemu_time = 0;
-    kqemu_time = 0;
-    kqemu_exec_count = 0;
     dev_time = 0;
-    kqemu_ret_int_count = 0;
-    kqemu_ret_excp_count = 0;
-    kqemu_ret_intr_count = 0;
-#ifdef CONFIG_KQEMU
-    kqemu_record_dump();
-#endif
 }
 #else
 static void do_info_profile(Monitor *mon)
@@ -1815,8 +1764,6 @@ static const mon_cmd_t info_cmds[] = {
 #endif
     { "jit", "", do_info_jit,
       "", "show dynamic compiler info", },
-    { "kqemu", "", do_info_kqemu,
-      "", "show KQEMU information", },
     { "kvm", "", do_info_kvm,
       "", "show KVM information", },
     { "numa", "", do_info_numa,
diff --git a/osdep.c b/osdep.c
index b300ba1..72df8d2 100644
--- a/osdep.c
+++ b/osdep.c
@@ -72,115 +72,6 @@ void qemu_vfree(void *ptr)
 
 #else
 
-#if defined(CONFIG_KQEMU)
-
-#ifdef __OpenBSD__
-#include <sys/param.h>
-#include <sys/types.h>
-#include <sys/mount.h>
-#else
-#ifndef __FreeBSD__
-#include <sys/vfs.h>
-#endif
-#endif
-
-#include <sys/mman.h>
-#include <fcntl.h>
-
-static void *kqemu_vmalloc(size_t size)
-{
-    static int phys_ram_fd = -1;
-    static int phys_ram_size = 0;
-    void *ptr;
-
-/* no need (?) for a dummy file on OpenBSD/FreeBSD */
-#if defined(__OpenBSD__) || defined(__FreeBSD__) || defined(__DragonFly__)
-    int map_anon = MAP_ANON;
-#else
-    int map_anon = 0;
-    const char *tmpdir;
-    char phys_ram_file[1024];
-#ifdef HOST_SOLARIS
-    struct statvfs stfs;
-#else
-    struct statfs stfs;
-#endif
-
-    if (phys_ram_fd < 0) {
-        tmpdir = getenv("QEMU_TMPDIR");
-        if (!tmpdir)
-#ifdef HOST_SOLARIS
-            tmpdir = "/tmp";
-        if (statvfs(tmpdir, &stfs) == 0) {
-#else
-            tmpdir = "/dev/shm";
-        if (statfs(tmpdir, &stfs) == 0) {
-#endif
-            int64_t free_space;
-            int ram_mb;
-
-            free_space = (int64_t)stfs.f_bavail * stfs.f_bsize;
-            if ((ram_size + 8192 * 1024) >= free_space) {
-                ram_mb = (ram_size / (1024 * 1024));
-                fprintf(stderr,
-                        "You do not have enough space in '%s' for the %d MB of QEMU virtual RAM.\n",
-                        tmpdir, ram_mb);
-                if (strcmp(tmpdir, "/dev/shm") == 0) {
-                    fprintf(stderr, "To have more space available provided you have enough RAM and swap, do as root:\n"
-                            "mount -o remount,size=%dm /dev/shm\n",
-                            ram_mb + 16);
-                } else {
-                    fprintf(stderr,
-                            "Use the '-m' option of QEMU to diminish the amount of virtual RAM or use the\n"
-                            "QEMU_TMPDIR environment variable to set another directory where the QEMU\n"
-                            "temporary RAM file will be opened.\n");
-                }
-                fprintf(stderr, "Or disable the accelerator module with -no-kqemu\n");
-                exit(1);
-            }
-        }
-        snprintf(phys_ram_file, sizeof(phys_ram_file), "%s/qemuXXXXXX",
-                 tmpdir);
-        phys_ram_fd = mkstemp(phys_ram_file);
-        if (phys_ram_fd < 0) {
-            fprintf(stderr,
-                    "warning: could not create temporary file in '%s'.\n"
-                    "Use QEMU_TMPDIR to select a directory in a tmpfs filesystem.\n"
-                    "Using '/tmp' as fallback.\n",
-                    tmpdir);
-            snprintf(phys_ram_file, sizeof(phys_ram_file), "%s/qemuXXXXXX",
-                     "/tmp");
-            phys_ram_fd = mkstemp(phys_ram_file);
-            if (phys_ram_fd < 0) {
-                fprintf(stderr, "Could not create temporary memory file '%s'\n",
-                        phys_ram_file);
-                exit(1);
-            }
-        }
-        unlink(phys_ram_file);
-    }
-    size = (size + 4095) & ~4095;
-    ftruncate(phys_ram_fd, phys_ram_size + size);
-#endif /* !(__OpenBSD__ || __FreeBSD__ || __DragonFly__) */
-    ptr = mmap(NULL,
-               size,
-               PROT_WRITE | PROT_READ, map_anon | MAP_SHARED,
-               phys_ram_fd, phys_ram_size);
-    if (ptr == MAP_FAILED) {
-        fprintf(stderr, "Could not map physical memory\n");
-        exit(1);
-    }
-    phys_ram_size += size;
-    return ptr;
-}
-
-static void kqemu_vfree(void *ptr)
-{
-    /* may be useful some day, but currently we do not need to free */
-}
-
-#endif
-
 void *qemu_memalign(size_t alignment, size_t size)
 {
 #if defined(_POSIX_C_SOURCE)
@@ -200,19 +91,11 @@ void *qemu_memalign(size_t alignment, size_t size)
 /* alloc shared memory pages */
 void *qemu_vmalloc(size_t size)
 {
-#if defined(CONFIG_KQEMU)
-    if (kqemu_allowed)
-        return kqemu_vmalloc(size);
-#endif
     return qemu_memalign(getpagesize(), size);
 }
 
 void qemu_vfree(void *ptr)
 {
-#if defined(CONFIG_KQEMU)
-    if (kqemu_allowed)
-        kqemu_vfree(ptr);
-#endif
     free(ptr);
 }
 
diff --git a/qemu-doc.texi b/qemu-doc.texi
index 837c2a4..78810ae 100644
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
@@ -358,8 +358,6 @@ show virtual to physical memory mappings (i386 only)
 show the active virtual memory mappings (i386 only)
 @item info hpet
 show state of HPET (i386 only)
-@item info kqemu
-show KQEMU information
 @item info kvm
 show KVM information
 @item info usb
diff --git a/qemu-options.hx b/qemu-options.hx
index 87af798..3e1b209 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1319,25 +1319,6 @@ STEXI
 Set the filename for the BIOS.
 ETEXI
 
-#ifdef CONFIG_KQEMU
-DEF("kernel-kqemu", 0, QEMU_OPTION_kernel_kqemu, \
-    "-kernel-kqemu   enable KQEMU full virtualization (default is user mode only)\n")
-#endif
-STEXI
-@item -kernel-kqemu
-Enable KQEMU full virtualization (default is user mode only).
-ETEXI
-
-#ifdef CONFIG_KQEMU
-DEF("no-kqemu", 0, QEMU_OPTION_no_kqemu, \
-    "-no-kqemu       disable KQEMU kernel module usage\n")
-#endif
-STEXI
-@item -no-kqemu
-Disable KQEMU kernel module usage. KQEMU options are only available if
-KQEMU support is enabled when compiling.
-ETEXI
-
 #ifdef CONFIG_KVM
 DEF("enable-kvm", 0, QEMU_OPTION_enable_kvm, \
     "-enable-kvm     enable KVM full virtualization support\n")
diff --git a/qemu-tech.texi b/qemu-tech.texi
index ed2d35b..3e62f40 100644
--- a/qemu-tech.texi
+++ b/qemu-tech.texi
@@ -116,8 +116,8 @@ QEMU full system emulation features:
 QEMU uses a full software MMU for maximum portability.
 
 @item
-QEMU can optionally use an in-kernel accelerator, like kqemu and
-kvm. The accelerators execute some of the guest code natively, while
+QEMU can optionally use an in-kernel accelerator, like kvm. 
+The accelerators execute some of the guest code natively, while
 continuing to emulate the rest of the machine.
 
 @item
diff --git a/softmmu_template.h b/softmmu_template.h
index 4b33aef..e519c51 100644
--- a/softmmu_template.h
+++ b/softmmu_template.h
@@ -76,9 +76,6 @@ static inline DATA_TYPE glue(io_read, SUFFIX)(target_phys_addr_t physaddr,
     res |= (uint64_t)io_mem_read[index][2](io_mem_opaque[index], physaddr + 4) << 32;
 #endif
 #endif /* SHIFT > 2 */
-#ifdef CONFIG_KQEMU
-    env->last_io_time = cpu_get_time_fast();
-#endif
     return res;
 }
 
@@ -221,9 +218,6 @@ static inline void glue(io_write, SUFFIX)(target_phys_addr_t physaddr,
     io_mem_write[index][2](io_mem_opaque[index], physaddr + 4, val >> 32);
 #endif
 #endif /* SHIFT > 2 */
-#ifdef CONFIG_KQEMU
-    env->last_io_time = cpu_get_time_fast();
-#endif
 }
 
 void REGPARM glue(glue(__st, SUFFIX), MMUSUFFIX)(target_ulong addr,
diff --git a/sysemu.h b/sysemu.h
index 92501ed..b9e2e8c 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -120,10 +120,6 @@ extern int no_quit;
 extern int semihosting_enabled;
 extern int old_param;
 
-#ifdef CONFIG_KQEMU
-extern int kqemu_allowed;
-#endif
-
 #define MAX_NODES 64
 extern int nb_numa_nodes;
 extern uint64_t node_mem[MAX_NODES];
diff --git a/target-i386/TODO b/target-i386/TODO
index b671e24..c8ada07 100644
--- a/target-i386/TODO
+++ b/target-i386/TODO
@@ -30,4 +30,3 @@ Optimizations/Features:
 - evaluate x87 stack pointer statically
 - find a way to avoid translating several time the same TB if CR0.TS
   is set or not.
-- move kqemu support outside target-i386.
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index d7b32d4..b61e073 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -664,11 +664,6 @@ typedef struct CPUX86State {
         uint64_t mask;
     } mtrr_var[8];
 
-#ifdef CONFIG_KQEMU
-    int kqemu_enabled;
-    int last_io_time;
-#endif
-
     /* For KVM */
     uint64_t interrupt_bitmap[256 / 64];
     uint32_t mp_state;
@@ -823,15 +818,6 @@ uint64_t cpu_get_tsc(CPUX86State *env);
 #define X86_DUMP_FPU  0x0001 /* dump FPU state too */
 #define X86_DUMP_CCOP 0x0002 /* dump qemu flag cache */
 
-#ifdef CONFIG_KQEMU
-static inline int cpu_get_time_fast(void)
-{
-    int low, high;
-    asm volatile("rdtsc" : "=a" (low), "=d" (high));
-    return low;
-}
-#endif
-
 #define TARGET_PAGE_BITS 12
 
 #define cpu_init cpu_x86_init
diff --git a/target-i386/helper.c b/target-i386/helper.c
index 7fc5366..4339b01 100644
--- a/target-i386/helper.c
+++ b/target-i386/helper.c
@@ -947,14 +947,10 @@ target_phys_addr_t cpu_get_phys_page_debug(CPUState *env, target_ulong addr)
 
 /* XXX: This value should match the one returned by CPUID
  * and in exec.c */
-#if defined(CONFIG_KQEMU)
-#define PHYS_ADDR_MASK 0xfffff000LL
+#if defined(TARGET_X86_64)
+#define PHYS_ADDR_MASK 0xfffffff000LL
 #else
-# if defined(TARGET_X86_64)
-# define PHYS_ADDR_MASK 0xfffffff000LL
-# else
-# define PHYS_ADDR_MASK 0xffffff000LL
-# endif
+#define PHYS_ADDR_MASK 0xffffff000LL
 #endif
 
 /* return value:
@@ -1647,21 +1643,13 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
 /* XXX: This value must match the one used in the MMU code. */ 
         if (env->cpuid_ext2_features & CPUID_EXT2_LM) {
             /* 64 bit processor */
-#if defined(CONFIG_KQEMU)
-            *eax = 0x00003020;	/* 48 bits virtual, 32 bits physical */
-#else
 /* XXX: The physical address space is limited to 42 bits in exec.c. */
             *eax = 0x00003028;	/* 48 bits virtual, 40 bits physical */
-#endif
         } else {
-#if defined(CONFIG_KQEMU)
-            *eax = 0x00000020;	/* 32 bits physical */
-#else
             if (env->cpuid_features & CPUID_PSE36)
                 *eax = 0x00000024; /* 36 bits physical */
             else
                 *eax = 0x00000020; /* 32 bits physical */
-#endif
         }
         *ebx = 0;
         *ecx = 0;
@@ -1706,9 +1694,6 @@ CPUX86State *cpu_x86_init(const char *cpu_model)
         return NULL;
     }
     cpu_reset(env);
-#ifdef CONFIG_KQEMU
-    kqemu_init(env);
-#endif
 
     qemu_init_vcpu(env);
 
diff --git a/target-i386/op_helper.c b/target-i386/op_helper.c
index bd1769c..6474578 100644
--- a/target-i386/op_helper.c
+++ b/target-i386/op_helper.c
@@ -1112,14 +1112,6 @@ void helper_sysret(int dflag)
         env->eflags |= IF_MASK;
         cpu_x86_set_cpl(env, 3);
     }
-#ifdef CONFIG_KQEMU
-    if (kqemu_is_ok(env)) {
-        if (env->hflags & HF_LMA_MASK)
-            CC_OP = CC_OP_EFLAGS;
-        env->exception_index = -1;
-        cpu_loop_exit();
-    }
-#endif
 }
 #endif
 
@@ -2507,12 +2499,6 @@ void helper_lcall_protected(int new_cs, target_ulong new_eip,
         SET_ESP(sp, sp_mask);
         EIP = offset;
     }
-#ifdef CONFIG_KQEMU
-    if (kqemu_is_ok(env)) {
-        env->exception_index = -1;
-        cpu_loop_exit();
-    }
-#endif
 }
 
 /* real and vm86 mode iret */
@@ -2793,24 +2779,11 @@ void helper_iret_protected(int shift, int next_eip)
         helper_ret_protected(shift, 1, 0);
     }
     env->hflags2 &= ~HF2_NMI_MASK;
-#ifdef CONFIG_KQEMU
-    if (kqemu_is_ok(env)) {
-        CC_OP = CC_OP_EFLAGS;
-        env->exception_index = -1;
-        cpu_loop_exit();
-    }
-#endif
 }
 
 void helper_lret_protected(int shift, int addend)
 {
     helper_ret_protected(shift, 0, addend);
-#ifdef CONFIG_KQEMU
-    if (kqemu_is_ok(env)) {
-        env->exception_index = -1;
-        cpu_loop_exit();
-    }
-#endif
 }
 
 void helper_sysenter(void)
@@ -2883,12 +2856,6 @@ void helper_sysexit(int dflag)
     }
     ESP = ECX;
     EIP = EDX;
-#ifdef CONFIG_KQEMU
-    if (kqemu_is_ok(env)) {
-        env->exception_index = -1;
-        cpu_loop_exit();
-    }
-#endif
 }
 
 #if defined(CONFIG_USER_ONLY)
@@ -3196,15 +3163,6 @@ void helper_rdmsr(void)
         val = env->kernelgsbase;
         break;
 #endif
-#ifdef CONFIG_KQEMU
-    case MSR_QPI_COMMBASE:
-        if (env->kqemu_enabled) {
-            val = kqemu_comm_base;
-        } else {
-            val = 0;
-        }
-        break;
-#endif
     case MSR_MTRRphysBase(0):
     case MSR_MTRRphysBase(1):
     case MSR_MTRRphysBase(2):
diff --git a/vl.c b/vl.c
index 1a227bb..d9a7279 100644
--- a/vl.c
+++ b/vl.c
@@ -442,30 +442,18 @@ void cpu_outb(CPUState *env, int addr, int val)
 {
     LOG_IOPORT("outb: %04x %02x\n", addr, val);
     ioport_write(0, addr, val);
-#ifdef CONFIG_KQEMU
-    if (env)
-        env->last_io_time = cpu_get_time_fast();
-#endif
 }
 
 void cpu_outw(CPUState *env, int addr, int val)
 {
     LOG_IOPORT("outw: %04x %04x\n", addr, val);
     ioport_write(1, addr, val);
-#ifdef CONFIG_KQEMU
-    if (env)
-        env->last_io_time = cpu_get_time_fast();
-#endif
 }
 
 void cpu_outl(CPUState *env, int addr, int val)
 {
     LOG_IOPORT("outl: %04x %08x\n", addr, val);
     ioport_write(2, addr, val);
-#ifdef CONFIG_KQEMU
-    if (env)
-        env->last_io_time = cpu_get_time_fast();
-#endif
 }
 
 int cpu_inb(CPUState *env, int addr)
@@ -473,10 +461,6 @@ int cpu_inb(CPUState *env, int addr)
     int val;
     val = ioport_read(0, addr);
     LOG_IOPORT("inb : %04x %02x\n", addr, val);
-#ifdef CONFIG_KQEMU
-    if (env)
-        env->last_io_time = cpu_get_time_fast();
-#endif
     return val;
 }
 
@@ -485,10 +469,6 @@ int cpu_inw(CPUState *env, int addr)
     int val;
     val = ioport_read(1, addr);
     LOG_IOPORT("inw : %04x %04x\n", addr, val);
-#ifdef CONFIG_KQEMU
-    if (env)
-        env->last_io_time = cpu_get_time_fast();
-#endif
     return val;
 }
 
@@ -497,10 +477,6 @@ int cpu_inl(CPUState *env, int addr)
     int val;
     val = ioport_read(2, addr);
     LOG_IOPORT("inl : %04x %08x\n", addr, val);
-#ifdef CONFIG_KQEMU
-    if (env)
-        env->last_io_time = cpu_get_time_fast();
-#endif
     return val;
 }
 
@@ -1354,11 +1330,6 @@ static void host_alarm_handler(int host_signum)
         if (next_cpu) {
             /* stop the currently executing cpu because a timer occured */
             cpu_exit(next_cpu);
-#ifdef CONFIG_KQEMU
-            if (next_cpu->kqemu_enabled) {
-                kqemu_cpu_interrupt(next_cpu);
-            }
-#endif
         }
 #endif
         timer_alarm_pending = 1;
@@ -3831,10 +3802,6 @@ void qemu_notify_event(void)
 
     if (env) {
         cpu_exit(env);
-#ifdef USE_KQEMU
-        if (env->kqemu_enabled)
-            kqemu_cpu_interrupt(env);
-#endif
      }
 }
 
@@ -5212,11 +5179,7 @@ int main(int argc, char **argv, char **envp)
                 }
 
                 /* On 32-bit hosts, QEMU is limited by virtual address space */
-                if (value > (2047 << 20)
-#ifndef CONFIG_KQEMU
-                    && HOST_LONG_BITS == 32
-#endif
-                    ) {
+                if (value > (2047 << 20) && HOST_LONG_BITS == 32) {
                     fprintf(stderr, "qemu: at most 2047 MB RAM can be simulated\n");
                     exit(1);
                 }
@@ -5397,20 +5360,9 @@ int main(int argc, char **argv, char **envp)
                 }
                 break;
 #endif
-#ifdef CONFIG_KQEMU
-            case QEMU_OPTION_no_kqemu:
-                kqemu_allowed = 0;
-                break;
-            case QEMU_OPTION_kernel_kqemu:
-                kqemu_allowed = 2;
-                break;
-#endif
 #ifdef CONFIG_KVM
             case QEMU_OPTION_enable_kvm:
                 kvm_allowed = 1;
-#ifdef CONFIG_KQEMU
-                kqemu_allowed = 0;
-#endif
                 break;
 #endif
             case QEMU_OPTION_usb:
@@ -5576,14 +5528,6 @@ int main(int argc, char **argv, char **envp)
         }
     }
 
-#if defined(CONFIG_KVM) && defined(CONFIG_KQEMU)
-    if (kvm_allowed && kqemu_allowed) {
-        fprintf(stderr,
-                "You can not enable both KVM and kqemu at the same time\n");
-        exit(1);
-    }
-#endif
-
     machine->max_cpus = machine->max_cpus ?: 1; /* Default to UP */
     if (smp_cpus > machine->max_cpus) {
         fprintf(stderr, "Number of SMP cpus requested (%d), exceeds max cpus "
@@ -5655,10 +5599,6 @@ int main(int argc, char **argv, char **envp)
     }
 #endif
 
-#ifdef CONFIG_KQEMU
-    if (smp_cpus > 1)
-        kqemu_allowed = 0;
-#endif
     if (qemu_init_main_loop()) {
         fprintf(stderr, "qemu_init_main_loop failed\n");
         exit(1);
@@ -5752,19 +5692,6 @@ int main(int argc, char **argv, char **envp)
     if (ram_size == 0)
         ram_size = DEFAULT_RAM_SIZE * 1024 * 1024;
 
-#ifdef CONFIG_KQEMU
-    /* FIXME: This is a nasty hack because kqemu can't cope with dynamic
-       guest ram allocation.  It needs to go away.  */
-    if (kqemu_allowed) {
-        kqemu_phys_ram_size = ram_size + 8 * 1024 * 1024 + 4 * 1024 * 1024;
-        kqemu_phys_ram_base = qemu_vmalloc(kqemu_phys_ram_size);
-        if (!kqemu_phys_ram_base) {
-            fprintf(stderr, "Could not allocate physical memory\n");
-            exit(1);
-        }
-    }
-#endif
-
     /* init the dynamic translator */
     cpu_exec_init_all(tb_size * 1024 * 1024);
 
-- 
1.5.6.6

^ permalink raw reply related	[flat|nested] 25+ messages in thread

* Re: [Qemu-devel] [PATCH] remove pieces of source code
  2009-05-28 23:03 [Qemu-devel] [PATCH] remove pieces of source code Glauber Costa
@ 2009-05-29  5:50 ` Anthony Liguori
  2009-05-29  9:08   ` [Qemu-devel] " Jan Kiszka
  2009-05-29 11:32   ` [Qemu-devel] " Glauber Costa
  0 siblings, 2 replies; 25+ messages in thread
From: Anthony Liguori @ 2009-05-29  5:50 UTC (permalink / raw)
  To: Glauber Costa; +Cc: aliguori, qemu-devel

Glauber Costa wrote:
> Have you ever seen a girl so beautiful that you, geeky,
> think: "I'll never stand a chance"?
>
> But sometimes, you decide to make your move anyway. There's
> always the chance that in that very day she'll be specially
> in good mood, and you'll get what you want.
>
> With the exception of the fact that qemu is not a girl,
> that's more or less what I'm trying to do here: Hopefully,
> nobody will notice what I'm trying to do, and will commmit it.
> Later, when realizing, it will be too late. Victory will be mine.
>
> Or maybe people will even agree. For that, I'll try briefly
> to arguee my point, without disclosing to much, avoiding
> jeopardizing the strategy I explained above:
>
>   This patch removes a piece of code that is unmaintaned,
>   that does not receive an update for years,
>   that get bug reports on the list that nobody fixes, because
>   nobody really understands,
>   that places some artificial constraints on other subsystems
>
> Signed-off-by: Glauber Costa <glommer@redhat.com

Let's actually build a proper case instead of closing our eyes and
hitting enter.  Here are the downsides of kqemu I know of:

 o Since it's enabled by default, it forces the default build to support
< 4GB of guest memory
 o It attempts to use /dev/shm for guest memory which means a special
option is needed in the default build to use more than 1/2 of host ram size
 o It touches an awful lot of places in QEMU
 o Some of the BIOS changes are particularly nasty and will prevent
having a unified BIOS between QEMU and Bochs
 o The kernel bits will never go upstream for Linux
 o No one actively supports kqemu in upstream QEMU

That said, here are the arguments for keeping kqemu

 o Even though it's unmaintained, it seems to work for people
 o There is no alternative for non-Linux users and folks with non-VT/SVM
hardware

Regards,

Anthony Liguori

^ permalink raw reply	[flat|nested] 25+ messages in thread

* [Qemu-devel] Re: [PATCH] remove pieces of source code
  2009-05-29  5:50 ` Anthony Liguori
@ 2009-05-29  9:08   ` Jan Kiszka
  2009-05-29  9:12     ` Anthony Liguori
                       ` (4 more replies)
  2009-05-29 11:32   ` [Qemu-devel] " Glauber Costa
  1 sibling, 5 replies; 25+ messages in thread
From: Jan Kiszka @ 2009-05-29  9:08 UTC (permalink / raw)
  To: Anthony Liguori; +Cc: Glauber Costa, aliguori, qemu-devel

Anthony Liguori wrote:
> Glauber Costa wrote:
>> Have you ever seen a girl so beautiful that you, geeky,
>> think: "I'll never stand a chance"?
>>
>> But sometimes, you decide to make your move anyway. There's
>> always the chance that in that very day she'll be specially
>> in good mood, and you'll get what you want.
>>
>> With the exception of the fact that qemu is not a girl,
>> that's more or less what I'm trying to do here: Hopefully,
>> nobody will notice what I'm trying to do, and will commmit it.
>> Later, when realizing, it will be too late. Victory will be mine.
>>
>> Or maybe people will even agree. For that, I'll try briefly
>> to arguee my point, without disclosing to much, avoiding
>> jeopardizing the strategy I explained above:
>>
>>   This patch removes a piece of code that is unmaintaned,
>>   that does not receive an update for years,
>>   that get bug reports on the list that nobody fixes, because
>>   nobody really understands,
>>   that places some artificial constraints on other subsystems
>>
>> Signed-off-by: Glauber Costa <glommer@redhat.com
> 
> Let's actually build a proper case instead of closing our eyes and
> hitting enter.  Here are the downsides of kqemu I know of:
> 
>  o Since it's enabled by default, it forces the default build to support
> < 4GB of guest memory

Making -no-kqemu the default appears as a reasonable first step then -
to kill those silly "Could not open '/dev/kqemu'" warnings) and also to
collect complains like: "What the heck happened to kqemu?"

>  o It attempts to use /dev/shm for guest memory which means a special
> option is needed in the default build to use more than 1/2 of host ram size
>  o It touches an awful lot of places in QEMU
>  o Some of the BIOS changes are particularly nasty and will prevent
> having a unified BIOS between QEMU and Bochs
>  o The kernel bits will never go upstream for Linux
>  o No one actively supports kqemu in upstream QEMU

We did some work on it a few months ago, trying to enhance its support
for segmented guests. It turned out to require unreasonable effort and
would still perform not significantly better than plain qemu in this
context (and our customer dropped the idea to support legacy systems
anyway). The results are a few low-level fixes and enhancements (that I
still want to post once cleaned up) and the confirmation of what is
likely already clear to people who had a look at the kernel bits: They
are almost unmaintainable and can cause severe headache when trying to
understand them.

> 
> That said, here are the arguments for keeping kqemu
> 
>  o Even though it's unmaintained, it seems to work for people

At some point, I bet, at least the Linux bindings will break, and no one
will be interested or able to fix that anymore. Same may happen to other
platforms (doesn't Windows 7 come with a new driver model?).

>  o There is no alternative for non-Linux users and folks with non-VT/SVM
> hardware

The non-HVM argument will become widely irrelevant (for desktops) very
soon. The non-Linux issue will likely persist - unless someone feels so
much pain to write some KVM for those platforms. But as long as there is
a kqemu version that builds and works for them, I think we should keep
QEMU's support. But it should no longer be a first-class citizen: off by
default, factored out into more hooks, maybe even de-optimized where it
blocks development or increases the maintenance effort of QEMU.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

^ permalink raw reply	[flat|nested] 25+ messages in thread

* [Qemu-devel] Re: [PATCH] remove pieces of source code
  2009-05-29  9:08   ` [Qemu-devel] " Jan Kiszka
@ 2009-05-29  9:12     ` Anthony Liguori
  2009-05-29  9:35       ` Stefan Weil
  2009-06-02 20:09       ` Stuart Brady
  2009-05-29 10:00     ` Daniel P. Berrange
                       ` (3 subsequent siblings)
  4 siblings, 2 replies; 25+ messages in thread
From: Anthony Liguori @ 2009-05-29  9:12 UTC (permalink / raw)
  To: Jan Kiszka; +Cc: Glauber Costa, qemu-devel

Jan Kiszka wrote:
> Anthony Liguori wrote:
>   
>> Glauber Costa wrote:
>>     
>>> Have you ever seen a girl so beautiful that you, geeky,
>>> think: "I'll never stand a chance"?
>>>
>>> But sometimes, you decide to make your move anyway. There's
>>> always the chance that in that very day she'll be specially
>>> in good mood, and you'll get what you want.
>>>
>>> With the exception of the fact that qemu is not a girl,
>>> that's more or less what I'm trying to do here: Hopefully,
>>> nobody will notice what I'm trying to do, and will commmit it.
>>> Later, when realizing, it will be too late. Victory will be mine.
>>>
>>> Or maybe people will even agree. For that, I'll try briefly
>>> to arguee my point, without disclosing to much, avoiding
>>> jeopardizing the strategy I explained above:
>>>
>>>   This patch removes a piece of code that is unmaintaned,
>>>   that does not receive an update for years,
>>>   that get bug reports on the list that nobody fixes, because
>>>   nobody really understands,
>>>   that places some artificial constraints on other subsystems
>>>
>>> Signed-off-by: Glauber Costa <glommer@redhat.com
>>>       
>> Let's actually build a proper case instead of closing our eyes and
>> hitting enter.  Here are the downsides of kqemu I know of:
>>
>>  o Since it's enabled by default, it forces the default build to support
>> < 4GB of guest memory
>>     
>
> Making -no-kqemu the default appears as a reasonable first step then -
> to kill those silly "Could not open '/dev/kqemu'" warnings) and also to
> collect complains like: "What the heck happened to kqemu?"
>   

Yes.  Note that -no-kqemu doesn't fix the above complaint but it fixes
the following one.  So unless there are major objections, I'd like to
make -no-kqemu the default for 0.11.  We can then discuss whether to
make kqemu deprecated and scheduled for removal in 0.12.

>>  o It attempts to use /dev/shm for guest memory which means a special
>> option is needed in the default build to use more than 1/2 of host ram size
>>  o It touches an awful lot of places in QEMU
>>  o Some of the BIOS changes are particularly nasty and will prevent
>> having a unified BIOS between QEMU and Bochs
>>  o The kernel bits will never go upstream for Linux
>>  o No one actively supports kqemu in upstream QEMU
>>     
>
> We did some work on it a few months ago, trying to enhance its support
> for segmented guests. It turned out to require unreasonable effort and
> would still perform not significantly better than plain qemu in this
> context (and our customer dropped the idea to support legacy systems
> anyway). The results are a few low-level fixes and enhancements (that I
> still want to post once cleaned up) and the confirmation of what is
> likely already clear to people who had a look at the kernel bits: They
> are almost unmaintainable and can cause severe headache when trying to
> understand them.
>
>   
>> That said, here are the arguments for keeping kqemu
>>
>>  o Even though it's unmaintained, it seems to work for people
>>     
>
> At some point, I bet, at least the Linux bindings will break, and no one
> will be interested or able to fix that anymore. Same may happen to other
> platforms (doesn't Windows 7 come with a new driver model?).
>
>   
>>  o There is no alternative for non-Linux users and folks with non-VT/SVM
>> hardware
>>     
>
> The non-HVM argument will become widely irrelevant (for desktops) very
> soon. The non-Linux issue will likely persist - unless someone feels so
> much pain to write some KVM for those platforms. But as long as there is
> a kqemu version that builds and works for them, I think we should keep
> QEMU's support. But it should no longer be a first-class citizen: off by
> default, factored out into more hooks, maybe even de-optimized where it
> blocks development or increases the maintenance effort of QEMU.
>   

If we disable in configure, then we should remove it from the tree.  The
feeling is that code that's disabled by default is too likely to bitrot.

I think you've made a reasonable suggestion though.  So unless there are
strong feelings otherwise, I think we should do -no-kqemu by default for
0.11, see what the reaction is, then figure out whether we want to
deprecate/remove.

Regards,

Anthony Liguori

> Jan
>
>   

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Qemu-devel] Re: [PATCH] remove pieces of source code
  2009-05-29  9:12     ` Anthony Liguori
@ 2009-05-29  9:35       ` Stefan Weil
  2009-06-02 20:09       ` Stuart Brady
  1 sibling, 0 replies; 25+ messages in thread
From: Stefan Weil @ 2009-05-29  9:35 UTC (permalink / raw)
  To: Anthony Liguori; +Cc: QEMU Developers

Anthony Liguori schrieb:
> Jan Kiszka wrote:
>   
>> Anthony Liguori wrote:
>>   
>>     
>>> Glauber Costa wrote:
>>>     
>>>       
>>>> Have you ever seen a girl so beautiful that you, geeky,
>>>> think: "I'll never stand a chance"?
>>>>
>>>> But sometimes, you decide to make your move anyway. There's
>>>> always the chance that in that very day she'll be specially
>>>> in good mood, and you'll get what you want.
>>>>
>>>> With the exception of the fact that qemu is not a girl,
>>>> that's more or less what I'm trying to do here: Hopefully,
>>>> nobody will notice what I'm trying to do, and will commmit it.
>>>> Later, when realizing, it will be too late. Victory will be mine.
>>>>
>>>> Or maybe people will even agree. For that, I'll try briefly
>>>> to arguee my point, without disclosing to much, avoiding
>>>> jeopardizing the strategy I explained above:
>>>>
>>>>   This patch removes a piece of code that is unmaintaned,
>>>>   that does not receive an update for years,
>>>>   that get bug reports on the list that nobody fixes, because
>>>>   nobody really understands,
>>>>   that places some artificial constraints on other subsystems
>>>>
>>>> Signed-off-by: Glauber Costa <glommer@redhat.com
>>>>       
>>>>         
>>> Let's actually build a proper case instead of closing our eyes and
>>> hitting enter.  Here are the downsides of kqemu I know of:
>>>
>>>  o Since it's enabled by default, it forces the default build to support
>>> < 4GB of guest memory
>>>     
>>>       
>> Making -no-kqemu the default appears as a reasonable first step then -
>> to kill those silly "Could not open '/dev/kqemu'" warnings) and also to
>> collect complains like: "What the heck happened to kqemu?"
>>   
>>     
>
> Yes.  Note that -no-kqemu doesn't fix the above complaint but it fixes
> the following one.  So unless there are major objections, I'd like to
> make -no-kqemu the default for 0.11.  We can then discuss whether to
> make kqemu deprecated and scheduled for removal in 0.12.
>
>   
>>>  o It attempts to use /dev/shm for guest memory which means a special
>>> option is needed in the default build to use more than 1/2 of host ram size
>>>  o It touches an awful lot of places in QEMU
>>>  o Some of the BIOS changes are particularly nasty and will prevent
>>> having a unified BIOS between QEMU and Bochs
>>>  o The kernel bits will never go upstream for Linux
>>>  o No one actively supports kqemu in upstream QEMU
>>>     
>>>       
>> We did some work on it a few months ago, trying to enhance its support
>> for segmented guests. It turned out to require unreasonable effort and
>> would still perform not significantly better than plain qemu in this
>> context (and our customer dropped the idea to support legacy systems
>> anyway). The results are a few low-level fixes and enhancements (that I
>> still want to post once cleaned up) and the confirmation of what is
>> likely already clear to people who had a look at the kernel bits: They
>> are almost unmaintainable and can cause severe headache when trying to
>> understand them.
>>
>>   
>>     
>>> That said, here are the arguments for keeping kqemu
>>>
>>>  o Even though it's unmaintained, it seems to work for people
>>>     
>>>       
>> At some point, I bet, at least the Linux bindings will break, and no one
>> will be interested or able to fix that anymore. Same may happen to other
>> platforms (doesn't Windows 7 come with a new driver model?).
>>
>>   
>>     
>>>  o There is no alternative for non-Linux users and folks with non-VT/SVM
>>> hardware
>>>     
>>>       
>> The non-HVM argument will become widely irrelevant (for desktops) very
>> soon. The non-Linux issue will likely persist - unless someone feels so
>> much pain to write some KVM for those platforms. But as long as there is
>> a kqemu version that builds and works for them, I think we should keep
>> QEMU's support. But it should no longer be a first-class citizen: off by
>> default, factored out into more hooks, maybe even de-optimized where it
>> blocks development or increases the maintenance effort of QEMU.
>>   
>>     
>
> If we disable in configure, then we should remove it from the tree.  The
> feeling is that code that's disabled by default is too likely to bitrot.
>
> I think you've made a reasonable suggestion though.  So unless there are
> strong feelings otherwise, I think we should do -no-kqemu by default for
> 0.11, see what the reaction is, then figure out whether we want to
> deprecate/remove.
>
> Regards,
>
> Anthony Liguori
>
>   
>> Jan
>>
>>   
>>     

Default setting -no-kqemu is ok for all platforms without
kqemu support or with working kvm support.

For Win32, I prefer to have kqemu support enabled by default.

Regards,

Stefan Weil

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Qemu-devel] Re: [PATCH] remove pieces of source code
  2009-05-29  9:08   ` [Qemu-devel] " Jan Kiszka
  2009-05-29  9:12     ` Anthony Liguori
@ 2009-05-29 10:00     ` Daniel P. Berrange
  2009-05-29 10:20       ` Jan Kiszka
  2009-05-29 11:35     ` Glauber Costa
                       ` (2 subsequent siblings)
  4 siblings, 1 reply; 25+ messages in thread
From: Daniel P. Berrange @ 2009-05-29 10:00 UTC (permalink / raw)
  To: Jan Kiszka; +Cc: Glauber Costa, aliguori, qemu-devel

On Fri, May 29, 2009 at 11:08:38AM +0200, Jan Kiszka wrote:
> Anthony Liguori wrote:
> 
> >  o There is no alternative for non-Linux users and folks with non-VT/SVM
> > hardware
> 
> The non-HVM argument will become widely irrelevant (for desktops) very
> soon. The non-Linux issue will likely persist - unless someone feels so
> much pain to write some KVM for those platforms. But as long as there is
> a kqemu version that builds and works for them, I think we should keep
> QEMU's support. But it should no longer be a first-class citizen: off by
> default, factored out into more hooks, maybe even de-optimized where it
> blocks development or increases the maintenance effort of QEMU.

The non-HVM argument will always exist, and could actually get worse
if lots of vendors start shipping with embedded hypervisors, such that
your 'real' OS is already virtualized behind your back. That said I do 
agree with you - we're still better off killing/deprecating kqemu and 
using any spare effort to improve nested-SVM/VT support which is a more 
useful long term feature.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Qemu-devel] Re: [PATCH] remove pieces of source code
  2009-05-29 10:00     ` Daniel P. Berrange
@ 2009-05-29 10:20       ` Jan Kiszka
  0 siblings, 0 replies; 25+ messages in thread
From: Jan Kiszka @ 2009-05-29 10:20 UTC (permalink / raw)
  To: Daniel P. Berrange; +Cc: Glauber Costa, aliguori, qemu-devel

Daniel P. Berrange wrote:
> On Fri, May 29, 2009 at 11:08:38AM +0200, Jan Kiszka wrote:
>> Anthony Liguori wrote:
>>
>>>  o There is no alternative for non-Linux users and folks with non-VT/SVM
>>> hardware
>> The non-HVM argument will become widely irrelevant (for desktops) very
>> soon. The non-Linux issue will likely persist - unless someone feels so
>> much pain to write some KVM for those platforms. But as long as there is
>> a kqemu version that builds and works for them, I think we should keep
>> QEMU's support. But it should no longer be a first-class citizen: off by
>> default, factored out into more hooks, maybe even de-optimized where it
>> blocks development or increases the maintenance effort of QEMU.
> 
> The non-HVM argument will always exist, and could actually get worse
> if lots of vendors start shipping with embedded hypervisors, such that
> your 'real' OS is already virtualized behind your back. That said I do 

Nested virtualization like this would have been one nice-to-have via
kqemu. And in fact, most of our development took place inside kvm. But
the performance was worse than qemu inside kvm, at least for our use cases.

That said, there might be scenarios where kqemu inside whatever
hypervisor provides better performance than emulation, but I can only
recommend to evaluate this carefully. The overhead of virtualizing
kqemu's monitor activities can be enormous.

> agree with you - we're still better off killing/deprecating kqemu and 
> using any spare effort to improve nested-SVM/VT support which is a more 
> useful long term feature.
> 

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Qemu-devel] [PATCH] remove pieces of source code
  2009-05-29  5:50 ` Anthony Liguori
  2009-05-29  9:08   ` [Qemu-devel] " Jan Kiszka
@ 2009-05-29 11:32   ` Glauber Costa
  2009-05-29 11:42     ` Gerd Hoffmann
  2009-05-29 15:43     ` [Qemu-devel] " Consul
  1 sibling, 2 replies; 25+ messages in thread
From: Glauber Costa @ 2009-05-29 11:32 UTC (permalink / raw)
  To: Anthony Liguori; +Cc: aliguori, qemu-devel

On Fri, May 29, 2009 at 12:50:56AM -0500, Anthony Liguori wrote:
> Glauber Costa wrote:
> > Have you ever seen a girl so beautiful that you, geeky,
> > think: "I'll never stand a chance"?
> >
> > But sometimes, you decide to make your move anyway. There's
> > always the chance that in that very day she'll be specially
> > in good mood, and you'll get what you want.
> >
> > With the exception of the fact that qemu is not a girl,
> > that's more or less what I'm trying to do here: Hopefully,
> > nobody will notice what I'm trying to do, and will commmit it.
> > Later, when realizing, it will be too late. Victory will be mine.
> >
> > Or maybe people will even agree. For that, I'll try briefly
> > to arguee my point, without disclosing to much, avoiding
> > jeopardizing the strategy I explained above:
> >
> >   This patch removes a piece of code that is unmaintaned,
> >   that does not receive an update for years,
> >   that get bug reports on the list that nobody fixes, because
> >   nobody really understands,
> >   that places some artificial constraints on other subsystems
> >
> > Signed-off-by: Glauber Costa <glommer@redhat.com
> 
> Let's actually build a proper case instead of closing our eyes and
> hitting enter.  Here are the downsides of kqemu I know of:
Okay... you do realize I was kidding, and I never really expected this to
happen at first, right? ;-)

> 
>  o Since it's enabled by default, it forces the default build to support
> < 4GB of guest memory
>  o It attempts to use /dev/shm for guest memory which means a special
> option is needed in the default build to use more than 1/2 of host ram size
>  o It touches an awful lot of places in QEMU
>  o Some of the BIOS changes are particularly nasty and will prevent
> having a unified BIOS between QEMU and Bochs
>  o The kernel bits will never go upstream for Linux
>  o No one actively supports kqemu in upstream QEMU
> 
> That said, here are the arguments for keeping kqemu
> 
>  o Even though it's unmaintained, it seems to work for people
But traffic in the mailing list indicates that it is less and less the case.
And more importantly: As it bitrots, nobody fixes it. so...

>  o There is no alternative for non-Linux users and folks with non-VT/SVM
> hardware

Sure, but I don't think kqemu is such an alternative. ;-)

^ permalink raw reply	[flat|nested] 25+ messages in thread

* [Qemu-devel] Re: [PATCH] remove pieces of source code
  2009-05-29  9:08   ` [Qemu-devel] " Jan Kiszka
  2009-05-29  9:12     ` Anthony Liguori
  2009-05-29 10:00     ` Daniel P. Berrange
@ 2009-05-29 11:35     ` Glauber Costa
  2009-05-30 18:04     ` François Revol
  2009-05-31 14:53     ` Jamie Lokier
  4 siblings, 0 replies; 25+ messages in thread
From: Glauber Costa @ 2009-05-29 11:35 UTC (permalink / raw)
  To: Jan Kiszka; +Cc: aliguori, qemu-devel

On Fri, May 29, 2009 at 11:08:38AM +0200, Jan Kiszka wrote:
> Anthony Liguori wrote:
> > Glauber Costa wrote:
> >> Have you ever seen a girl so beautiful that you, geeky,
> >> think: "I'll never stand a chance"?
> >>
> >> But sometimes, you decide to make your move anyway. There's
> >> always the chance that in that very day she'll be specially
> >> in good mood, and you'll get what you want.
> >>
> >> With the exception of the fact that qemu is not a girl,
> >> that's more or less what I'm trying to do here: Hopefully,
> >> nobody will notice what I'm trying to do, and will commmit it.
> >> Later, when realizing, it will be too late. Victory will be mine.
> >>
> >> Or maybe people will even agree. For that, I'll try briefly
> >> to arguee my point, without disclosing to much, avoiding
> >> jeopardizing the strategy I explained above:
> >>
> >>   This patch removes a piece of code that is unmaintaned,
> >>   that does not receive an update for years,
> >>   that get bug reports on the list that nobody fixes, because
> >>   nobody really understands,
> >>   that places some artificial constraints on other subsystems
> >>
> >> Signed-off-by: Glauber Costa <glommer@redhat.com
> > 
> > Let's actually build a proper case instead of closing our eyes and
> > hitting enter.  Here are the downsides of kqemu I know of:
> > 
> >  o Since it's enabled by default, it forces the default build to support
> > < 4GB of guest memory
> 
> Making -no-kqemu the default appears as a reasonable first step then -
> to kill those silly "Could not open '/dev/kqemu'" warnings) and also to
> collect complains like: "What the heck happened to kqemu?"
We have at least one _stable_ release at this point that includes kqemu.
So why not just remove it for the next one?

> 
> >  o There is no alternative for non-Linux users and folks with non-VT/SVM
> > hardware
> 
> The non-HVM argument will become widely irrelevant (for desktops) very
> soon. The non-Linux issue will likely persist - unless someone feels so
> much pain to write some KVM for those platforms. But as long as there is
> a kqemu version that builds and works for them, I think we should keep
> QEMU's support. But it should no longer be a first-class citizen: off by
> default, factored out into more hooks, maybe even de-optimized where it
> blocks development or increases the maintenance effort of QEMU.

Any change we make to decrease its citizenship status will likely break it
very fast. Reality is noone here really understands it.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Qemu-devel] [PATCH] remove pieces of source code
  2009-05-29 11:32   ` [Qemu-devel] " Glauber Costa
@ 2009-05-29 11:42     ` Gerd Hoffmann
  2009-05-29 15:43     ` [Qemu-devel] " Consul
  1 sibling, 0 replies; 25+ messages in thread
From: Gerd Hoffmann @ 2009-05-29 11:42 UTC (permalink / raw)
  To: Glauber Costa; +Cc: aliguori, qemu-devel

On 05/29/09 13:32, Glauber Costa wrote:
>>   o Even though it's unmaintained, it seems to work for people
> But traffic in the mailing list indicates that it is less and less the case.
> And more importantly: As it bitrots, nobody fixes it. so...

Data point:  Running 64bit guests doesn't work stable for me.  Guest 
starts booting up, but qemu aborts before it reaches the login prompt. 
32bit guests seem to work ok, but I don't use it that much.

cheers,
   Gerd

^ permalink raw reply	[flat|nested] 25+ messages in thread

* [Qemu-devel] Re: [PATCH] remove pieces of source code
  2009-05-29 11:32   ` [Qemu-devel] " Glauber Costa
  2009-05-29 11:42     ` Gerd Hoffmann
@ 2009-05-29 15:43     ` Consul
  2009-05-29 18:49       ` Glauber Costa
  1 sibling, 1 reply; 25+ messages in thread
From: Consul @ 2009-05-29 15:43 UTC (permalink / raw)
  To: qemu-devel

Glauber Costa wrote:
> But traffic in the mailing list indicates that it is less and less the case.
> And more importantly: As it bitrots, nobody fixes it. so...
> 
>>  o There is no alternative for non-Linux users and folks with non-VT/SVM
>> hardware
> 
> Sure, but I don't think kqemu is such an alternative. ;-)

It is. Without kqemu I'll have no alternative, but switch to VBox or VMWare.
And none of them work with qcow images.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Qemu-devel] Re: [PATCH] remove pieces of source code
  2009-05-29 15:43     ` [Qemu-devel] " Consul
@ 2009-05-29 18:49       ` Glauber Costa
  2009-05-30 10:26         ` Andreas Färber
  0 siblings, 1 reply; 25+ messages in thread
From: Glauber Costa @ 2009-05-29 18:49 UTC (permalink / raw)
  To: Consul; +Cc: qemu-devel

On Fri, May 29, 2009 at 08:43:09AM -0700, Consul wrote:
> Glauber Costa wrote:
>> But traffic in the mailing list indicates that it is less and less the case.
>> And more importantly: As it bitrots, nobody fixes it. so...
>>
>>>  o There is no alternative for non-Linux users and folks with non-VT/SVM
>>> hardware
>>
>> Sure, but I don't think kqemu is such an alternative. ;-)
>
> It is. Without kqemu I'll have no alternative, but switch to VBox or VMWare.
> And none of them work with qcow images.
I'm not saying that because of any kind of functionality. I'm saying it is
not an alternative, because nobody really maintains it. It's bitrotting,
and unless someone wants to step up, soon or later you won't be able to use it
anyway.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Qemu-devel] Re: [PATCH] remove pieces of source code
  2009-05-29 18:49       ` Glauber Costa
@ 2009-05-30 10:26         ` Andreas Färber
  2009-05-31  9:15           ` Jan Kiszka
  0 siblings, 1 reply; 25+ messages in thread
From: Andreas Färber @ 2009-05-30 10:26 UTC (permalink / raw)
  To: Glauber Costa; +Cc: Consul, qemu-devel


Am 29.05.2009 um 20:49 schrieb Glauber Costa:

> On Fri, May 29, 2009 at 08:43:09AM -0700, Consul wrote:
>> Glauber Costa wrote:
>>> But traffic in the mailing list indicates that it is less and less  
>>> the case.
>>> And more importantly: As it bitrots, nobody fixes it. so...
>>>
>>>> o There is no alternative for non-Linux users and folks with non- 
>>>> VT/SVM
>>>> hardware
>>>
>>> Sure, but I don't think kqemu is such an alternative. ;-)
>>
>> It is. Without kqemu I'll have no alternative, but switch to VBox  
>> or VMWare.
>> And none of them work with qcow images.
> I'm not saying that because of any kind of functionality. I'm saying  
> it is
> not an alternative, because nobody really maintains it.

KVM is no alternative either for us because nobody really maintains  
documentation of what interface and functionality we'd have to  
implement on Solaris, Windows, Mac OS X etc. where no KVM is available  
today.

I'd expect some documentation here: http://www.linux-kvm.org/page/Documents 
  -- but no luck. No "Porting KVM For Dummies". ;(

I see no problem dumping kqemu support once KVM is available on the  
kqemu platforms, but now is really a bad point in time.

Andreas

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Qemu-devel] Re: [PATCH] remove pieces of source code
  2009-05-29  9:08   ` [Qemu-devel] " Jan Kiszka
                       ` (2 preceding siblings ...)
  2009-05-29 11:35     ` Glauber Costa
@ 2009-05-30 18:04     ` François Revol
  2009-05-31  9:13       ` Jan Kiszka
  2009-05-31 14:53     ` Jamie Lokier
  4 siblings, 1 reply; 25+ messages in thread
From: François Revol @ 2009-05-30 18:04 UTC (permalink / raw)
  To: Jan Kiszka; +Cc: glommer, aliguori, qemu-devel

> > That said, here are the arguments for keeping kqemu
> >
> >  o Even though it's unmaintained, it seems to work for people
>
> At some point, I bet, at least the Linux bindings will break, and no
> one
> will be interested or able to fix that anymore. Same may happen to
> other
> platforms (doesn't Windows 7 come with a new driver model?).

Yes and MS even made supplications to hw vendors to write drivers for
it, as they got slapped by their own monopoly practices :D
Instead they should just ask them to release specs so everyone can
write drivers for their own OS and restore fair competition...

> >  o There is no alternative for non-Linux users and folks with non-
> > VT/SVM
> > hardware
>
> The non-HVM argument will become widely irrelevant (for desktops)
> very

Hmm not everyone has the money to renew their hw every year or so. I
still have an AthlonXP and a PentiumM based laptop here, which do work
fine.

> soon. The non-Linux issue will likely persist - unless someone feels
> so
> much pain to write some KVM for those platforms. But as long as there
> is

<rant reason="Sorry you just cought me on a bad day">
Well, some FOSS devs have a tendancy those years to act like
proprietary devs, disregarding other OSes as "non existant, not
relevant" and so "not worth caring", which is both quite irritating and
wrong, since many of those actually account for the technodiversity
necessary to keep "innovation" going. I still remember all the buzz I
read about Linux getting "tickless", wow, I mean like, BeOS had it 10
years ago (and Irix probably also but it wasn't really desktop
oriented).

Just like ALSA, which is written by Linux, for Linux, without everyone
else in mind, discrediting OSS API, which actually is defacto std on
UNIX, and making it unportable to anything else.

Maybe those things like KVM could be written in a portable way...
OSSv4 proves kernel code can be written in a portable way, despite them
having to maintain a huge ugly kludge to account for the total lack of
a stable DDM API in Linux... and again the total disregard from Linux
devs dismissing the problem as "you aren't in the kernel tree, you
don't exist". Of course they wouldn't include OSSv4 in the tree since
it's meant to be portable anyway.

Still, Haiku proves one can go forward yet have a stable driver API.
the OSSv4 BeOS port runs fine in Haiku :
http://revolf.free.fr/Alchimie-7/Alchimie7_OSS_Haiku.en.pdf
yet we have a new DDM, bluetooth support, ...

</rant>

Couldn't they just write their KVM code cleanly ?

François.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* [Qemu-devel] Re: [PATCH] remove pieces of source code
  2009-05-30 18:04     ` François Revol
@ 2009-05-31  9:13       ` Jan Kiszka
  0 siblings, 0 replies; 25+ messages in thread
From: Jan Kiszka @ 2009-05-31  9:13 UTC (permalink / raw)
  To: François Revol; +Cc: glommer, aliguori, qemu-devel

[-- Attachment #1: Type: text/plain, Size: 2981 bytes --]

François Revol wrote:
>>> That said, here are the arguments for keeping kqemu
>>>
>>>  o Even though it's unmaintained, it seems to work for people
>> At some point, I bet, at least the Linux bindings will break, and no 
>> one
>> will be interested or able to fix that anymore. Same may happen to 
>> other
>> platforms (doesn't Windows 7 come with a new driver model?).
> 
> Yes and MS even made supplications to hw vendors to write drivers for 
> it, as they got slapped by their own monopoly practices :D
> Instead they should just ask them to release specs so everyone can 
> write drivers for their own OS and restore fair competition...
> 
>>>  o There is no alternative for non-Linux users and folks with non-
>>> VT/SVM
>>> hardware
>> The non-HVM argument will become widely irrelevant (for desktops) 
>> very
> 
> Hmm not everyone has the money to renew their hw every year or so. I 
> still have an AthlonXP and a PentiumM based laptop here, which do work 
> fine.
> 
>> soon. The non-Linux issue will likely persist - unless someone feels 
>> so
>> much pain to write some KVM for those platforms. But as long as there 
>> is
> 
> <rant reason="Sorry you just cought me on a bad day">
> Well, some FOSS devs have a tendancy those years to act like 
> proprietary devs, disregarding other OSes as "non existant, not 
> relevant" and so "not worth caring", which is both quite irritating and 
> wrong, since many of those actually account for the technodiversity 
> necessary to keep "innovation" going. I still remember all the buzz I 
> read about Linux getting "tickless", wow, I mean like, BeOS had it 10 
> years ago (and Irix probably also but it wasn't really desktop 
> oriented).
> 
> Just like ALSA, which is written by Linux, for Linux, without everyone 
> else in mind, discrediting OSS API, which actually is defacto std on 
> UNIX, and making it unportable to anything else.
> 
> Maybe those things like KVM could be written in a portable way...
> OSSv4 proves kernel code can be written in a portable way, despite them 
> having to maintain a huge ugly kludge to account for the total lack of 
> a stable DDM API in Linux... and again the total disregard from Linux 
> devs dismissing the problem as "you aren't in the kernel tree, you 
> don't exist". Of course they wouldn't include OSSv4 in the tree since 
> it's meant to be portable anyway.
> 
> Still, Haiku proves one can go forward yet have a stable driver API.
> the OSSv4 BeOS port runs fine in Haiku :
> http://revolf.free.fr/Alchimie-7/Alchimie7_OSS_Haiku.en.pdf
> yet we have a new DDM, bluetooth support, ...
> 
> </rant>
> 
> Couldn't they just write their KVM code cleanly ?

Rant back: If you contribute to the KVM project, you would have a chance
to influence its direction (always given that you provide a
corresponding added value). But plain ranting doesn't change a single
bit. That's how open source works.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

^ permalink raw reply	[flat|nested] 25+ messages in thread

* [Qemu-devel] Re: [PATCH] remove pieces of source code
  2009-05-30 10:26         ` Andreas Färber
@ 2009-05-31  9:15           ` Jan Kiszka
  2009-05-31 13:08             ` Andreas Färber
  0 siblings, 1 reply; 25+ messages in thread
From: Jan Kiszka @ 2009-05-31  9:15 UTC (permalink / raw)
  To: Andreas Färber; +Cc: Glauber Costa, Consul, qemu-devel

[-- Attachment #1: Type: text/plain, Size: 2089 bytes --]

Andreas Färber wrote:
> 
> Am 29.05.2009 um 20:49 schrieb Glauber Costa:
> 
>> On Fri, May 29, 2009 at 08:43:09AM -0700, Consul wrote:
>>> Glauber Costa wrote:
>>>> But traffic in the mailing list indicates that it is less and less
>>>> the case.
>>>> And more importantly: As it bitrots, nobody fixes it. so...
>>>>
>>>>> o There is no alternative for non-Linux users and folks with
>>>>> non-VT/SVM
>>>>> hardware
>>>>
>>>> Sure, but I don't think kqemu is such an alternative. ;-)
>>>
>>> It is. Without kqemu I'll have no alternative, but switch to VBox or
>>> VMWare.
>>> And none of them work with qcow images.
>> I'm not saying that because of any kind of functionality. I'm saying
>> it is
>> not an alternative, because nobody really maintains it.
> 
> KVM is no alternative either for us because nobody really maintains
> documentation of what interface and functionality we'd have to implement
> on Solaris, Windows, Mac OS X etc. where no KVM is available today.
> 
> I'd expect some documentation here:
> http://www.linux-kvm.org/page/Documents -- but no luck. No "Porting KVM
> For Dummies". ;(

There was and likely will never be any documentation for kqemu either.
But having worked on both, I can say that kvm is by an order of
magnitude easier to understand from its sources than kqemu.

Sorry, but if you are really interested in such a port, having to dig
through source code and ask questions to the community if something
remains unclear should not be the actual problem.

I've once ported the whole Linux IrDA stack to Windows (as its own stack
just sucked). There was no real design document at that point too, but
well structured code and a very responsive community  - which as quite
happy about patches against bugs I found running it "on the evil side".

> 
> I see no problem dumping kqemu support once KVM is available on the
> kqemu platforms, but now is really a bad point in time.

Take it the other way around: This (yet only discussed!) step comes with
the chance to trigger such a development.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

^ permalink raw reply	[flat|nested] 25+ messages in thread

* [Qemu-devel] Re: [PATCH] remove pieces of source code
  2009-05-31  9:15           ` Jan Kiszka
@ 2009-05-31 13:08             ` Andreas Färber
  2009-05-31 13:40               ` Avi Kivity
  2009-05-31 15:10               ` Jan Kiszka
  0 siblings, 2 replies; 25+ messages in thread
From: Andreas Färber @ 2009-05-31 13:08 UTC (permalink / raw)
  To: Jan Kiszka; +Cc: Glauber Costa, Consul, qemu-devel


Am 31.05.2009 um 11:15 schrieb Jan Kiszka:

> Andreas Färber wrote:
>>
>> KVM is no alternative either for us because nobody really maintains
>> documentation of what interface and functionality we'd have to  
>> implement
>> on Solaris, Windows, Mac OS X etc. where no KVM is available today.
>>
>> I'd expect some documentation here:
>> http://www.linux-kvm.org/page/Documents -- but no luck. No "Porting  
>> KVM
>> For Dummies". ;(
>
> There was and likely will never be any documentation for kqemu either.

And I'm not complaining about kqemu. No one has suggested me to start  
new ports of kqemu.

> But having worked on both, I can say that kvm is by an order of
> magnitude easier to understand from its sources than kqemu.
>
> Sorry, but if you are really interested in such a port, having to dig
> through source code and ask questions to the community if something
> remains unclear should not be the actual problem.

It is. My using the kqemu accelerator neither makes me an expert on  
x86 architecture nor on any sort of kernel modules. (Just like some  
understanding of TCG and certain other instruction sets doesn't make  
me too knowledgeable about IRQ, DMA, MMU, TLB and all the other TLAs)

The porting issues start with very basic considerations: IIUC the  
relevant part of KVM porting-wise is the kernel side (assuming that  
sufficient userspace code has arrived in upstream QEMU already), which  
by nature of Linux and according to the FAQ is GPL'ed. Meaning that if  
I attempted to port KVM to a new platform, the kernel module, Kernel  
Extension, daemon, Service, driver or whatever form of implementation  
may be needed on the target OS would be required to be GPL'ed as well.  
Can I create a GPL'ed Kernel Extension for Mac OS X? Questionable,  
since it would probably end up in the same address space as  
proprietary/non-GPL code. Similar potential issues with CDDL'ed  
(Open)Solaris kernel, BSD kernels, MIT/X11'ed Haiku kernel and fully  
closed-source Windows. So, to be on the safe side, I can't start  
implementing KVM by reading the KVM source code but would need  
documentation of the interface that needs to be implemented (cf.  
virtio drivers). If KVM wants to be the one standardized interface  
instead of one of three implementations then it needs formalization.  
There are contradicting answers on whether non-GPL code may legally  
dynamically load GPL code, making code and inline comments not  
necessarily a sufficient replacement for proper documentation.  
Especially if it's not my personal wish, but KVM developers trying to  
force people to port their software in order to make their life easier.

Arguing about Open Source, you are forgetting that not everyone gets  
paid for their Open Source contributions to QEMU. If you work on KVM/ 
QEMU for a living and have the time to work on large'ish porting or  
refactoring projects, that's one facet of Open Source only.
Many other people aren't selling but merely using QEMU, be it as a  
tool for (Open Source) application or operating system development or  
for research, because they favor it as a FOSS solution, contributing  
bugfixes and to ongoing platform support. These are often not the same  
people building QEMU on a per-commit basis, testing every apparently  
unrelated patch before it gets committed and breaks things for them,  
and are thus hit the most when some member of the now highly active  
KVM community decides to shuffle features around or to drop something  
in some upcoming release for valid reasons. Are they really "bad"  
community members? Should they better get lost, let you do your KVM  
work and go buy closed-source VMware instead? Or let partially open  
source VirtualBox freeze their system and ruin their Superdrive? I  
don't think so. Having flourishing KVM code inside QEMU is totally  
fine, but pointing the pistol at others, asking to port KVM to a new  
platform with a fixed timeframe and without documentation, even if KVM  
developers happen to dislike kqemu hooks in the sources and QEMU  
maintainers - being on Linux mainly - have turned to KVM, is not okay.  
The problem is not unwillingness, but rather time, information,  
skills, communicativeness and politeness. It makes a major difference  
if someone steps up and posts on qemu-devel, "hey, we'd like to  
replace kqemu with KVM, let's talk about how and when we can make this  
happen", rather than submitting a patch rendering the kqemu kernel  
module unusable, leaving the majority of its current users standing in  
the rain without replacement accelerator. That's got little to do with  
the spirit of Open Source.

I have a dream of something like the Open Group specification, which  
describes a virtualization standard in terms of required C types,  
preprocessor defines, functions, valid parameters, expected return  
values etc. It would allow multiple source-compatible but differing  
implementations and would in theory even allow to consolidate the  
current virtualization island solutions into sane, interoperable  
solutions. Is this too far from KVM reality?

Andreas

P.S. The "KVM on BSD" page (http://www.linux-kvm.org/page/BSD) does in  
fact instruct people to use kqemu!

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Qemu-devel] Re: [PATCH] remove pieces of source code
  2009-05-31 13:08             ` Andreas Färber
@ 2009-05-31 13:40               ` Avi Kivity
  2009-05-31 16:20                 ` M. Warner Losh
  2009-05-31 15:10               ` Jan Kiszka
  1 sibling, 1 reply; 25+ messages in thread
From: Avi Kivity @ 2009-05-31 13:40 UTC (permalink / raw)
  To: Andreas Färber; +Cc: Glauber Costa, Consul, Jan Kiszka, qemu-devel

Andreas Färber wrote:
> I have a dream of something like the Open Group specification, which 
> describes a virtualization standard in terms of required C types, 
> preprocessor defines, functions, valid parameters, expected return 
> values etc. It would allow multiple source-compatible but differing 
> implementations and would in theory even allow to consolidate the 
> current virtualization island solutions into sane, interoperable 
> solutions. Is this too far from KVM reality?

Aren't those things standardized only after everyone loses interest in them?

It's on my TODO to document the kvm interfaces.  Unfortunately 
documentation jobs tend to stay low on the priority list.  If someone 
wants to volunteer to do this I will render them any assistance I can.

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

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Qemu-devel] Re: [PATCH] remove pieces of source code
  2009-05-29  9:08   ` [Qemu-devel] " Jan Kiszka
                       ` (3 preceding siblings ...)
  2009-05-30 18:04     ` François Revol
@ 2009-05-31 14:53     ` Jamie Lokier
  2009-05-31 15:43       ` Jan Kiszka
  4 siblings, 1 reply; 25+ messages in thread
From: Jamie Lokier @ 2009-05-31 14:53 UTC (permalink / raw)
  To: Jan Kiszka; +Cc: Glauber Costa, aliguori, qemu-devel

Jan Kiszka wrote:
> >  o There is no alternative for non-Linux users and folks with non-VT/SVM
> > hardware
> 
> The non-HVM argument will become widely irrelevant (for desktops) very
> soon.

Only if your looking at the virtualisation market.
As far as I know

    - There are no non-Intel, non-AMD CPUs which support HVM
    - Laptops are outselling desktops these days
    - Little low-power PCs are gaining in popularity at home

Personally I have HVM on one of my laptops but not the other.  I have
several "media player" nano-ITX PCs, and I don't think any of them
support HVM, even the Intel ones.  I have one dual-AMD desktop machine
which does not have HVM.  I have access to two big Intel Xeon servers.
Only one has HVM, and annoyingly the faster one does not have HVM,
even though it's 64-bit.

That's only 2 out 7 PC types I have ready access to which have HVM.

I do understand the wish to drop KQEMU, and I understand the wish of
the staff developers to not want to spend time supporting platforms
they aren't using themselves, and aren't their customers.  Especially
when it complicates the code base.

But it will make QEMU a less useful tool for some.

I suspect if QEMU development was still a "hobby" project, the
"coolness factor" of being able to do things like KQEMU would win over
"target market" rule which I guess is more motivating for paid developers.

Anyway, we had this discussion before and the obvious conclusion was
that the only viable way to keep KQEMU is if there are volunteers
stepping up to maintain it, both the userspace and kernel portions.

Or ideally, to replace it with something KVM-compatible, as that would
reduce the maintenance burden.

For replacing KQEMU on Linux, that's realistic I think.  Either it's
done, or there's no maintainer anyway.

But for non-Linux hosts I see a non-technical problem:

   - Without API documentation you have to read the KVM source code.

   - Those goes doubly so for the fiddly bits like kernel APIC
     emulation and virtio.

   - But it may not be legally safe to read the KVM source code and
     reimplement it in such detail for a GPL-incompatible target kernel.
     (It might be seen as a form of translation).

(We've already seen someone implementing a virtio driver on the list
who was worried about GPL implications).

So how can anyone implement a KVM-compatible replacement for KQEMU on
other host platforms?

-- Jamie

^ permalink raw reply	[flat|nested] 25+ messages in thread

* [Qemu-devel] Re: [PATCH] remove pieces of source code
  2009-05-31 13:08             ` Andreas Färber
  2009-05-31 13:40               ` Avi Kivity
@ 2009-05-31 15:10               ` Jan Kiszka
  2009-06-06 10:17                 ` Andreas Färber
  1 sibling, 1 reply; 25+ messages in thread
From: Jan Kiszka @ 2009-05-31 15:10 UTC (permalink / raw)
  To: Andreas Färber; +Cc: Glauber Costa, Consul, qemu-devel

[-- Attachment #1: Type: text/plain, Size: 6098 bytes --]

Andreas Färber wrote:
> Am 31.05.2009 um 11:15 schrieb Jan Kiszka:
>> Sorry, but if you are really interested in such a port, having to dig
>> through source code and ask questions to the community if something
>> remains unclear should not be the actual problem.
> 
> It is. My using the kqemu accelerator neither makes me an expert on x86
> architecture nor on any sort of kernel modules. (Just like some
> understanding of TCG and certain other instruction sets doesn't make me
> too knowledgeable about IRQ, DMA, MMU, TLB and all the other TLAs)

A certain level of experience (or drive to build it up) is required for
this. This will never be a "mechanical" porting job (for the same
reason, kqemu is doomed to die once things seriously start to fall apart
and there is still no one to dig deeper into it).

> 
> The porting issues start with very basic considerations: IIUC the
> relevant part of KVM porting-wise is the kernel side (assuming that
> sufficient userspace code has arrived in upstream QEMU already), which
> by nature of Linux and according to the FAQ is GPL'ed. Meaning that if I
> attempted to port KVM to a new platform, the kernel module, Kernel
> Extension, daemon, Service, driver or whatever form of implementation
> may be needed on the target OS would be required to be GPL'ed as well.
> Can I create a GPL'ed Kernel Extension for Mac OS X? Questionable, since
> it would probably end up in the same address space as
> proprietary/non-GPL code. Similar potential issues with CDDL'ed
> (Open)Solaris kernel, BSD kernels, MIT/X11'ed Haiku kernel and fully
> closed-source Windows.

Kqemu is already GPLv2, so the picture would not really change. And
unless the license of the target OS does not exclude binding against
GPL'ed drivers, there is no problem to be expected.

> So, to be on the safe side, I can't start
> implementing KVM by reading the KVM source code but would need
> documentation of the interface that needs to be implemented (cf. virtio
> drivers). If KVM wants to be the one standardized interface instead of
> one of three implementations then it needs formalization. There are
> contradicting answers on whether non-GPL code may legally dynamically
> load GPL code, making code and inline comments not necessarily a
> sufficient replacement for proper documentation. Especially if it's not
> my personal wish, but KVM developers trying to force people to port
> their software in order to make their life easier.
> 
> Arguing about Open Source, you are forgetting that not everyone gets
> paid for their Open Source contributions to QEMU. If you work on
> KVM/QEMU for a living and have the time to work on large'ish porting or
> refactoring projects, that's one facet of Open Source only.

Like many others, I'm doing both, ie. not all of my open source work is
directly paid.

> Many other people aren't selling but merely using QEMU, be it as a tool
> for (Open Source) application or operating system development or for
> research, because they favor it as a FOSS solution, contributing
> bugfixes and to ongoing platform support. These are often not the same
> people building QEMU on a per-commit basis, testing every apparently
> unrelated patch before it gets committed and breaks things for them, and
> are thus hit the most when some member of the now highly active KVM
> community decides to shuffle features around or to drop something in
> some upcoming release for valid reasons. Are they really "bad" community
> members? Should they better get lost, let you do your KVM work and go
> buy closed-source VMware instead? Or let partially open source
> VirtualBox freeze their system and ruin their Superdrive? I don't think
> so. Having flourishing KVM code inside QEMU is totally fine, but
> pointing the pistol at others, asking to port KVM to a new platform with
> a fixed timeframe and without documentation, even if KVM developers
> happen to dislike kqemu hooks in the sources and QEMU maintainers -
> being on Linux mainly - have turned to KVM, is not okay. The problem is
> not unwillingness, but rather time, information, skills,
> communicativeness and politeness. It makes a major difference if someone
> steps up and posts on qemu-devel, "hey, we'd like to replace kqemu with
> KVM, let's talk about how and when we can make this happen", rather than
> submitting a patch rendering the kqemu kernel module unusable, leaving
> the majority of its current users standing in the rain without
> replacement accelerator. That's got little to do with the spirit of Open
> Source.

As we are doing open source, we do have this discussion here and now, we
do consider options how to evolve qemu best (instead of just sticking
*forever* with legacy support that is no longer making progress and is
starting to cause troubles), and we do not just discontinue it like it
may happen with some commercial software.

Recall: Removing kqemu did not make into the repos, it did not even make
it on the agenda for 0.11. So there will like be at least another year
to look for alternatives on other platforms + the ability to use stable
0.11 even longer - at least as long as kqemu works.

> 
> I have a dream of something like the Open Group specification, which
> describes a virtualization standard in terms of required C types,
> preprocessor defines, functions, valid parameters, expected return
> values etc. It would allow multiple source-compatible but differing
> implementations and would in theory even allow to consolidate the
> current virtualization island solutions into sane, interoperable
> solutions. Is this too far from KVM reality?

As I tried to explain: All nice ideas also require someone to work on
them or to pay for this or to otherwise convincingly motivate people to
do this.

> 
> Andreas
> 
> P.S. The "KVM on BSD" page (http://www.linux-kvm.org/page/BSD) does in
> fact instruct people to use kqemu!
> 

Should probably be fixed or even dropped (it suggests that on FreeBSD
kqemu == kvm).

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

^ permalink raw reply	[flat|nested] 25+ messages in thread

* [Qemu-devel] Re: [PATCH] remove pieces of source code
  2009-05-31 14:53     ` Jamie Lokier
@ 2009-05-31 15:43       ` Jan Kiszka
  0 siblings, 0 replies; 25+ messages in thread
From: Jan Kiszka @ 2009-05-31 15:43 UTC (permalink / raw)
  To: Jamie Lokier; +Cc: Glauber Costa, aliguori, qemu-devel

[-- Attachment #1: Type: text/plain, Size: 4840 bytes --]

Jamie Lokier wrote:
> Jan Kiszka wrote:
>>>  o There is no alternative for non-Linux users and folks with non-VT/SVM
>>> hardware
>> The non-HVM argument will become widely irrelevant (for desktops) very
>> soon.
> 
> Only if your looking at the virtualisation market.
> As far as I know
> 
>     - There are no non-Intel, non-AMD CPUs which support HVM
>     - Laptops are outselling desktops these days
>     - Little low-power PCs are gaining in popularity at home

VIA will soon (or already started to?) deliver working VT-x support with
their CPUs. As HVM also became a marketing tag, probably only very
resource-restricted systems will soon be sold without it, and on those
kqemu is no fun anyway (at best only for very very resource-restricted
guests).

> 
> Personally I have HVM on one of my laptops but not the other.  I have
> several "media player" nano-ITX PCs, and I don't think any of them
> support HVM, even the Intel ones.  I have one dual-AMD desktop machine
> which does not have HVM.  I have access to two big Intel Xeon servers.
> Only one has HVM, and annoyingly the faster one does not have HVM,
> even though it's 64-bit.
> 
> That's only 2 out 7 PC types I have ready access to which have HVM.
> 
> I do understand the wish to drop KQEMU, and I understand the wish of
> the staff developers to not want to spend time supporting platforms
> they aren't using themselves, and aren't their customers.  Especially
> when it complicates the code base.
> 
> But it will make QEMU a less useful tool for some.
> 
> I suspect if QEMU development was still a "hobby" project, the
> "coolness factor" of being able to do things like KQEMU would win over
> "target market" rule which I guess is more motivating for paid developers.

That wouldn't change any of the technical problems it has. If we had no
broadly available HVM support today, /then/ you could bet that a kqemu
rewrite would be on the way, either driven by hobbyists or commercial use.

> 
> Anyway, we had this discussion before and the obvious conclusion was
> that the only viable way to keep KQEMU is if there are volunteers
> stepping up to maintain it, both the userspace and kernel portions.
> 
> Or ideally, to replace it with something KVM-compatible, as that would
> reduce the maintenance burden.
> 
> For replacing KQEMU on Linux, that's realistic I think.  Either it's
> done, or there's no maintainer anyway.
> 
> But for non-Linux hosts I see a non-technical problem:
> 
>    - Without API documentation you have to read the KVM source code.
> 
>    - Those goes doubly so for the fiddly bits like kernel APIC
>      emulation and virtio.
> 
>    - But it may not be legally safe to read the KVM source code and
>      reimplement it in such detail for a GPL-incompatible target kernel.
>      (It might be seen as a form of translation).

For that case (and Avi still haven written the API docs): Take (at
least) two people, one reading the source and writing that docs and the
others reading the docs and re-implementing a backend under whatever
license they want.

> 
> (We've already seen someone implementing a virtio driver on the list
> who was worried about GPL implications).
> 
> So how can anyone implement a KVM-compatible replacement for KQEMU on
> other host platforms?

It's not that easy. The major design challenge is that kqemu is running
in cooperative mode with TCG, using the latter to handle cases the
in-kernel monitor cannot (or doesn't want to due to performance/latency
impact). Kvm does not need this as its guest-host switches are less
frequent and less heavy. We played with an approach to drive kqemu into
the same direction (patch and trap those un-virtualizable instructions)
and reduced the exists. The next step would have been to adopt kvm's I/O
handling philosophy (or even code), but problems of our approach on
heavily segmented guests stopped the effort.

There might have been another issue of the patch&trap approach:
self-checking guests (you can't easily hide the binary changes from the
guest). Then the only option would have been to translate the guest code
like TCG already does, but optimized for host = guest = x86. But that
effort would have been enormous and simply no longer worth it.


That said, I think the best one can do for kqemu remaining a qemu
citizen is to move it out of the way the latter wants to take, e.g.
eliminating the reason for

/* address in the RAM (different from a physical address) */
#ifdef CONFIG_KQEMU
/* FIXME: This is wrong.  */
typedef uint32_t ram_addr_t;
#else
typedef unsigned long ram_addr_t;
#endif

or reducing the impact of its hooks. One could, as another example, push
the hooks in cpu_in/out to helpers injected into the TCG output.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Qemu-devel] Re: [PATCH] remove pieces of source code
  2009-05-31 13:40               ` Avi Kivity
@ 2009-05-31 16:20                 ` M. Warner Losh
  0 siblings, 0 replies; 25+ messages in thread
From: M. Warner Losh @ 2009-05-31 16:20 UTC (permalink / raw)
  To: avi; +Cc: andreas.faerber, void, jan.kiszka, glommer, qemu-devel

In message: <4A2288C6.9070206@redhat.com>
            Avi Kivity <avi@redhat.com> writes:
: Andreas Färber wrote:
: > I have a dream of something like the Open Group specification, which 
: > describes a virtualization standard in terms of required C types, 
: > preprocessor defines, functions, valid parameters, expected return 
: > values etc. It would allow multiple source-compatible but differing 
: > implementations and would in theory even allow to consolidate the 
: > current virtualization island solutions into sane, interoperable 
: > solutions. Is this too far from KVM reality?
: 
: Aren't those things standardized only after everyone loses interest in them?
: 
: It's on my TODO to document the kvm interfaces.  Unfortunately 
: documentation jobs tend to stay low on the priority list.  If someone 
: wants to volunteer to do this I will render them any assistance I can.

Documenting is a good way to learn interfaces as well.  Especially if
you can get people who know what they really do (or should do) review
your initial idea of what's going on... :)

Warner

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Qemu-devel] Re: [PATCH] remove pieces of source code
  2009-05-29  9:12     ` Anthony Liguori
  2009-05-29  9:35       ` Stefan Weil
@ 2009-06-02 20:09       ` Stuart Brady
  2009-06-02 20:29         ` Avi Kivity
  1 sibling, 1 reply; 25+ messages in thread
From: Stuart Brady @ 2009-06-02 20:09 UTC (permalink / raw)
  To: qemu-devel

On Fri, May 29, 2009 at 04:12:52AM -0500, Anthony Liguori wrote:
> If we disable in configure, then we should remove it from the tree.  The
> feeling is that code that's disabled by default is too likely to bitrot.
> 
> I think you've made a reasonable suggestion though.  So unless there are
> strong feelings otherwise, I think we should do -no-kqemu by default for
> 0.11, see what the reaction is, then figure out whether we want to
> deprecate/remove.

One option that has not been suggested is building binaries both with and
without kqemu enabled by default.  This would allow limitations that are
imposed by enabling kqemu to be avoided, but wouldn't help to avoid any
limitations imposed by the mere existence of kqemu support in the code.
It also gives the user an extra binary that they shouldn't really have
to know or care about, and prevents any "what happened to kqemu?!"
feedback from being received.

However, as an intermediate step, perhaps it might be worth considering.

Either way, kqemu will clearly disappear at some point, unless someone
with the required knowledge, skill, time, interest and pervasiveness
intervenes.

Silly question, btw -- I've heard on several occasions that kqemu is not
auditable.  Is it even possible to produce a replacement with reasonable
performance that *is* auditable?

(Whilst I certainly have the interest, I'm not sure whether I possess a
sufficient quantity of the other four required attributes to implement
something like this for KVM, if such a thing is even possible.)

Cheers,
-- 
Stuart Brady

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Qemu-devel] Re: [PATCH] remove pieces of source code
  2009-06-02 20:09       ` Stuart Brady
@ 2009-06-02 20:29         ` Avi Kivity
  0 siblings, 0 replies; 25+ messages in thread
From: Avi Kivity @ 2009-06-02 20:29 UTC (permalink / raw)
  To: Stuart Brady; +Cc: qemu-devel

Stuart Brady wrote:
> Silly question, btw -- I've heard on several occasions that kqemu is not
> auditable.  Is it even possible to produce a replacement with reasonable
> performance that *is* auditable?
>   

Is it possible to produce a large scale system-level program (esp. with 
smp) that is auditable?  I think not.

kqemu is particularly difficult because it interacts with the hardware 
in complex ways.

> (Whilst I certainly have the interest, I'm not sure whether I possess a
> sufficient quantity of the other four required attributes to implement
> something like this for KVM, if such a thing is even possible.)

It's technically possible, but I don't think it's realistic.  No one 
wants to code for yesterday's hardware; every day there are fewer 
machines that need kqemu.

If you're interested in virtualization, but a cpu that supports 
virtualization.  If you want to keep your old cpu, keep your old 
software as well.

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

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [Qemu-devel] Re: [PATCH] remove pieces of source code
  2009-05-31 15:10               ` Jan Kiszka
@ 2009-06-06 10:17                 ` Andreas Färber
  0 siblings, 0 replies; 25+ messages in thread
From: Andreas Färber @ 2009-06-06 10:17 UTC (permalink / raw)
  To: Jan Kiszka; +Cc: Glauber Costa, qemu-devel


Am 31.05.2009 um 17:10 schrieb Jan Kiszka:

> Andreas Färber wrote:
>> Can I create a GPL'ed Kernel Extension for Mac OS X? Questionable,  
>> since
>> it would probably end up in the same address space as
>> proprietary/non-GPL code. Similar potential issues with CDDL'ed
>> (Open)Solaris kernel, BSD kernels, MIT/X11'ed Haiku kernel and fully
>> closed-source Windows.
>
> Kqemu is already GPLv2, so the picture would not really change.

I've extended the picture here - the kqemu platforms I'm aware of are  
Linux, Windows, Solaris, BSDs, BeOS.
Mac OS X was not among them. And kqemu for Solaris is already  
partially CDDL in addition to GPLv2.

>
>> Arguing about Open Source, you are forgetting that not everyone gets
>> paid for their Open Source contributions to QEMU. If you work on
>> KVM/QEMU for a living and have the time to work on large'ish  
>> porting or
>> refactoring projects, that's one facet of Open Source only.
>
> Like many others, I'm doing both, ie. not all of my open source work  
> is
> directly paid.

You, plural! :)

As a matter of fact, with KVM the pace of development has become hard  
to follow - within days there are hundreds of mails in your inbox.
My point being that it's nice if this leads to shining new cool  
features for all of us, but not so nice if suddenly put under the same  
pressure to deliver features. For example, compare a KVM upstream  
patch not being reviewed for a week to Cocoa being broken for a number  
of weeks during the DisplayState refactoring or ppc host being broken  
for months during TCG conversion - different paces.

Andreas

^ permalink raw reply	[flat|nested] 25+ messages in thread

end of thread, other threads:[~2009-06-06 10:19 UTC | newest]

Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-05-28 23:03 [Qemu-devel] [PATCH] remove pieces of source code Glauber Costa
2009-05-29  5:50 ` Anthony Liguori
2009-05-29  9:08   ` [Qemu-devel] " Jan Kiszka
2009-05-29  9:12     ` Anthony Liguori
2009-05-29  9:35       ` Stefan Weil
2009-06-02 20:09       ` Stuart Brady
2009-06-02 20:29         ` Avi Kivity
2009-05-29 10:00     ` Daniel P. Berrange
2009-05-29 10:20       ` Jan Kiszka
2009-05-29 11:35     ` Glauber Costa
2009-05-30 18:04     ` François Revol
2009-05-31  9:13       ` Jan Kiszka
2009-05-31 14:53     ` Jamie Lokier
2009-05-31 15:43       ` Jan Kiszka
2009-05-29 11:32   ` [Qemu-devel] " Glauber Costa
2009-05-29 11:42     ` Gerd Hoffmann
2009-05-29 15:43     ` [Qemu-devel] " Consul
2009-05-29 18:49       ` Glauber Costa
2009-05-30 10:26         ` Andreas Färber
2009-05-31  9:15           ` Jan Kiszka
2009-05-31 13:08             ` Andreas Färber
2009-05-31 13:40               ` Avi Kivity
2009-05-31 16:20                 ` M. Warner Losh
2009-05-31 15:10               ` Jan Kiszka
2009-06-06 10:17                 ` Andreas Färber

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.