Has any work 3.3 kvm-kmod for rhel 6.2 kernel successfully?

Has any work 3.3 kvm-kmod for rhel 6.2 kernel successfully?

[ya su]

Hi,all:

    I try 3.3 kvm-kmod to compile against redhat 2.6.32-220.7.1, after
change some macros in external-module-compat-comm.h ,
external-module-compat.h, and in some C files, finally I can compile
and run qemu-kvm(0.12 with rhel release) with 3.3 module, everything
looks fine except that screen-display can not flush correctly,  it
looks like the display-card memory can not get updated in time when it
changes.

   Is there anyone that can give me some clues, thanks.

Regards.

Suya.

Re: Has any work 3.3 kvm-kmod for rhel 6.2 kernel successfully?

[Nadav Har'El]

On Mon, Apr 16, 2012, ya su wrote about "Has any work 3.3 kvm-kmod for rhel 6.2 kernel successfully?":
> Hi,all:
> 
>     I try 3.3 kvm-kmod to compile against redhat 2.6.32-220.7.1, after
> change some macros in external-module-compat-comm.h ,
> external-module-compat.h, and in some C files, finally I can compile
> and run qemu-kvm(0.12 with rhel release) with 3.3 module, everything
> looks fine except that screen-display can not flush correctly,  it
> looks like the display-card memory can not get updated in time when it
> changes.
> 
>    Is there anyone that can give me some clues, thanks.

I don't have an answer to your specific question (about kmod on 2.6.32),
but perhaps you can provide more information - what guest were you using
(also Redhat Linux with 2.6.32? something different?)? Does the problem
also happen for different guests? And what do you mean by "screen display
cannot flush correctly"? Are you using an emulated serial console, emulated
VGA (on X? on VNC?), or what?

-- 
Nadav Har'El                        |                    Monday, Apr 16 2012, 
nyh@math.technion.ac.il             |-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |If Barbie is so popular, why do you have
http://nadav.harel.org.il           |to buy her friends?

Re: Has any work 3.3 kvm-kmod for rhel 6.2 kernel successfully?

[Jan Kiszka]

On 2012-04-16 12:12, ya su wrote:
> Hi,all:
> 
>     I try 3.3 kvm-kmod to compile against redhat 2.6.32-220.7.1, after
> change some macros in external-module-compat-comm.h ,
> external-module-compat.h, and in some C files, finally I can compile
> and run qemu-kvm(0.12 with rhel release) with 3.3 module, everything
> looks fine except that screen-display can not flush correctly,  it
> looks like the display-card memory can not get updated in time when it
> changes.
> 
>    Is there anyone that can give me some clues, thanks.

Maybe you can share your adoptions to make it easier to asses to what
degree that kernel is different from a real 2.6.32 kernel.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: Has any work 3.3 kvm-kmod for rhel 6.2 kernel successfully?

[ya su]

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

kvm-kmod 3.3 patch attached.

I also change kernel to export __get_user_pages_fast.

Regards.

Suya.


2012/4/16, Jan Kiszka <jan.kiszka@siemens.com>:
> On 2012-04-16 12:12, ya su wrote:
>> Hi,all:
>>
>>     I try 3.3 kvm-kmod to compile against redhat 2.6.32-220.7.1, after
>> change some macros in external-module-compat-comm.h ,
>> external-module-compat.h, and in some C files, finally I can compile
>> and run qemu-kvm(0.12 with rhel release) with 3.3 module, everything
>> looks fine except that screen-display can not flush correctly,  it
>> looks like the display-card memory can not get updated in time when it
>> changes.
>>
>>    Is there anyone that can give me some clues, thanks.
>
> Maybe you can share your adoptions to make it easier to asses to what
> degree that kernel is different from a real 2.6.32 kernel.
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT T DE IT 1
> Corporate Competence Center Embedded Linux
>

[-- Attachment #2: kvm-kmod.patch --]
[-- Type: application/octet-stream, Size: 13351 bytes --]

diff -ur /root/src/kvm-kmod-3.3/external-module-compat.c kvm-kmod-3.3/external-module-compat.c
--- /root/src/kvm-kmod-3.3/external-module-compat.c	2012-03-20 06:00:42.000000000 +0800
+++ kvm-kmod-3.3/external-module-compat.c	2012-04-16 16:18:55.111812633 +0800
@@ -267,7 +267,7 @@
 
 #endif /* CONFIG_USER_RETURN_NOTIFIER */
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,39)
+#if 0 //LINUX_VERSION_CODE < KERNEL_VERSION(2,6,39)
 
 #include <linux/kvm_host.h>
 
diff -ur /root/src/kvm-kmod-3.3/external-module-compat-comm.h kvm-kmod-3.3/external-module-compat-comm.h
--- /root/src/kvm-kmod-3.3/external-module-compat-comm.h	2012-03-20 06:00:42.000000000 +0800
+++ kvm-kmod-3.3/external-module-compat-comm.h	2012-04-16 20:01:13.426968264 +0800
@@ -203,7 +203,8 @@
 
 #endif
 
-#ifdef KVM_NEED_PAGEFAULT_DISABLE
+#if 0 
+def KVM_NEED_PAGEFAULT_DISABLE
 
 static inline void pagefault_disable(void)
 {
@@ -271,7 +272,7 @@
 
 #endif
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,37)
+#if 0 //LINUX_VERSION_CODE < KERNEL_VERSION(2,6,37)
 
 #include <linux/mm.h>
 
@@ -447,7 +448,8 @@
 #define marker_synchronize_unregister() synchronize_sched()
 #endif
 
-#ifdef NEED_COMPOUND_HEAD
+#if 0 
+def NEED_COMPOUND_HEAD
 
 static inline struct page *compound_head(struct page *page)
 {
@@ -482,7 +484,7 @@
 
 #include <linux/tracepoint.h>
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,33)
+#if 0 //LINUX_VERSION_CODE < KERNEL_VERSION(2,6,33)
 
 struct tracepoint;
 
@@ -656,7 +658,7 @@
 
 #endif /* CONFIG_USER_RETURN_NOTIFIER */
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,33)
+#if 0 //LINUX_VERSION_CODE < KERNEL_VERSION(2,6,33)
 
 #ifdef CONFIG_SMP
 void kvm_synchronize_srcu_expedited(struct srcu_struct *sp);
