From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33420) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zr2pu-0005Nj-Eu for qemu-devel@nongnu.org; Tue, 27 Oct 2015 07:54:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zr2pr-0003d2-8X for qemu-devel@nongnu.org; Tue, 27 Oct 2015 07:54:42 -0400 Received: from mout.kundenserver.de ([212.227.126.131]:57226) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zr2pr-0003cv-22 for qemu-devel@nongnu.org; Tue, 27 Oct 2015 07:54:39 -0400 References: <1444151509-5047-1-git-send-email-laurent@vivier.eu> <562EEAD4.7070706@vivier.eu> <562F564A.5040902@vivier.eu> From: Laurent Vivier Message-ID: <562F65F5.7040106@vivier.eu> Date: Tue, 27 Oct 2015 12:54:29 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH] linux-user: manage SOCK_PACKET socket type. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Riku Voipio , QEMU Developers Le 27/10/2015 12:35, Peter Maydell a écrit : > On 27 October 2015 at 10:47, Laurent Vivier wrote: >> And for the socketcall part, we need the tswap16(): >> >> for instance, >> >> int a = htons(0x0003); >> >> On a LE host: >> >> a = 0x00000300 >> >> On a BE host: >> >> a = 0x00000003 >> >> If the guest is BE, it will put in memory: >> >> 0x00 0x00 0x00 0x03 >> >> Then a LE host, will read: >> >> int b = 0x03000000 >> >> but get_user_ual() in do_socketcall() will byte-swap it and put >> 0x00000003 in a[2]. >> >> so without the byte-swap, we call do_socket(..., 0x0003), >> whereas the syscall is waiting for htons(0x0003) -> 0x0300 as we are on >> LE host. > > So, I thought through this this morning, and I think the swapping > issues here are not specific to socketcall. If the socket syscall > ABI requires an argument of "htons(3)", then this is actually > a *different* ABI for BE vs LE systems. On a BE system this is > asking for "3", but on LE it is asking for "0x300". (Argument > is generally passed in a register.) So we need to be able to tell > when the host kernel wants this sort of difference and fix it up. > > For socketcall, the current swapping we have will correctly pass > the value the user wrote into the array-of-longs into the syscall, > because if the value to be passed is 0x11223344 (assume 32-bit long), > for BE guest LE host we have: > in register 0x11223344 > in memory 0x11 0x22 0x33 0x44 > byteswapped back by get_user_ual: 0x11223344 > and for LE guest LE host: > in register 0x11223344 > in memory 0x44 0x33 0x22 0x11 > read back by get_user_ual: 0x11223344 > But we still have the same issue that if the guest believes the > kernel wants a value of 0x3 but in fact it wants 0x300 we need to > fix things up. > > So the fix needs to go into do_socket(), and it needs to be > specific to the PF*/SOCK* values that indicate socket types > that want a network-order-16-bit value, which I think is > (domain == AF_PACKET || (domain == AF_INET && type == SOCK_PACKET)) OK, I will try with my use case. > > (this is pretty close to what your patch had to start with, > so apologies for taking a while to work through it. Endianness > always confuses me...) No problem, It tooks me 3 years to explain that correctly :) ... > Still thinking about the other part of your patch, because > "does this start with 'eth'" is not very pretty... I agree but I didn't find a better way... Laurent