From: Alexander Graf <agraf@suse.de>
To: kvm-ia64@vger.kernel.org
Subject: Re: [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic: moving dirty bitmaps
Date: Tue, 11 May 2010 15:55:38 +0000 [thread overview]
Message-ID: <4BE97DFA.1060408@suse.de> (raw)
In-Reply-To: <20100504215645.6448af8f.takuya.yoshikawa@gmail.com>
Takuya Yoshikawa wrote:
> Hi, sorry for sending from my personal account.
> The following series are all from me:
>
> From: Takuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp>
>
> The 3rd version of "moving dirty bitmaps to user space".
>
> From this version, we add x86 and ppc and asm-generic people to CC lists.
>
>
> [To KVM people]
>
> Sorry for being late to reply your comments.
>
> Avi,
> - I've wrote an answer to your question in patch 5/12: drivers/vhost/vhost.c .
>
> - I've considered to change the set_bit_user_non_atomic to an inline function,
> but did not change because the other helpers in the uaccess.h are written as
> macros. Anyway, I hope that x86 people will give us appropriate suggestions
> about this.
>
> - I thought that documenting about making bitmaps 64-bit aligned will be
> written when we add an API to register user-allocated bitmaps. So probably
> in the next series.
>
> Avi, Alex,
> - Could you check the ia64 and ppc parts, please? I tried to keep the logical
> changes as small as possible.
>
> I personally tried to build these with cross compilers. For ia64, I could check
> build success with my patch series. But book3s, even without my patch series,
> it failed with the following errors:
>
> arch/powerpc/kvm/book3s_paired_singles.c: In function 'kvmppc_emulate_paired_single':
> arch/powerpc/kvm/book3s_paired_singles.c:1289: error: the frame size of 2288 bytes is larger than 2048 bytes
> make[1]: *** [arch/powerpc/kvm/book3s_paired_singles.o] Error 1
> make: *** [arch/powerpc/kvm] Error 2
>
This is bad. I haven't encountered that one at all so far, but I guess
my compiler version is different from yours. Sigh.
>
> About changelog: there are two main changes from the 2nd version:
> 1. I changed the treatment of clean slots (see patch 1/12).
> This was already applied today, thanks!
> 2. I changed the switch API. (see patch 11/12).
>
> To show this API's advantage, I also did a test (see the end of this mail).
>
>
> [To x86 people]
>
> Hi, Thomas, Ingo, Peter,
>
> Please review the patches 4,5/12. Because this is the first experience for
> me to send patches to x86, please tell me if this lacks anything.
>
>
> [To ppc people]
>
> Hi, Benjamin, Paul, Alex,
>
> Please see the patches 6,7/12. I first say sorry for that I've not tested these
> yet. In that sense, these may not be in the quality for precise reviews. But I
> will be happy if you would give me any comments.
>
> Alex, could you help me? Though I have a plan to get PPC box in the future,
> currently I cannot test these.
>
Could you please point me to a git tree where everything's readily
applied? That would make testing a lot easier.
Alex
WARNING: multiple messages have this Message-ID (diff)
From: Alexander Graf <agraf@suse.de>
To: Takuya Yoshikawa <takuya.yoshikawa@gmail.com>
Cc: avi@redhat.com, mtosatti@redhat.com,
yoshikawa.takuya@oss.ntt.co.jp, fernando@oss.ntt.co.jp,
kvm@vger.kernel.org, kvm-ppc@vger.kernel.org,
kvm-ia64@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com,
hpa@zytor.com, x86@kernel.org, benh@kernel.crashing.org,
paulus@samba.org, linuxppc-dev@ozlabs.org, arnd@arndb.de,
linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic: moving dirty bitmaps
Date: Tue, 11 May 2010 15:55:38 +0000 [thread overview]
Message-ID: <4BE97DFA.1060408@suse.de> (raw)
In-Reply-To: <20100504215645.6448af8f.takuya.yoshikawa@gmail.com>
Takuya Yoshikawa wrote:
> Hi, sorry for sending from my personal account.
> The following series are all from me:
>
> From: Takuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp>
>
> The 3rd version of "moving dirty bitmaps to user space".
>
> From this version, we add x86 and ppc and asm-generic people to CC lists.
>
>
> [To KVM people]
>
> Sorry for being late to reply your comments.
>
> Avi,
> - I've wrote an answer to your question in patch 5/12: drivers/vhost/vhost.c .
>
> - I've considered to change the set_bit_user_non_atomic to an inline function,
> but did not change because the other helpers in the uaccess.h are written as
> macros. Anyway, I hope that x86 people will give us appropriate suggestions
> about this.
>
> - I thought that documenting about making bitmaps 64-bit aligned will be
> written when we add an API to register user-allocated bitmaps. So probably
> in the next series.
>
> Avi, Alex,
> - Could you check the ia64 and ppc parts, please? I tried to keep the logical
> changes as small as possible.
>
> I personally tried to build these with cross compilers. For ia64, I could check
> build success with my patch series. But book3s, even without my patch series,
> it failed with the following errors:
>
> arch/powerpc/kvm/book3s_paired_singles.c: In function 'kvmppc_emulate_paired_single':
> arch/powerpc/kvm/book3s_paired_singles.c:1289: error: the frame size of 2288 bytes is larger than 2048 bytes
> make[1]: *** [arch/powerpc/kvm/book3s_paired_singles.o] Error 1
> make: *** [arch/powerpc/kvm] Error 2
>
This is bad. I haven't encountered that one at all so far, but I guess
my compiler version is different from yours. Sigh.
>
> About changelog: there are two main changes from the 2nd version:
> 1. I changed the treatment of clean slots (see patch 1/12).
> This was already applied today, thanks!
> 2. I changed the switch API. (see patch 11/12).
>
> To show this API's advantage, I also did a test (see the end of this mail).
>
>
> [To x86 people]
>
> Hi, Thomas, Ingo, Peter,
>
> Please review the patches 4,5/12. Because this is the first experience for
> me to send patches to x86, please tell me if this lacks anything.
>
>
> [To ppc people]
>
> Hi, Benjamin, Paul, Alex,
>
> Please see the patches 6,7/12. I first say sorry for that I've not tested these
> yet. In that sense, these may not be in the quality for precise reviews. But I
> will be happy if you would give me any comments.
>
> Alex, could you help me? Though I have a plan to get PPC box in the future,
> currently I cannot test these.
>
Could you please point me to a git tree where everything's readily
applied? That would make testing a lot easier.
Alex
WARNING: multiple messages have this Message-ID (diff)
From: Alexander Graf <agraf@suse.de>
To: Takuya Yoshikawa <takuya.yoshikawa@gmail.com>
Cc: avi@redhat.com, mtosatti@redhat.com,
yoshikawa.takuya@oss.ntt.co.jp, fernando@oss.ntt.co.jp,
kvm@vger.kernel.org, kvm-ppc@vger.kernel.org,
kvm-ia64@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com,
hpa@zytor.com, x86@kernel.org, benh@kernel.crashing.org,
paulus@samba.org, linuxppc-dev@ozlabs.org, arnd@arndb.de,
linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic: moving dirty bitmaps to user space
Date: Tue, 11 May 2010 17:55:38 +0200 [thread overview]
Message-ID: <4BE97DFA.1060408@suse.de> (raw)
In-Reply-To: <20100504215645.6448af8f.takuya.yoshikawa@gmail.com>
Takuya Yoshikawa wrote:
> Hi, sorry for sending from my personal account.
> The following series are all from me:
>
> From: Takuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp>
>
> The 3rd version of "moving dirty bitmaps to user space".
>
> From this version, we add x86 and ppc and asm-generic people to CC lists.
>
>
> [To KVM people]
>
> Sorry for being late to reply your comments.
>
> Avi,
> - I've wrote an answer to your question in patch 5/12: drivers/vhost/vhost.c .
>
> - I've considered to change the set_bit_user_non_atomic to an inline function,
> but did not change because the other helpers in the uaccess.h are written as
> macros. Anyway, I hope that x86 people will give us appropriate suggestions
> about this.
>
> - I thought that documenting about making bitmaps 64-bit aligned will be
> written when we add an API to register user-allocated bitmaps. So probably
> in the next series.
>
> Avi, Alex,
> - Could you check the ia64 and ppc parts, please? I tried to keep the logical
> changes as small as possible.
>
> I personally tried to build these with cross compilers. For ia64, I could check
> build success with my patch series. But book3s, even without my patch series,
> it failed with the following errors:
>
> arch/powerpc/kvm/book3s_paired_singles.c: In function 'kvmppc_emulate_paired_single':
> arch/powerpc/kvm/book3s_paired_singles.c:1289: error: the frame size of 2288 bytes is larger than 2048 bytes
> make[1]: *** [arch/powerpc/kvm/book3s_paired_singles.o] Error 1
> make: *** [arch/powerpc/kvm] Error 2
>
This is bad. I haven't encountered that one at all so far, but I guess
my compiler version is different from yours. Sigh.
>
> About changelog: there are two main changes from the 2nd version:
> 1. I changed the treatment of clean slots (see patch 1/12).
> This was already applied today, thanks!
> 2. I changed the switch API. (see patch 11/12).
>
> To show this API's advantage, I also did a test (see the end of this mail).
>
>
> [To x86 people]
>
> Hi, Thomas, Ingo, Peter,
>
> Please review the patches 4,5/12. Because this is the first experience for
> me to send patches to x86, please tell me if this lacks anything.
>
>
> [To ppc people]
>
> Hi, Benjamin, Paul, Alex,
>
> Please see the patches 6,7/12. I first say sorry for that I've not tested these
> yet. In that sense, these may not be in the quality for precise reviews. But I
> will be happy if you would give me any comments.
>
> Alex, could you help me? Though I have a plan to get PPC box in the future,
> currently I cannot test these.
>
Could you please point me to a git tree where everything's readily
applied? That would make testing a lot easier.
Alex
WARNING: multiple messages have this Message-ID (diff)
From: Alexander Graf <agraf@suse.de>
To: Takuya Yoshikawa <takuya.yoshikawa@gmail.com>
Cc: linux-arch@vger.kernel.org, x86@kernel.org, arnd@arndb.de,
kvm@vger.kernel.org, kvm-ia64@vger.kernel.org,
fernando@oss.ntt.co.jp, mtosatti@redhat.com,
linux-kernel@vger.kernel.org, kvm-ppc@vger.kernel.org,
yoshikawa.takuya@oss.ntt.co.jp, linuxppc-dev@ozlabs.org,
mingo@redhat.com, paulus@samba.org, avi@redhat.com,
hpa@zytor.com, tglx@linutronix.de
Subject: Re: [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic: moving dirty bitmaps to user space
Date: Tue, 11 May 2010 17:55:38 +0200 [thread overview]
Message-ID: <4BE97DFA.1060408@suse.de> (raw)
In-Reply-To: <20100504215645.6448af8f.takuya.yoshikawa@gmail.com>
Takuya Yoshikawa wrote:
> Hi, sorry for sending from my personal account.
> The following series are all from me:
>
> From: Takuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp>
>
> The 3rd version of "moving dirty bitmaps to user space".
>
> From this version, we add x86 and ppc and asm-generic people to CC lists.
>
>
> [To KVM people]
>
> Sorry for being late to reply your comments.
>
> Avi,
> - I've wrote an answer to your question in patch 5/12: drivers/vhost/vhost.c .
>
> - I've considered to change the set_bit_user_non_atomic to an inline function,
> but did not change because the other helpers in the uaccess.h are written as
> macros. Anyway, I hope that x86 people will give us appropriate suggestions
> about this.
>
> - I thought that documenting about making bitmaps 64-bit aligned will be
> written when we add an API to register user-allocated bitmaps. So probably
> in the next series.
>
> Avi, Alex,
> - Could you check the ia64 and ppc parts, please? I tried to keep the logical
> changes as small as possible.
>
> I personally tried to build these with cross compilers. For ia64, I could check
> build success with my patch series. But book3s, even without my patch series,
> it failed with the following errors:
>
> arch/powerpc/kvm/book3s_paired_singles.c: In function 'kvmppc_emulate_paired_single':
> arch/powerpc/kvm/book3s_paired_singles.c:1289: error: the frame size of 2288 bytes is larger than 2048 bytes
> make[1]: *** [arch/powerpc/kvm/book3s_paired_singles.o] Error 1
> make: *** [arch/powerpc/kvm] Error 2
>
This is bad. I haven't encountered that one at all so far, but I guess
my compiler version is different from yours. Sigh.
>
> About changelog: there are two main changes from the 2nd version:
> 1. I changed the treatment of clean slots (see patch 1/12).
> This was already applied today, thanks!
> 2. I changed the switch API. (see patch 11/12).
>
> To show this API's advantage, I also did a test (see the end of this mail).
>
>
> [To x86 people]
>
> Hi, Thomas, Ingo, Peter,
>
> Please review the patches 4,5/12. Because this is the first experience for
> me to send patches to x86, please tell me if this lacks anything.
>
>
> [To ppc people]
>
> Hi, Benjamin, Paul, Alex,
>
> Please see the patches 6,7/12. I first say sorry for that I've not tested these
> yet. In that sense, these may not be in the quality for precise reviews. But I
> will be happy if you would give me any comments.
>
> Alex, could you help me? Though I have a plan to get PPC box in the future,
> currently I cannot test these.
>
Could you please point me to a git tree where everything's readily
applied? That would make testing a lot easier.
Alex
next prev parent reply other threads:[~2010-05-11 15:55 UTC|newest]
Thread overview: 175+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-04 12:56 [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic: moving dirty bitmaps Takuya Yoshikawa
2010-05-04 12:56 ` [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic: moving dirty bitmaps to user space Takuya Yoshikawa
2010-05-04 12:56 ` Takuya Yoshikawa
2010-05-04 12:56 ` Takuya Yoshikawa
2010-05-04 12:56 ` Takuya Yoshikawa
2010-05-04 12:56 ` Takuya Yoshikawa
2010-05-04 12:56 ` [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic: moving dirty bitmaps Takuya Yoshikawa
2010-05-10 12:06 ` Avi Kivity
2010-05-10 12:06 ` [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic: moving dirty bitmaps to user space Avi Kivity
2010-05-10 12:06 ` Avi Kivity
2010-05-10 12:06 ` [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic: moving dirty bitmaps Avi Kivity
2010-05-10 12:26 ` Takuya Yoshikawa
2010-05-10 12:26 ` [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic: moving dirty bitmaps to user space Takuya Yoshikawa
2010-05-10 12:26 ` Takuya Yoshikawa
2010-05-10 12:26 ` [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic: moving dirty bitmaps Takuya Yoshikawa
2010-05-11 10:11 ` Takuya Yoshikawa
2010-05-11 10:11 ` [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic: moving dirty bitmaps to user space Takuya Yoshikawa
2010-05-11 10:11 ` Takuya Yoshikawa
2010-05-11 10:11 ` [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic: moving dirty bitmaps Takuya Yoshikawa
2010-05-11 15:55 ` Alexander Graf [this message]
2010-05-11 15:55 ` [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic: moving dirty bitmaps to user space Alexander Graf
2010-05-11 15:55 ` Alexander Graf
2010-05-11 15:55 ` [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic: moving dirty bitmaps Alexander Graf
2010-05-12 9:19 ` Takuya Yoshikawa
2010-05-12 9:19 ` [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic: moving dirty bitmaps to user space Takuya Yoshikawa
2010-05-12 9:19 ` Takuya Yoshikawa
2010-05-12 9:19 ` [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic: moving dirty bitmaps Takuya Yoshikawa
2010-05-13 11:47 ` Avi Kivity
2010-05-13 11:47 ` [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic: moving dirty bitmaps to user space Avi Kivity
2010-05-13 11:47 ` Avi Kivity
2010-05-13 11:47 ` [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic: moving dirty bitmaps Avi Kivity
2010-05-17 9:06 ` Takuya Yoshikawa
2010-05-17 9:06 ` [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic: moving dirty bitmaps to user space Takuya Yoshikawa
2010-05-17 9:06 ` Takuya Yoshikawa
2010-05-17 9:06 ` [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic: moving dirty bitmaps Takuya Yoshikawa
-- strict thread matches above, loose matches on Subject: below --
2010-05-04 12:58 [RFC][PATCH 1/12 applied today] KVM: x86: avoid unnecessary bitmap Takuya Yoshikawa
2010-05-04 12:58 ` [RFC][PATCH 1/12 applied today] KVM: x86: avoid unnecessary bitmap allocation when memslot is clean Takuya Yoshikawa
2010-05-04 12:58 ` Takuya Yoshikawa
2010-05-04 12:58 ` [RFC][PATCH 1/12 applied today] KVM: x86: avoid unnecessary bitmap Takuya Yoshikawa
2010-05-04 13:00 [RFC][PATCH 2/12] KVM: introduce slot level dirty state management Takuya Yoshikawa
2010-05-04 13:00 ` Takuya Yoshikawa
2010-05-04 13:00 ` Takuya Yoshikawa
2010-05-04 13:00 ` Takuya Yoshikawa
2010-05-04 13:00 ` Takuya Yoshikawa
2010-05-04 13:01 [RFC][PATCH 3/12] KVM: introduce wrapper functions to create and Takuya Yoshikawa
2010-05-04 13:01 ` [RFC][PATCH 3/12] KVM: introduce wrapper functions to create and destroy dirty bitmaps Takuya Yoshikawa
2010-05-04 13:01 ` Takuya Yoshikawa
2010-05-04 13:01 ` Takuya Yoshikawa
2010-05-04 13:01 ` [RFC][PATCH 3/12] KVM: introduce wrapper functions to create and Takuya Yoshikawa
2010-05-04 13:02 [RFC][PATCH 4/12] x86: introduce copy_in_user() for 32-bit Takuya Yoshikawa
2010-05-04 13:02 ` Takuya Yoshikawa
2010-05-04 13:02 ` Takuya Yoshikawa
2010-05-04 13:02 ` Takuya Yoshikawa
2010-05-04 13:02 [RFC][PATCH 5/12] x86: introduce __set_bit() like function for Takuya Yoshikawa
2010-05-04 13:02 ` [RFC][PATCH 5/12] x86: introduce __set_bit() like function for bitmaps in user space Takuya Yoshikawa
2010-05-04 13:02 ` Takuya Yoshikawa
2010-05-04 13:02 ` [RFC][PATCH 5/12] x86: introduce __set_bit() like function for Takuya Yoshikawa
2010-05-04 13:03 [RFC][PATCH 6/12 not tested yet] PPC: introduce copy_in_user() for Takuya Yoshikawa
2010-05-04 13:03 ` [RFC][PATCH 6/12 not tested yet] PPC: introduce copy_in_user() for 32-bit Takuya Yoshikawa
2010-05-04 13:03 ` Takuya Yoshikawa
2010-05-04 13:03 ` [RFC][PATCH 6/12 not tested yet] PPC: introduce copy_in_user() for Takuya Yoshikawa
2010-05-04 13:04 [RFC][PATCH 7/12 not tested yet] PPC: introduce __set_bit() like Takuya Yoshikawa
2010-05-04 13:04 ` [RFC][PATCH 7/12 not tested yet] PPC: introduce __set_bit() like function for bitmaps in user space Takuya Yoshikawa
2010-05-04 13:04 ` Takuya Yoshikawa
2010-05-04 13:04 ` Takuya Yoshikawa
2010-05-04 13:04 ` [RFC][PATCH 7/12 not tested yet] PPC: introduce __set_bit() like Takuya Yoshikawa
2010-05-11 16:00 ` Alexander Graf
2010-05-11 16:00 ` [RFC][PATCH 7/12 not tested yet] PPC: introduce __set_bit() like function for bitmaps in user space Alexander Graf
2010-05-11 16:00 ` Alexander Graf
2010-05-11 16:00 ` Alexander Graf
2010-05-11 16:00 ` [RFC][PATCH 7/12 not tested yet] PPC: introduce __set_bit() like Alexander Graf
2010-05-12 9:25 ` Takuya Yoshikawa
2010-05-12 9:25 ` [RFC][PATCH 7/12 not tested yet] PPC: introduce __set_bit() like function for bitmaps in user space Takuya Yoshikawa
2010-05-12 9:25 ` Takuya Yoshikawa
2010-05-12 9:25 ` [RFC][PATCH 7/12 not tested yet] PPC: introduce __set_bit() like Takuya Yoshikawa
2010-05-04 13:05 [RFC][PATCH resend 8/12] asm-generic: bitops: introduce le bit Takuya Yoshikawa
2010-05-04 13:05 ` [RFC][PATCH resend 8/12] asm-generic: bitops: introduce le bit offset macro Takuya Yoshikawa
2010-05-04 13:05 ` Takuya Yoshikawa
2010-05-04 13:05 ` [RFC][PATCH resend 8/12] asm-generic: bitops: introduce le bit Takuya Yoshikawa
2010-05-04 15:03 ` [RFC][PATCH resend 8/12] asm-generic: bitops: introduce le bit offset macro Arnd Bergmann
2010-05-04 15:03 ` Arnd Bergmann
2010-05-04 15:03 ` Arnd Bergmann
2010-05-04 15:03 ` Arnd Bergmann
2010-05-04 16:08 ` [RFC][PATCH resend 8/12] asm-generic: bitops: introduce le bit Avi Kivity
2010-05-04 16:08 ` [RFC][PATCH resend 8/12] asm-generic: bitops: introduce le bit offset macro Avi Kivity
2010-05-04 16:08 ` Avi Kivity
2010-05-04 16:08 ` [RFC][PATCH resend 8/12] asm-generic: bitops: introduce le bit Avi Kivity
2010-05-05 2:59 ` Takuya Yoshikawa
2010-05-05 2:59 ` [RFC][PATCH resend 8/12] asm-generic: bitops: introduce le bit offset macro Takuya Yoshikawa
2010-05-05 2:59 ` Takuya Yoshikawa
2010-05-05 2:59 ` Takuya Yoshikawa
2010-05-05 2:59 ` [RFC][PATCH resend 8/12] asm-generic: bitops: introduce le bit Takuya Yoshikawa
2010-05-06 13:38 ` [RFC][PATCH resend 8/12] asm-generic: bitops: introduce le bit offset macro Arnd Bergmann
2010-05-06 13:38 ` Arnd Bergmann
2010-05-06 13:38 ` Arnd Bergmann
2010-05-06 13:38 ` Arnd Bergmann
2010-05-06 13:38 ` Arnd Bergmann
2010-05-10 11:46 ` [RFC][PATCH resend 8/12] asm-generic: bitops: introduce le bit Takuya Yoshikawa
2010-05-10 11:46 ` [RFC][PATCH resend 8/12] asm-generic: bitops: introduce le bit offset macro Takuya Yoshikawa
2010-05-10 11:46 ` Takuya Yoshikawa
2010-05-10 11:46 ` Takuya Yoshikawa
2010-05-10 11:46 ` [RFC][PATCH resend 8/12] asm-generic: bitops: introduce le bit Takuya Yoshikawa
2010-05-10 12:01 ` Avi Kivity
2010-05-10 12:01 ` [RFC][PATCH resend 8/12] asm-generic: bitops: introduce le bit offset macro Avi Kivity
2010-05-10 12:01 ` Avi Kivity
2010-05-10 12:01 ` [RFC][PATCH resend 8/12] asm-generic: bitops: introduce le bit Avi Kivity
2010-05-10 12:01 ` [RFC][PATCH resend 8/12] asm-generic: bitops: introduce le bit offset macro Arnd Bergmann
2010-05-10 12:01 ` Arnd Bergmann
2010-05-10 12:01 ` Arnd Bergmann
2010-05-10 12:01 ` Arnd Bergmann
2010-05-10 12:01 ` Arnd Bergmann
2010-05-10 12:09 ` [RFC][PATCH resend 8/12] asm-generic: bitops: introduce le bit Takuya Yoshikawa
2010-05-10 12:09 ` [RFC][PATCH resend 8/12] asm-generic: bitops: introduce le bit offset macro Takuya Yoshikawa
2010-05-10 12:09 ` Takuya Yoshikawa
2010-05-10 12:09 ` Takuya Yoshikawa
2010-05-10 12:09 ` [RFC][PATCH resend 8/12] asm-generic: bitops: introduce le bit Takuya Yoshikawa
2010-05-04 13:06 [RFC][PATCH 9/12] KVM: introduce a wrapper function of Takuya Yoshikawa
2010-05-04 13:06 ` [RFC][PATCH 9/12] KVM: introduce a wrapper function of set_bit_user_non_atomic() Takuya Yoshikawa
2010-05-04 13:06 ` Takuya Yoshikawa
2010-05-04 13:06 ` Takuya Yoshikawa
2010-05-04 13:06 ` [RFC][PATCH 9/12] KVM: introduce a wrapper function of Takuya Yoshikawa
2010-05-04 13:07 [RFC][PATCH RFC 10/12] KVM: move dirty bitmaps to user space Takuya Yoshikawa
2010-05-04 13:07 ` Takuya Yoshikawa
2010-05-04 13:07 ` Takuya Yoshikawa
2010-05-04 13:07 ` Takuya Yoshikawa
2010-05-11 3:28 ` Marcelo Tosatti
2010-05-11 3:28 ` Marcelo Tosatti
2010-05-11 3:28 ` Marcelo Tosatti
2010-05-11 3:28 ` Marcelo Tosatti
2010-05-11 3:28 ` Marcelo Tosatti
2010-05-12 6:27 ` Takuya Yoshikawa
2010-05-12 6:27 ` Takuya Yoshikawa
2010-05-12 6:27 ` Takuya Yoshikawa
2010-05-12 6:27 ` Takuya Yoshikawa
2010-05-13 11:05 ` Takuya Yoshikawa
2010-05-13 11:05 ` Takuya Yoshikawa
2010-05-13 11:05 ` Takuya Yoshikawa
2010-05-04 13:08 [RFC][PATCH 11/12] KVM: introduce new API for getting/switching Takuya Yoshikawa
2010-05-04 13:08 ` [RFC][PATCH 11/12] KVM: introduce new API for getting/switching dirty bitmaps Takuya Yoshikawa
2010-05-04 13:08 ` Takuya Yoshikawa
2010-05-04 13:08 ` [RFC][PATCH 11/12] KVM: introduce new API for getting/switching Takuya Yoshikawa
2010-05-11 3:43 ` Marcelo Tosatti
2010-05-11 3:43 ` [RFC][PATCH 11/12] KVM: introduce new API for getting/switching dirty bitmaps Marcelo Tosatti
2010-05-11 3:43 ` Marcelo Tosatti
2010-05-11 3:43 ` Marcelo Tosatti
2010-05-11 3:43 ` [RFC][PATCH 11/12] KVM: introduce new API for getting/switching Marcelo Tosatti
2010-05-11 5:53 ` Takuya Yoshikawa
2010-05-11 5:53 ` [RFC][PATCH 11/12] KVM: introduce new API for getting/switching dirty bitmaps Takuya Yoshikawa
2010-05-11 5:53 ` Takuya Yoshikawa
2010-05-11 5:53 ` [RFC][PATCH 11/12] KVM: introduce new API for getting/switching Takuya Yoshikawa
2010-05-11 14:07 ` Marcelo Tosatti
2010-05-11 14:07 ` [RFC][PATCH 11/12] KVM: introduce new API for getting/switching dirty bitmaps Marcelo Tosatti
2010-05-11 14:07 ` Marcelo Tosatti
2010-05-11 14:07 ` Marcelo Tosatti
2010-05-11 14:07 ` [RFC][PATCH 11/12] KVM: introduce new API for getting/switching Marcelo Tosatti
2010-05-12 5:59 ` Takuya Yoshikawa
2010-05-12 6:03 ` [RFC][PATCH 11/12] KVM: introduce new API for getting/switching dirty bitmaps Takuya Yoshikawa
2010-05-12 6:03 ` Takuya Yoshikawa
2010-05-12 6:03 ` [RFC][PATCH 11/12] KVM: introduce new API for getting/switching Takuya Yoshikawa
2010-05-04 13:11 [RFC][PATCH 12/12 sample] qemu-kvm: use new API for Takuya Yoshikawa
2010-05-04 13:11 ` [RFC][PATCH 12/12 sample] qemu-kvm: use new API for getting/switching dirty bitmaps Takuya Yoshikawa
2010-05-04 13:11 ` Takuya Yoshikawa
2010-05-04 13:11 ` [RFC][PATCH 12/12 sample] qemu-kvm: use new API for Takuya Yoshikawa
2010-05-24 7:05 Any comments? Re: [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic: moving Takuya Yoshikawa
2010-05-24 7:05 ` Any comments? Re: [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic: moving dirty bitmaps to user space Takuya Yoshikawa
2010-05-24 7:05 ` Any comments? Re: [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic: moving Takuya Yoshikawa
2010-06-01 10:55 ` Any comments? Re: [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic: Marcelo Tosatti
2010-06-01 10:55 ` Any comments? Re: [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic: moving dirty bitmaps to user space Marcelo Tosatti
2010-06-01 10:55 ` Any comments? Re: [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic: Marcelo Tosatti
2010-06-01 12:05 ` Takuya Yoshikawa
2010-06-01 12:05 ` Any comments? Re: [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic: moving dirty bitmaps to user space Takuya Yoshikawa
2010-06-01 12:05 ` Any comments? Re: [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic: Takuya Yoshikawa
2010-06-01 12:54 ` Marcelo Tosatti
2010-06-01 12:54 ` Any comments? Re: [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic: moving dirty bitmaps to user space Marcelo Tosatti
2010-06-01 12:54 ` Any comments? Re: [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic: Marcelo Tosatti
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=4BE97DFA.1060408@suse.de \
--to=agraf@suse.de \
--cc=kvm-ia64@vger.kernel.org \
/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.