Re: [PATCH] some optimizations for Virtual Machines

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Aug 20, 2007 at 03:12:00PM +0200, Renzo Davoli wrote:
> http://www.cs.unibo.it/~renzo/utrace.
> > 2- Access to traced process vm.
> > 
> This patch is very important: with this change VM hypervisors can access
> their process memory efficiently. 
> > 
> > I propose a new call:
> > int utrace_access_process_vm(struct task_struct *tsk, unsigned long addr, char __user *ubuf, int len, int write, int string);

"string" smells like a hack, someone will come up with his favourite
structure and ask for flag for copying, say, single-linked lists. :(

> > which give I-O access to the memory of the process.
> I have seen that access_process_vm has been exported to modules: it is a
> change included in mainstream 2.6.23 from the first rc.
> so I have exported access_process_vm_user too.
> access_process_vm_user has two main differences with
> access_process_vm:
> - it copies a memory area directly from a process vm to the user space
>   of current and viceversa (it uses an internal one page buffer,

check for allocation failure

> it does
> not need extra buffers or extra code loops).
> - it supports the "string" flag for reading: no useless copies of data
>   after the end of string, no memory errors due to short string read
> into large buffers.
> 
> utrace_access_process_vm can be kept or not: modules can call it instead
> of directly accessing access_process_vm_user when they need to check
> that the requesting process has the right to access the other process
> vm.
> > 
> > 3- In the patch I have also implemented the support for PTRACE_MULTI 
> > and PTRACE_SYSVM.

PTRACE_MULTI is horrible, it is asking for pain with compat version.

>                            Several ptrace based application could
> benefit from these features (e.g. when they need to load chunks of
> memory or chunks of registers, burst of ptrace calls could be sent as a
> single call reducing the number of mode switches).

Mode switches are fast. This is a reason why read(2) doesn't have
batched version, and read is called waaay more often than ptrace.

I also wonder if this was tested with list debugging on: iterating over
RCU protected list backwards when prev pointers are poisoned shouldn't
work.


[Index of Archives]     [Kernel Discussion]     [Gimp]     [Yosemite News]

  Powered by Linux