From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Blake Subject: Re: [PATCH for-1.4 04/12] kvm: Create kvm_arch_vcpu_id() function Date: Mon, 21 Jan 2013 07:35:22 -0700 Message-ID: <50FD522A.2090706@redhat.com> 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> <50F98A87.40307@redhat.com> <50FD3F25.1060504@suse.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----enig2XWCENSTKGGJXLXPGXRLO" Cc: Eduardo Habkost , Gleb Natapov , qemu-devel@nongnu.org, Anthony Liguori , "kvm@vger.kernel.org list" , Igor Mammedov To: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= Return-path: In-Reply-To: <50FD3F25.1060504@suse.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2XWCENSTKGGJXLXPGXRLO Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01/21/2013 06:14 AM, Andreas F=C3=A4rber wrote: >> 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 > So ... do we have a conclusion what to put into the commit message? :) >=20 > It looks to me as if kvm-all.c:kvm_vm_ioctl() is using void*. I like > unsigned long but maybe uintptr_t would be more correct then? uintptr_t feels more correct - the 3rd (vararg) argument through the ioctl() syscall is always retrieved using the same size as void*. >=20 > Or should kvm_vm_ioctl() be fixed to use something else instead? > Eric's int would be a semantic change for the 64-bit platforms, no? My discussion about 'int' vs. 'unsigned long' was in regards to the second argument KVM_CREATE_VCPU, which your patch does not change (perhaps my fault for jumping in on a conversation mid-thread without actually reading your original patch, which I have now done). That is, KVM_CREATE_VCPU as a constant is always 32 bits (kernel constraint), widened out to unsigned long when passed to the glibc function (due to the glibc signature disagreeing with POSIX), then narrowed back down to 32 bits when forwarded to the kernel syscall. Meanwhile, your patch is fixing the third argument from 'int' to a wider type, which is necessary for passing that value through varargs when the receiving end will retrieve the same argument via a void* variable. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org ------enig2XWCENSTKGGJXLXPGXRLO 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/VIqAAoJEKeha0olJ0Nqk7cIAIekmM0QKhoTD8gC3w8Q5bPA 4gg1zHd5KzNawYAwN48qALauOa8nqrKU772108snHMz18+k2j6y/zqecAApEk9vY TXHHeryh0rhuaoIttf6uJmMe5HQEKN1ujeXprOHerwQknc1iy1h5QmRRItkp7BUh NHxdJol+J1Vap4TOnPYNfXQIPn2P4bZtJqSQ8qUXsUJvKF9XcU9ZQmqeFncMkGvQ KH6HyLGhVsvJUW/at66Q+2D/E/lcJdnwV/t7SnteP7+lI9BthbfmQXtuY6Cv4YNo bsiGM3Z2NqOsrzus7ZqWeN93xkf8olQYdIJl6uwaHo+eym5n+SnanNNTn0T0gpM= =6WTy -----END PGP SIGNATURE----- ------enig2XWCENSTKGGJXLXPGXRLO--