@@ -718,8 +720,10 @@
 #endif
 }
 
-#if defined(CONFIG_PCI) && LINUX_VERSION_CODE < KERNEL_VERSION(2,6,33) && \
+#if 0 
+/*defined(CONFIG_PCI) && LINUX_VERSION_CODE < KERNEL_VERSION(2,6,33) && \
     (!defined(CONFIG_SUSE_KERNEL) || LINUX_VERSION_CODE < KERNEL_VERSION(2,6,32))
+*/
 #include <linux/pci.h>
 static inline struct pci_dev *
 pci_get_domain_bus_and_slot(int domain, unsigned int bus, unsigned int devfn)
@@ -743,7 +747,7 @@
 
 #endif
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,35)
+#if 0 //LINUX_VERSION_CODE < KERNEL_VERSION(2,6,35)
 struct perf_guest_info_callbacks {
 	int (*is_in_guest) (void);
 	int (*is_user_mode) (void);
@@ -821,7 +825,7 @@
 #define lower_32_bits(n) ((u32)(n))
 #endif
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,39)
+#if 0 //LINUX_VERSION_CODE < KERNEL_VERSION(2,6,39)
 #define EHWPOISON	133	/* Memory page has hardware error */
 #define FOLL_HWPOISON	0x100	/* check page is hwpoisoned */
 
@@ -873,7 +877,7 @@
 
 /* Services below are only referenced by code unused in older kernels */
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,34)
+#if 0 //LINUX_VERSION_CODE < KERNEL_VERSION(2,6,34)
 static inline void kvm_use_mm(struct mm_struct *mm)
 {
 	BUG();
@@ -901,11 +905,13 @@
 #define __rcu
 #endif
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,37) && \
+#if 0 
+/*LINUX_VERSION_CODE < KERNEL_VERSION(2,6,37) && \
     (!defined(CONFIG_FEDORA_KERNEL) || \
      (LINUX_VERSION_CODE == KERNEL_VERSION(2,6,35) && \
       KERNEL_EXTRAVERSION < 11) || \
      LINUX_VERSION_CODE < KERNEL_VERSION(2,6,35))
+*/
 #include <linux/vmalloc.h>
 static inline void *vzalloc(unsigned long size)
 {
@@ -932,7 +938,7 @@
 #define kvm_request_threaded_irq	request_threaded_irq
 #endif
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,38)
+#if 0 //LINUX_VERSION_CODE < KERNEL_VERSION(2,6,38)
 #define compound_trans_head(page) compound_head(page)
 
 static inline int PageTransCompound(struct page *page)
@@ -949,7 +955,7 @@
 #define kvm___this_cpu_write		__this_cpu_write
 #endif /* > 2.6.33 */
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,39)
+#if 0 //LINUX_VERSION_CODE < KERNEL_VERSION(2,6,39)
 #define kvm_get_task_pid(t, pt)	(t)->pids[pt].pid
 #define kvm_put_pid(p)		p = p
 #else /* >= 2.6.39 */
@@ -984,7 +990,7 @@
 #define __set_bit_le	ext2_set_bit
 #endif
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(3,0,0)
+#if 0 //LINUX_VERSION_CODE < KERNEL_VERSION(3,0,0)
 static inline void rcu_virt_note_context_switch(int cpu)
 {
 }
