[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] RFC: x86_64 Best way to fix 'cast to pointer from integ
From: |
Paul Brook |
Subject: |
Re: [Qemu-devel] RFC: x86_64 Best way to fix 'cast to pointer from integer of different size' problems? |
Date: |
Tue, 6 Nov 2007 01:05:03 +0000 |
User-agent: |
KMail/1.9.7 |
> 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
- [Qemu-devel] RFC: x86_64 Best way to fix 'cast to pointer from integer of different size' problems?, TJ, 2007/11/03
- Re: [Qemu-devel] RFC: x86_64 Best way to fix 'cast to pointer from integer of different size' problems?, Paul Brook, 2007/11/03
- Re: [Qemu-devel] RFC: x86_64 Best way to fix 'cast to pointer from integer of different size' problems?, Thayne Harbaugh, 2007/11/05
- Re: [Qemu-devel] RFC: x86_64 Best way to fix 'cast to pointer from integer of different size' problems?,
Paul Brook <=
- Re: [Qemu-devel] RFC: x86_64 Best way to fix 'cast to pointer from integer of different size' problems?, Thayne Harbaugh, 2007/11/05
- Re: [Qemu-devel] RFC: x86_64 Best way to fix 'cast to pointer from integer of different size' problems?, Fabrice Bellard, 2007/11/07
- Re: [Qemu-devel] RFC: x86_64 Best way to fix 'cast to pointer from integer of different size' problems?, Thayne Harbaugh, 2007/11/07
- Re: [Qemu-devel] RFC: x86_64 Best way to fix 'cast to pointer from integer of different size' problems?, Paul Brook, 2007/11/07
- Re: [Qemu-devel] RFC: x86_64 Best way to fix 'cast to pointer from integer of different size' problems?, Thayne Harbaugh, 2007/11/12
- Re: [Qemu-devel] RFC: x86_64 Best way to fix 'cast to pointer from integer of different size' problems?, Fabrice Bellard, 2007/11/06
- Re: [Qemu-devel] RFC: x86_64 Best way to fix 'cast to pointer from integer of different size' problems?, Stuart Anderson, 2007/11/06
- Re: [Qemu-devel] RFC: x86_64 Best way to fix 'cast to pointer from integer of different size' problems?, Paul Brook, 2007/11/06
- Re: [Qemu-devel] RFC: x86_64 Best way to fix 'cast to pointer from integer of different size' problems?, Stuart Anderson, 2007/11/06