From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51073) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TwG1l-0007EB-1q for qemu-devel@nongnu.org; Fri, 18 Jan 2013 12:46:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TwG1i-0000a0-Kc for qemu-devel@nongnu.org; Fri, 18 Jan 2013 12:46:52 -0500 Received: from mx1.redhat.com ([209.132.183.28]:18798) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TwG1i-0000Zs-Ck for qemu-devel@nongnu.org; Fri, 18 Jan 2013 12:46:50 -0500 Message-ID: <50F98A87.40307@redhat.com> Date: Fri, 18 Jan 2013 10:46:47 -0700 From: Eric Blake MIME-Version: 1.0 References: <1358456378-29248-1-git-send-email-ehabkost@redhat.com> <1358456378-29248-5-git-send-email-ehabkost@redhat.com> <50F92DE1.7040107@suse.de> <20130118125340.GV10683@otherpad.lan.raisama.net> <50F9480D.3040400@suse.de> <20130118142013.GX10683@otherpad.lan.raisama.net> <50F9743E.2080601@redhat.com> <20130118164002.GN20133@otherpad.lan.raisama.net> In-Reply-To: <20130118164002.GN20133@otherpad.lan.raisama.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----enig2HIKKTQAPNWVAHJUVUHHE" Subject: Re: [Qemu-devel] [PATCH for-1.4 04/12] kvm: Create kvm_arch_vcpu_id() function List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: Gleb Natapov , "kvm@vger.kernel.org list" , qemu-devel@nongnu.org, Anthony Liguori , Igor Mammedov , =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2HIKKTQAPNWVAHJUVUHHE Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01/18/2013 09:40 AM, Eduardo Habkost wrote: > On Fri, Jan 18, 2013 at 09:11:42AM -0700, Eric Blake wrote: >> On 01/18/2013 07:20 AM, Eduardo Habkost wrote: >>>> Could you suggest a text for me to add please? >>> >>> "The argument passed to KVM_CREATE_VCPU now has 'unsigned long' type >>> instead of 'int', as expected by the Linux ioctl() syscall. Maybe an = int >>> works on most or all architectures supporting KVM, but it is safer to= >>> use an appropriate 'unsigned long' parameter." >> >> Interestingly enough, while the Linux syscall uses 'unsigned long', th= e >> POSIX definition of ioctl() uses 'int'; so the Linux kernel is already= >> constrained to never use an ioctl value that doesn't fit within 'int',= >=20 > Really? What about the ioctl()s that get a pointer as argument on > architectures where pointers don't fit in an int? >=20 > Do you have a pointer to the POSIX definition you are talking about? >=20 > Note that I'm talking about the the extra ioctl() argument, not the > ioctl() number (that is an unsigned int in the kernel code). Okay, now you made me go back and check sources. POSIX 2008 says: #include int ioctl(int fildes, int request, ... /* arg */); Gnulib says this about a bug that it works around: @item On glibc platforms, the second parameter is of type @code{unsigned long} rather than @code{int}. But gnulib also suggests using instead of the POSIX header for getting ioctl(), because was declared obsolete in POSIX 2008 and was never implemented in glibc. Sure enough, looking at Fedora 18 /usr/include/sys/ioctl.h, I still see: extern int ioctl (int __fd, unsigned long int __request, ...) __THROW; Meanwhile, you are correct that the kernel defines request as 32 bits: linux.git:include/uapi/asm-generic/ioctl.h /* ioctl command encoding: 32 bits total, command in lower 16 bits, * size of the parameter structure in the lower 14 bits of the * upper 16 bits. * Encoding the size of the parameter structure in the ioctl request * is useful for catching programs compiled with old versions * and to avoid overwriting user space outside the user buffer area. * The highest 2 bits are reserved for indicating the ``access mode''. * NOTE: This limits the max parameter size to 16kB -1 ! */ >=20 >> and glibc is already responsible for ensuring that argument promotion = of >> an int doesn't change the behavior of ioctl() in libc when converting = it >> over to the unsigned long syscall semantics expected by the kernel. So a more precise wording of this is: glibc is already responsible from converting the 'unsigned long int' of the user declaration back into the 'unsigned int' that the kernel expects for the second argument. The third argument (when present), is generally treated as a pointer (of size appropriate for the architecture). Although there _might_ be an ioctl that uses it directly as an integer instead of dereferencing it as a pointer, those would be the exceptions to the rule. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org ------enig2HIKKTQAPNWVAHJUVUHHE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJQ+YqHAAoJEKeha0olJ0NqzXEH/idEf6FMsdh8LKFXHh8XYkO8 2WSL+dNsW6tKX4I5CN79yTbj373a0yU2JVUsLsKxkbmPVWhOAAMF0fEjAOC4Blqs 8rsVw+9LF40jweYb+alLYnD3T1N4UscFggyayoDMJO45FMv/YqMfqTe2cxnmV4yg UWWwmx9qJxaxursK+0/kQF9OpPXMpHbzxaHHi+fbcCu0ENrH+XWDNtEpVe219wX/ aP3E9LKDgww8R3S6mvee4YWIoESSSB4VAR8C5CbmIpDM1o0O7AfRj0ek4ftQpcLh 5TzOemzqR1iunO4/Rl5rHTCfbRX7RLLA9SJ9k+avdN8x0bmsx5SEJ2/j2D5f8wk= =lwmu -----END PGP SIGNATURE----- ------enig2HIKKTQAPNWVAHJUVUHHE--