@@ -1008,9 +1014,9 @@
 #endif /* >= 3.1 */
 #endif /* CONFIG_COMPAT */
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,33)
+#if 0 //LINUX_VERSION_CODE < KERNEL_VERSION(2,6,33)
 
-#ifdef CONFIG_PRINTK
+#if def CONFIG_PRINTK
 #define printk_ratelimited(fmt, ...)					\
 ({									\
 	static DEFINE_RATELIMIT_STATE(_rs,				\
@@ -1043,7 +1049,7 @@
 
 #endif /* < 2.6.35 */
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(3,1,0)
+#if 0 //LINUX_VERSION_CODE < KERNEL_VERSION(3,1,0)
 static inline int kvm_sched_info_on(void)
 {
 #ifdef CONFIG_SCHEDSTATS
diff -ur /root/src/kvm-kmod-3.3/srcu.c kvm-kmod-3.3/srcu.c
--- /root/src/kvm-kmod-3.3/srcu.c	2012-03-20 06:00:42.000000000 +0800
+++ kvm-kmod-3.3/srcu.c	2012-04-16 14:47:28.509802286 +0800
@@ -35,7 +35,8 @@
 #include <linux/srcu.h>
 #include <linux/kthread.h>
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,33) && defined(CONFIG_SMP)
+#if 0 
+LINUX_VERSION_CODE < KERNEL_VERSION(2,6,33) && defined(CONFIG_SMP)
 
 /*
  * srcu_readers_active_idx -- returns approximate number of readers
diff -ur /root/src/kvm-kmod-3.3/x86/compat-x86.c kvm-kmod-3.3/x86/compat-x86.c
--- /root/src/kvm-kmod-3.3/x86/compat-x86.c	2012-03-20 06:00:42.000000000 +0800
+++ kvm-kmod-3.3/x86/compat-x86.c	2012-04-16 16:16:43.722802282 +0800
@@ -1,5 +1,5 @@
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,36)
+#if 0 //LINUX_VERSION_CODE < KERNEL_VERSION(2,6,36)
 
 unsigned int kvm_xstate_size;
 
diff -ur /root/src/kvm-kmod-3.3/x86/eventfd.c kvm-kmod-3.3/x86/eventfd.c
--- /root/src/kvm-kmod-3.3/x86/eventfd.c	2012-03-20 06:00:56.000000000 +0800
+++ kvm-kmod-3.3/x86/eventfd.c	2012-04-16 15:08:31.192719176 +0800
@@ -77,7 +77,6 @@
  * --------------------------------------------------------------------
  */
 
-#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,33)
 struct _irqfd {
 	/* Used for MSI fast-path */
 	struct kvm *kvm;
@@ -690,12 +689,3 @@
 
 	return kvm_assign_ioeventfd(kvm, args);
 }
-#else
-void kvm_eventfd_init(struct kvm *kvm) { }
-void kvm_irqfd_release(struct kvm *kvm) { }
-void kvm_irq_routing_update(struct kvm *kvm,
-                            struct kvm_irq_routing_table *irq_rt)
-{
-	rcu_assign_pointer(kvm->irq_routing, irq_rt);
-}
-#endif
diff -ur /root/src/kvm-kmod-3.3/x86/external-module-compat.h kvm-kmod-3.3/x86/external-module-compat.h
--- /root/src/kvm-kmod-3.3/x86/external-module-compat.h	2012-03-20 06:00:42.000000000 +0800
+++ kvm-kmod-3.3/x86/external-module-compat.h	2012-04-16 16:49:11.880968642 +0800
@@ -852,7 +852,8 @@
 #define percpu_write(t, v)	__get_cpu_var(t) = v
 #endif
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,32) || \
+#if 0 
+LINUX_VERSION_CODE < KERNEL_VERSION(2,6,32) || \
     (LINUX_VERSION_CODE == KERNEL_VERSION(2,6,32) && \
      KERNEL_EXTRAVERSION < 16) || \
     (LINUX_VERSION_CODE == KERNEL_VERSION(2,6,33) && \
@@ -865,7 +866,7 @@
 #define KVM_TBOOT_ENABLED_WORKS	1
 #endif
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,35)
+#if 0 //LINUX_VERSION_CODE < KERNEL_VERSION(2,6,35)
 struct kvm_pvclock_vcpu_time_info {
 	u32   version;
 	u32   pad0;
@@ -890,7 +891,7 @@
 
 #include <asm/i387.h>
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,35)
+#if 0 //LINUX_VERSION_CODE < KERNEL_VERSION(2,6,35)
 struct kvm_i387_fxsave_struct {
 	u16	cwd;
 	u16	swd;
@@ -936,7 +937,7 @@
 
 #endif /* >= 2.6.35 */
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,36)
+#if 0 //LINUX_VERSION_CODE < KERNEL_VERSION(2,6,36)
 
 struct kvm_compat_fpu {
 	union kvm_thread_xstate state_buffer;
@@ -1039,7 +1040,7 @@
 #define XSAVE_HDR_OFFSET    512
 #endif
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,28)
+#if 0 //LINUX_VERSION_CODE < KERNEL_VERSION(2,6,28)
 #define kvm_cpu_has_xsave	0
 #else /* >= 2.6.28 */
 #define kvm_cpu_has_xsave	cpu_has_xsave
@@ -1115,8 +1116,10 @@
 
 #endif /* >= 2.6.36 */
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,37) && \
+#if 0 
+/*LINUX_VERSION_CODE < KERNEL_VERSION(2,6,37) && \
     (LINUX_VERSION_CODE != KERNEL_VERSION(2,6,32) || KERNEL_EXTRAVERSION < 40)
+*/
 static inline u64 pvclock_scale_delta(u64 delta, u32 mul_frac, int shift)
 {
 	u64 product;
@@ -1173,7 +1176,7 @@
 	asm("mov %%" #seg ",%0":"=r" (value) : : "memory")
 #endif
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,35)
+#if 0 //LINUX_VERSION_CODE < KERNEL_VERSION(2,6,35)
 #define static_cpu_has(bit) boot_cpu_has(bit)
 #endif
 
@@ -1237,7 +1240,7 @@
 #define X86_PMC_MAX_FIXED					3
 #endif
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,35)
+#if 0 //LINUX_VERSION_CODE < KERNEL_VERSION(2,6,35)
 union kvm_cpuid10_eax {
 	struct {
 		unsigned int version_id:8;
@@ -1251,7 +1254,7 @@
 #define kvm_cpuid10_eax	cpuid10_eax
 #endif
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,36)
+#if 0 //LINUX_VERSION_CODE < KERNEL_VERSION(2,6,36)
 union kvm_cpuid10_edx {
 	struct {
 		unsigned int num_counters_fixed:5;
diff -ur /root/src/kvm-kmod-3.3/x86/kvm_main.c kvm-kmod-3.3/x86/kvm_main.c
--- /root/src/kvm-kmod-3.3/x86/kvm_main.c	2012-03-20 06:00:56.000000000 +0800
+++ kvm-kmod-3.3/x86/kvm_main.c	2012-04-16 20:00:20.673075540 +0800
@@ -427,7 +427,7 @@
 	return young;
 }
 
-#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,38)
+#if 1 
 static int kvm_mmu_notifier_test_young(struct mmu_notifier *mn,
 				       struct mm_struct *mm,
 				       unsigned long address)
@@ -461,7 +461,7 @@
 	.invalidate_range_start	= kvm_mmu_notifier_invalidate_range_start,
 	.invalidate_range_end	= kvm_mmu_notifier_invalidate_range_end,
 	.clear_flush_young	= kvm_mmu_notifier_clear_flush_young,
-#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,38)
+#if 1
 	.test_young		= kvm_mmu_notifier_test_young,
 #endif
 #ifdef MMU_NOTIFIER_HAS_CHANGE_PTE
@@ -1155,8 +1155,11 @@
 
 	if (write)
 		flags |= FOLL_WRITE;
-
+#if 0
 	return __get_user_pages(tsk, mm, start, 1, flags, page, NULL, NULL);
+#else
+        return __get_user_pages(tsk, mm, start, 1, flags, page, NULL);
+#endif
 }
 
 static inline int check_user_page_hwpoison(unsigned long addr)
@@ -1164,7 +1167,11 @@
 	int rc, flags = FOLL_TOUCH | FOLL_HWPOISON | FOLL_WRITE;
 
 	rc = __get_user_pages(current, current->mm, addr, 1,
+#if 0
 			      flags, NULL, NULL, NULL);
+#else
+                              flags, NULL, NULL);
+#endif
 	return rc == -EHWPOISON;
 }
 
