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.kis...@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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to