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