@@ -1269,7 +1276,7 @@
 		return page_to_pfn(bad_page);
 	}
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,39)
+#if 1 //LINUX_VERSION_CODE < KERNEL_VERSION(2,6,39)
 	async = NULL;
 #endif
 	return hva_to_pfn(kvm, addr, atomic, async, write_fault, writable);
@@ -1637,7 +1644,7 @@
 }
 EXPORT_SYMBOL_GPL(kvm_resched);
 
-#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,39)
+#if 1 //LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,39)
 void kvm_vcpu_on_spin(struct kvm_vcpu *me)
 {
 	struct kvm *kvm = me->kvm;
@@ -2125,7 +2132,7 @@
 		break;
 	}
 #endif
-#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,33)
+#if 1
 	case KVM_IRQFD: {
 		struct kvm_irqfd data;
 
@@ -2136,7 +2143,7 @@
 		break;
 	}
 #endif
-#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,33)
+#if 1 
 	case KVM_IOEVENTFD: {
 		struct kvm_ioeventfd data;
 
@@ -2455,18 +2462,10 @@
 		       cpu);
 		hardware_disable(NULL);
 		break;
-#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,28)
 	case CPU_STARTING:
-#else
-	case CPU_ONLINE:
-#endif
 		printk(KERN_INFO "kvm: enabling virtualization on CPU%d\n",
 		       cpu);
