Re: [PATCH RFC v2 6/6] KVM: introduce a new API for getting dirty

[Takuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp>]

(2010/04/20 20:15), Alexander Graf wrote:
>
> On 20.04.2010, at 13:03, Takuya Yoshikawa wrote:
>
>> We can now export the addree of the bitmap created by do_mmap()
>> to user space. For the sake of this, we introduce a new API:
>>
>>   KVM_SWITCH_DIRTY_LOG: application can use this to trigger the
>>   switch of the bitmaps and get the address of the bitmap which
>>   has been used until now. This reduces the copy of the dirty
>>   bitmap from the kernel.
>>
>> Signed-off-by: Takuya Yoshikawa<yoshikawa.takuya@oss.ntt.co.jp>
>> Cc: Fernando Luis Vazquez Cao<fernando@oss.ntt.co.jp>
>> ---
>> Documentation/kvm/api.txt |   23 +++++++++++++++++++++++
>> arch/ia64/kvm/kvm-ia64.c  |   19 ++++++++++++++-----
>> arch/powerpc/kvm/book3s.c |   19 ++++++++++++++-----
>> arch/x86/kvm/x86.c        |   32 ++++++++++++++++++++++++++------
>> include/linux/kvm.h       |    6 ++++--
>> include/linux/kvm_host.h  |    7 ++++---
>> virt/kvm/kvm_main.c       |   41 ++++++++++++++++++++++++++++++++++++-----
>> 7 files changed, 121 insertions(+), 26 deletions(-)
>>
>
> [...]
>
>> diff --git a/include/linux/kvm.h b/include/linux/kvm.h
>> index 23ea022..9fa6f1e 100644
>> --- a/include/linux/kvm.h
>> +++ b/include/linux/kvm.h
>> @@ -12,7 +12,7 @@
>> #include<linux/ioctl.h>
>> #include<asm/kvm.h>
>>
>> -#define KVM_API_VERSION 12
>> +#define KVM_API_VERSION 13
>
> Is there a way to keep both interfaces around for some time at least? I'd prefer the API version not to change if not _really_ necessary.
>
> To enable the new dirty mapping you could for example use KVM_CAP_ENABLE_CAP :-).

Thanks, I did not know what is the appropriate way for this kind of change.

I just read the comments in the kvm.h and thought I had to update the number whenever
I added some entries to kvm.h .


>
>
> Alex
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html