All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: ya su <suya94335@gmail.com>,
	Takuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: Has any work 3.3 kvm-kmod for rhel 6.2 kernel successfully?
Date: Tue, 05 Jun 2012 10:40:15 +0200	[thread overview]
Message-ID: <4FCDC5EF.3070100@siemens.com> (raw)
In-Reply-To: <CA+tHM2FD5v-qHw_5wO5wiZsz0pS1cyt-p7b-9uE0YPAU3tCryA@mail.gmail.com>

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

  reply	other threads:[~2012-06-05  8:40 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-16 10:12 Has any work 3.3 kvm-kmod for rhel 6.2 kernel successfully? ya su
2012-04-16 10:27 ` Nadav Har'El
2012-04-16 11:08 ` Jan Kiszka
2012-04-16 12:23   ` ya su
2012-04-16 13:10     ` Jan Kiszka
2012-04-16 14:34       ` ya su
2012-04-16 14:46         ` Jan Kiszka
2012-06-05  4:22           ` ya su
2012-06-05  8:40             ` Jan Kiszka [this message]
2012-06-05 15:59               ` Takuya Yoshikawa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FCDC5EF.3070100@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=kvm@vger.kernel.org \
    --cc=suya94335@gmail.com \
    --cc=yoshikawa.takuya@oss.ntt.co.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.