-#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,28)
 		hardware_enable(NULL);
-#else
-		smp_call_function_single(cpu, hardware_enable, NULL, 1);
-#endif
 		break;
 	}
 	return NOTIFY_OK;
diff -ur /root/src/kvm-kmod-3.3/x86/mmu.c kvm-kmod-3.3/x86/mmu.c
--- /root/src/kvm-kmod-3.3/x86/mmu.c	2012-03-20 06:00:56.000000000 +0800
+++ kvm-kmod-3.3/x86/mmu.c	2012-04-14 16:58:31.103842804 +0800
@@ -3939,9 +3939,9 @@
 	kvm_mmu_prepare_zap_page(kvm, page, invalid_list);
 }
 
-#if LINUX_VERSION_CODE >= KERNEL_VERSION(3,0,0)
+#if 0 //LINUX_VERSION_CODE >= KERNEL_VERSION(3,0,0)
 static int mmu_shrink(struct shrinker *shrink, struct shrink_control *sc)
-#elif LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,35)
+#elif 1 //LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,35)
 static int mmu_shrink(struct shrinker *shrink, int nr_to_scan, gfp_t gfp_mask)
 #else
 static int mmu_shrink(int nr_to_scan, gfp_t gfp_mask)
diff -ur /root/src/kvm-kmod-3.3/x86/x86.c kvm-kmod-3.3/x86/x86.c
--- /root/src/kvm-kmod-3.3/x86/x86.c	2012-03-20 06:00:56.000000000 +0800
+++ kvm-kmod-3.3/x86/x86.c	2012-04-16 16:01:17.944050813 +0800
@@ -122,11 +122,8 @@
 struct kvm_x86_ops *kvm_x86_ops;
 EXPORT_SYMBOL_GPL(kvm_x86_ops);
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,31)
-static int ignore_msrs = 0;
-#else
 static bool ignore_msrs = 0;
-#endif
+
 module_param(ignore_msrs, bool, S_IRUGO | S_IWUSR);
 
 bool kvm_has_tsc_control;
@@ -2102,10 +2099,8 @@
 	case KVM_CAP_REINJECT_CONTROL:
 	case KVM_CAP_IRQ_INJECT_STATUS:
 	case KVM_CAP_ASSIGN_DEV_IRQ:
-#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,33)
 	case KVM_CAP_IRQFD:
 	case KVM_CAP_IOEVENTFD:
-#endif
 	case KVM_CAP_PIT2:
 	case KVM_CAP_PIT_STATE2:
 	case KVM_CAP_SET_IDENTITY_MAP_ADDR:
@@ -2119,9 +2114,7 @@
 	case KVM_CAP_DEBUGREGS:
 	case KVM_CAP_X86_ROBUST_SINGLESTEP:
 	case KVM_CAP_XSAVE:
-#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,39)
 	case KVM_CAP_ASYNC_PF:
-#endif
 	case KVM_CAP_GET_TSC_KHZ:
 		r = 1;
 		break;

Re: Has any work 3.3 kvm-kmod for rhel 6.2 kernel successfully?

[Jan Kiszka]

On 2012-04-16 14:23, ya su wrote:
> kvm-kmod 3.3 patch attached.
> 
> I also change kernel to export __get_user_pages_fast.

Ugh, that's huge. How did you select which feature to enable? Based on
compile tests? The risk would then be to miss some bits that are
additionally required. Or did you step through the git commits to
identify corresponding parts?

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: Has any work 3.3 kvm-kmod for rhel 6.2 kernel successfully?

[ya su]

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

I first notice 3.3 release notes, it says it can compile against
2.6.32-40, so I think it can work with 2.6.32,  then I change it with
rhel 2.6.32 kernel.

I just re-change orginal kvm-kmod 3.3 with rhel 2.6.32, only to change
compile redefination errors, but the problem remains the same. the
patch attached.

I don't go through git commits, as so many changes from 2.6.32 to 3.3 in kernel.

I think the problem may come from  memory change notification.

2012/4/16, Jan Kiszka <jan.kiszka@siemens.com>:
> On 2012-04-16 14:23, ya su wrote:
>> kvm-kmod 3.3 patch attached.
>>
>> I also change kernel to export __get_user_pages_fast.
>
> Ugh, that's huge. How did you select which feature to enable? Based on
> compile tests? The risk would then be to miss some bits that are
> additionally required. Or did you step through the git commits to
> identify corresponding parts?
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT T DE IT 1
> Corporate Competence Center Embedded Linux
>

