Re: [Qemu-devel] RFC: x86_64 Best way to fix 'cast to pointer from integer of different size' problems?

[Paul Brook <paul@codesourcery.com>]

> access_ok() and lock_user() perform essential functions.  lock_user(),
> however, isn't directly comparable to how the kernel operates and should
> therefore be encapsulated inside more typical kernel functions such as
> {get,put}_user(), copy_{to,from}_user() and the like.  access_ok() and
> lock_user() also have overhead and should therefore be used with the
> largest memory hunks possible (e.g.: they should be used with an entire
> structure - not with each individual data member of the structure).
> That is why __{get,put}_user() exist: for copying the individual data
> members of a structure once the *entire* structure has had access
> checked and the address translation is performed.

>   I don't think there's an appropriate way
> to eliminate either {lock,unlock}_user() or {get,put}_user() and keep
> comparable coding semantics to the kernel.

Your argument seems inconsistent to me. The kernel doesn't have lock_user at 
all, so how can using it be consistent with kernel code?

There are two different strategies for accessing user data. Either:

- Use a copying interface. i.e. get_user (for single values) or  
copy_from_user (for blocks/structures).
- Use a locking interface. i.e. lock_user.

Personally I like the locking interface as it allows a zero-copy 
implementation. However the kernel uses a copying interface, and my 
understanding is that other qemu maintainers also prefer the copying 
interface.

You need to pick one interface (get/put/copy or lock) and stick to it. If 
get_user actually just does byteswapping of values in host memory then IMHO 
it really needs to be renamed (to tswap).

Part of the problem may be that linux assumes that both kernel and userspace 
pointers can be represented by the compiler. This allows it to do address 
arithmetic and take the address of members of pointers to userspace 
structures. qemu can not do this.

qemu also has to deal with endian conversion. The kernel does not. This means 
that some data the kernel may be able to copy/pass/access unmodified needs 
special treatment in qemu.

Paul