From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IpCsV-0001XJ-1t for qemu-devel@nongnu.org; Mon, 05 Nov 2007 20:05:15 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IpCsT-0001W2-Mg for qemu-devel@nongnu.org; Mon, 05 Nov 2007 20:05:14 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IpCsT-0001Vu-BA for qemu-devel@nongnu.org; Mon, 05 Nov 2007 20:05:13 -0500 Received: from mail.codesourcery.com ([65.74.133.4]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IpCsR-00049R-B2 for qemu-devel@nongnu.org; Mon, 05 Nov 2007 20:05:11 -0500 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 References: <1194110810.13889.25.camel@hephaestion> <200711031752.20135.paul@codesourcery.com> <1194292268.5154.73.camel@phantasm.home.enterpriseandprosperity.com> In-Reply-To: <1194292268.5154.73.camel@phantasm.home.enterpriseandprosperity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200711060105.04529.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org, thayne@c2.net Cc: TJ > 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. > =A0I 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 a= t=20 all, so how can using it be consistent with kernel code? There are two different strategies for accessing user data. Either: =2D Use a copying interface. i.e. get_user (for single values) or =20 copy_from_user (for blocks/structures). =2D Use a locking interface. i.e. lock_user. Personally I like the locking interface as it allows a zero-copy=20 implementation. However the kernel uses a copying interface, and my=20 understanding is that other qemu maintainers also prefer the copying=20 interface. You need to pick one interface (get/put/copy or lock) and stick to it. If=20 get_user actually just does byteswapping of values in host memory then IMHO= =20 it really needs to be renamed (to tswap). Part of the problem may be that linux assumes that both kernel and userspac= e=20 pointers can be represented by the compiler. This allows it to do address=20 arithmetic and take the address of members of pointers to userspace=20 structures. qemu can not do this. qemu also has to deal with endian conversion. The kernel does not. This mea= ns=20 that some data the kernel may be able to copy/pass/access unmodified needs= =20 special treatment in qemu. Paul