[-- Attachment #2: kvm-kmod-min.patch --]
[-- Type: application/octet-stream, Size: 3664 bytes --]

diff -ur -i /root/src/kvm-kmod-3.3/external-module-compat-comm.h kvm-kmod-3.3/external-module-compat-comm.h
--- /root/src/kvm-kmod-3.3/external-module-compat-comm.h	2012-03-20 06:00:42.000000000 +0800
+++ kvm-kmod-3.3/external-module-compat-comm.h	2012-04-16 22:00:59.815810075 +0800
@@ -718,7 +718,8 @@
 #endif
 }
 
-#if defined(CONFIG_PCI) && LINUX_VERSION_CODE < KERNEL_VERSION(2,6,33) && \
+#if 0 
+defined(CONFIG_PCI) && LINUX_VERSION_CODE < KERNEL_VERSION(2,6,33) && \
     (!defined(CONFIG_SUSE_KERNEL) || LINUX_VERSION_CODE < KERNEL_VERSION(2,6,32))
 #include <linux/pci.h>
 static inline struct pci_dev *
@@ -743,7 +744,7 @@
 
 #endif
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,35)
+#if 0 //LINUX_VERSION_CODE < KERNEL_VERSION(2,6,35)
 struct perf_guest_info_callbacks {
 	int (*is_in_guest) (void);
 	int (*is_user_mode) (void);
@@ -901,7 +902,8 @@
 #define __rcu
 #endif
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,37) && \
+#if 0 
+LINUX_VERSION_CODE < KERNEL_VERSION(2,6,37) && \
     (!defined(CONFIG_FEDORA_KERNEL) || \
      (LINUX_VERSION_CODE == KERNEL_VERSION(2,6,35) && \
       KERNEL_EXTRAVERSION < 11) || \
@@ -932,7 +934,8 @@
 #define kvm_request_threaded_irq	request_threaded_irq
 #endif
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,38)
+#if 0
+LINUX_VERSION_CODE < KERNEL_VERSION(2,6,38)
 #define compound_trans_head(page) compound_head(page)
 
 static inline int PageTransCompound(struct page *page)
@@ -984,7 +987,7 @@
 #define __set_bit_le	ext2_set_bit
 #endif
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(3,0,0)
+#if 0 //LINUX_VERSION_CODE < KERNEL_VERSION(3,0,0)
 static inline void rcu_virt_note_context_switch(int cpu)
 {
 }
@@ -1008,7 +1011,7 @@
 #endif /* >= 3.1 */
 #endif /* CONFIG_COMPAT */
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,33)
+#if 0 //LINUX_VERSION_CODE < KERNEL_VERSION(2,6,33)
 
 #ifdef CONFIG_PRINTK
 #define printk_ratelimited(fmt, ...)					\
@@ -1021,7 +1024,7 @@
 		printk(fmt, ##__VA_ARGS__);				\
 })
 #else
-#define printk_ratelimited(fmt, ...)
+//#define printk_ratelimited(fmt, ...)
 #endif
 
 #define pr_err_ratelimited(fmt, ...)					\
diff -ur -i /root/src/kvm-kmod-3.3/x86/external-module-compat.h kvm-kmod-3.3/x86/external-module-compat.h
--- /root/src/kvm-kmod-3.3/x86/external-module-compat.h	2012-03-20 06:00:42.000000000 +0800
+++ kvm-kmod-3.3/x86/external-module-compat.h	2012-04-16 22:01:35.657969473 +0800
@@ -1115,7 +1115,8 @@
 
 #endif /* >= 2.6.36 */
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,37) && \
+#if 0
+LINUX_VERSION_CODE < KERNEL_VERSION(2,6,37) && \
     (LINUX_VERSION_CODE != KERNEL_VERSION(2,6,32) || KERNEL_EXTRAVERSION < 40)
 static inline u64 pvclock_scale_delta(u64 delta, u32 mul_frac, int shift)
 {
@@ -1173,7 +1174,7 @@
 	asm("mov %%" #seg ",%0":"=r" (value) : : "memory")
 #endif
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,35)
+#if 0 //LINUX_VERSION_CODE < KERNEL_VERSION(2,6,35)
 #define static_cpu_has(bit) boot_cpu_has(bit)
 #endif
 
diff -ur -i /root/src/kvm-kmod-3.3/x86/mmu.c kvm-kmod-3.3/x86/mmu.c
--- /root/src/kvm-kmod-3.3/x86/mmu.c	2012-03-20 06:00:56.000000000 +0800
+++ kvm-kmod-3.3/x86/mmu.c	2012-04-16 22:02:46.925967148 +0800
@@ -3939,9 +3939,9 @@
 	kvm_mmu_prepare_zap_page(kvm, page, invalid_list);
 }
 
