Avi Kivity wrote:
On 04/12/2010 05:29 AM, Takuya Yoshikawa wrote:
TODO:
1. We want to use copy_in_user() for 32bit case too.
Definitely. Why doesn't it work now?
Sadly we don't have that for 32bit. We have to implement by ourselves.
I tested two temporary implementations for 32bit:
1. Thi
On 04/12/2010 11:55 PM, Fernando Luis Vazquez Cao wrote:
Sadly we don't have that for 32bit. We have to implement by ourselves.
I tested two temporary implementations for 32bit:
1. This version using copy_from_user() and copy_to_user() with
not nice vmalloc().
2. Loop with __get_user()
On 04/12/2010 05:29 AM, Takuya Yoshikawa wrote:
TODO:
1. We want to use copy_in_user() for 32bit case too.
Definitely. Why doesn't it work now?
Sadly we don't have that for 32bit. We have to implement by ourselves.
I tested two temporary implementations for 32bit:
1. This version using
(2010/04/12 2:21), Avi Kivity wrote:
On 04/09/2010 12:38 PM, Takuya Yoshikawa wrote:
By this patch, bitmap allocation is replaced with do_mmap() and
bitmap manipulation is replaced with *_user() functions.
Note that this does not change the APIs between kernel and user space.
To get more advant
On 04/09/2010 12:38 PM, Takuya Yoshikawa wrote:
By this patch, bitmap allocation is replaced with do_mmap() and
bitmap manipulation is replaced with *_user() functions.
Note that this does not change the APIs between kernel and user space.
To get more advantage from this hack, we need to add a n
By this patch, bitmap allocation is replaced with do_mmap() and
bitmap manipulation is replaced with *_user() functions.
Note that this does not change the APIs between kernel and user space.
To get more advantage from this hack, we need to add a new interface
for triggering the bitmap swith and g