-#if LINUX_VERSION_CODE >= KERNEL_VERSION(3,0,0)
+#if 0 // LINUX_VERSION_CODE >= KERNEL_VERSION(3,0,0)
 static int mmu_shrink(struct shrinker *shrink, struct shrink_control *sc)
-#elif LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,35)
+#elif 1 //LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,35)
 static int mmu_shrink(struct shrinker *shrink, int nr_to_scan, gfp_t gfp_mask)
 #else
 static int mmu_shrink(int nr_to_scan, gfp_t gfp_mask)

Re: Has any work 3.3 kvm-kmod for rhel 6.2 kernel successfully?

[Jan Kiszka]

On 2012-04-16 16:34, ya su wrote:
> I first notice 3.3 release notes, it says it can compile against
> 2.6.32-40, so I think it can work with 2.6.32,  then I change it with
> rhel 2.6.32 kernel.

The problem is that the RHEL 2.6.32 kernel has nothing to do with a
standard 2.6.32 as too many features were ported back. So the version
number based feature checks fail as you noticed.

We could adapt kvm-kmod to detect that it is a RHEL kernel (there is
surely some define), but it requires going through all the relevant
features carefully.

> 
> I just re-change orginal kvm-kmod 3.3 with rhel 2.6.32, only to change
> compile redefination errors, but the problem remains the same. the
> patch attached.
> 
> I don't go through git commits, as so many changes from 2.6.32 to 3.3 in kernel.
> 
> I think the problem may come from  memory change notification.

The approach to resolve this could be to identify backported features
based on the build breakage or runtime anomalies, then analyze the
kvm-kmod history for changes that wrapped those features, and finally
adjust all affected code blocks. I'm open for patches and willing to
support you on questions, but I can't work on this myself.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: Has any work 3.3 kvm-kmod for rhel 6.2 kernel successfully?

[ya su]

Jan:

    sorry for late response of your suggestion.

    I have found the patch which produce this problem, it comes from
this one: 7850ac5420803996e2960d15b924021f28e0dffc.

    I change as the following, it works fine.

diff -ur -i kvm-kmod-3.4/x86/kvm_main.c kvm-kmod-3.4-fix/x86/kvm_main.c
--- kvm-kmod-3.4/x86/kvm_main.c 2012-05-21 23:43:02.000000000 +0800
+++ kvm-kmod-3.4-fix/x86/kvm_main.c     2012-06-05 12:19:37.780136969 +0800
@@ -1525,8 +1525,8 @@
        if (memslot && memslot->dirty_bitmap) {
                unsigned long rel_gfn = gfn - memslot->base_gfn;

-               if (!test_and_set_bit_le(rel_gfn, memslot->dirty_bitmap))
-                       memslot->nr_dirty_pages++;
+               __set_bit_le(rel_gfn, memslot->dirty_bitmap);
+               memslot->nr_dirty_pages++;
        }
 }

~

    I think the root cause maybe: the acton of clear dirty_bitmap
don't sync with that of set nr_dirty_pages=0.

    but I don't realize why it works fine in new kernel.

Regards.

Suya.


2012/4/16 Jan Kiszka <jan.kiszka@siemens.com>:
> On 2012-04-16 16:34, ya su wrote:
>> I first notice 3.3 release notes, it says it can compile against
>> 2.6.32-40, so I think it can work with 2.6.32,  then I change it with
>> rhel 2.6.32 kernel.
>
> The problem is that the RHEL 2.6.32 kernel has nothing to do with a
> standard 2.6.32 as too many features were ported back. So the version
> number based feature checks fail as you noticed.
>
> We could adapt kvm-kmod to detect that it is a RHEL kernel (there is
> surely some define), but it requires going through all the relevant
> features carefully.
>
>>
>> I just re-change orginal kvm-kmod 3.3 with rhel 2.6.32, only to change
>> compile redefination errors, but the problem remains the same. the
>> patch attached.
>>
>> I don't go through git commits, as so many changes from 2.6.32 to 3.3 in kernel.
>>
>> I think the problem may come from  memory change notification.
>
> The approach to resolve this could be to identify backported features
> based on the build breakage or runtime anomalies, then analyze the
> kvm-kmod history for changes that wrapped those features, and finally
> adjust all affected code blocks. I'm open for patches and willing to
> support you on questions, but I can't work on this myself.
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT T DE IT 1
> Corporate Competence Center Embedded Linux

Re: Has any work 3.3 kvm-kmod for rhel 6.2 kernel successfully?

[Jan Kiszka]

On 2012-06-05 06:22, ya su wrote:
> Jan:
> 
>     sorry for late response of your suggestion.
> 
>     I have found the patch which produce this problem, it comes from
> this one: 7850ac5420803996e2960d15b924021f28e0dffc.
> 
>     I change as the following, it works fine.
> 
> diff -ur -i kvm-kmod-3.4/x86/kvm_main.c kvm-kmod-3.4-fix/x86/kvm_main.c
> --- kvm-kmod-3.4/x86/kvm_main.c 2012-05-21 23:43:02.000000000 +0800
> +++ kvm-kmod-3.4-fix/x86/kvm_main.c     2012-06-05 12:19:37.780136969 +0800
> @@ -1525,8 +1525,8 @@
>         if (memslot && memslot->dirty_bitmap) {
>                 unsigned long rel_gfn = gfn - memslot->base_gfn;
> 
> -               if (!test_and_set_bit_le(rel_gfn, memslot->dirty_bitmap))
> -                       memslot->nr_dirty_pages++;
> +               __set_bit_le(rel_gfn, memslot->dirty_bitmap);
> +               memslot->nr_dirty_pages++;
>         }
>  }
> 
> ~
> 
>     I think the root cause maybe: the acton of clear dirty_bitmap
> don't sync with that of set nr_dirty_pages=0.
> 
>     but I don't realize why it works fine in new kernel.

Takuya, any idea why this change could make a difference when running
3.4 kvm code on an older host kernel?

Jan

> 
> Regards.
> 
> Suya.
> 
> 
> 2012/4/16 Jan Kiszka <jan.kiszka@siemens.com>:
>> On 2012-04-16 16:34, ya su wrote:
>>> I first notice 3.3 release notes, it says it can compile against
>>> 2.6.32-40, so I think it can work with 2.6.32,  then I change it with
>>> rhel 2.6.32 kernel.
>>
>> The problem is that the RHEL 2.6.32 kernel has nothing to do with a
>> standard 2.6.32 as too many features were ported back. So the version
>> number based feature checks fail as you noticed.
>>
>> We could adapt kvm-kmod to detect that it is a RHEL kernel (there is
>> surely some define), but it requires going through all the relevant
>> features carefully.
>>
>>>
>>> I just re-change orginal kvm-kmod 3.3 with rhel 2.6.32, only to change
>>> compile redefination errors, but the problem remains the same. the
>>> patch attached.
>>>
>>> I don't go through git commits, as so many changes from 2.6.32 to 3.3 in kernel.
>>>
>>> I think the problem may come from  memory change notification.
>>
>> The approach to resolve this could be to identify backported features
>> based on the build breakage or runtime anomalies, then analyze the
>> kvm-kmod history for changes that wrapped those features, and finally
>> adjust all affected code blocks. I'm open for patches and willing to
>> support you on questions, but I can't work on this myself.
>>
>> Jan
>>
>> --
>> Siemens AG, Corporate Technology, CT T DE IT 1
>> Corporate Competence Center Embedded Linux

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: Has any work 3.3 kvm-kmod for rhel 6.2 kernel successfully?

[Takuya Yoshikawa]

On Tue, 05 Jun 2012 10:40:15 +0200
Jan Kiszka <jan.kiszka@siemens.com> wrote:

> > diff -ur -i kvm-kmod-3.4/x86/kvm_main.c kvm-kmod-3.4-fix/x86/kvm_main.c
> > --- kvm-kmod-3.4/x86/kvm_main.c 2012-05-21 23:43:02.000000000 +0800
> > +++ kvm-kmod-3.4-fix/x86/kvm_main.c     2012-06-05 12:19:37.780136969 +0800
> > @@ -1525,8 +1525,8 @@
> >         if (memslot && memslot->dirty_bitmap) {
> >                 unsigned long rel_gfn = gfn - memslot->base_gfn;
> > 
> > -               if (!test_and_set_bit_le(rel_gfn, memslot->dirty_bitmap))
> > -                       memslot->nr_dirty_pages++;
> > +               __set_bit_le(rel_gfn, memslot->dirty_bitmap);
> > +               memslot->nr_dirty_pages++;
> >         }
> >  }
> > 
> > ~
> > 
> >     I think the root cause maybe: the acton of clear dirty_bitmap
> > don't sync with that of set nr_dirty_pages=0.

memslot->nr_dirty_pages should become 0 when dirty_bitmap is updated
by the SRCU-update.

Actually this number was used just for optimizing get_dirty's write
protection and did not need to be correct: if we could know !0, that's
enough.

> >     but I don't realize why it works fine in new kernel.
> 
> Takuya, any idea why this change could make a difference when running
> 3.4 kvm code on an older host kernel?

Assuming that the new little endian bitops functions are properly defined,
the only dirty logging problem I can think of is a rmap_write_protect race
bug which was recently fixed in 3.4 stable tree.

By the change above, memslot->nr_dirty_pages might be incremented more
than necessary, which would make get_dirty select the old write protection
method -- kvm_mmu_slot_remove_write_access() -- which was safe from the bug.

But I don't think this was the cause of the problem.

Thanks,
	Takuya