From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexey Kardashevskiy Subject: Re: [PATCH] KVM: PPC: Book3S HV: return htab entries in big endian Date: Sat, 04 Oct 2014 13:42:25 +1000 Message-ID: <542F6CA1.9000200@ozlabs.ru> References: <1412269080-18510-1-git-send-email-clg@fr.ibm.com> <542D8620.2060503@suse.de> <20141003120507.GA10764@iris.ozlabs.ibm.com> <0A654AAC-070B-4B20-BD26-50A055863E64@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Cc: =?KOI8-R?Q?Ce=27dric_Le_Goater?= , "kvm-ppc@vger.kernel.org" , "kvm@vger.kernel.org" To: Alexander Graf , Paul Mackerras Return-path: In-Reply-To: <0A654AAC-070B-4B20-BD26-50A055863E64@suse.de> Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/04/2014 07:05 AM, Alexander Graf wrote: > > > >> Am 03.10.2014 um 14:05 schrieb Paul Mackerras : >> >>> On Thu, Oct 02, 2014 at 07:06:40PM +0200, Alexander Graf wrote: >>> >>> I think we're best off to keep the user space API native endian. >>> So really we should only ever have to convert from big to native >>> endian on read and native to big on write. >>> >>> With that QEMU should do the "right thing" already, no? >> >> I believe that when migrating a guest, QEMU just passes the byte >> stream it gets from the htab fd along to the destination QEMU with >> little or no interpretation, and the destination QEMU writes the >> byte stream to the htab fd for the receiving VM. Alexey would be >> able to say for sure. >> >> If that's the case, then perhaps it's best to define that byte >> stream to contain values of one specific endianness, and for >> compatibility that would be big endian. >> >> I assume we would want to be able to migrate a guest from a BE host >> to an LE host or vice versa. If not then the question is moot. > > Yes, the migration stream needs to stay host endian agnostic, so it > should be BE. Whether QEMU or kvm does the conversion is an > implementation detail I don't mind much for either way. I find it lot easier if every binary interface has defined endianness, using native endian just creates problems. > But keep in mind that qemu also uses the htab fd for htab > introspection that it does for gdbstub emulation or the x monitor > command. - -- Alexey -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUL2ygAAoJEIYTPdgrwSC5CcEP/REdOJ6XAqwC4fhUMK9b40FO ef72ggABoHiG5DZkAjwd0iUmGYvRkDHHH8tbC4BEhnxRlN4OkHRzXA7CgXsZfBea DwB9eH7IXOycGBNbFcSDfsnxJLdqU8XP1kFtOzV68YtNoGjV1lPLLJ241hGvmuIQ h+JdD5tRrA2LeV52knxHMQyALYF769fGXCigSsTvY6/VXPoVeNB/tDELzxri/DUM GntqSZJBGXSD1x4Q1oWopy+QefTP586EZz+sKjMRNLi4gIq8/Z0Do9TaMPq+zmH0 TOk6hukfBVmUXC26nv3Yyo0YZSPAprSd7kiy9TmLnfQPOIdO1Rdh6VaSniyWykyr G/NDEXJsl1U5OqiWmyJIJssT3QZgYgsxzicwCpyIHe8R9checwONEDAj5gU9RfiG DJ5WHbGqZ/wQ5G5o/BRYrORX3IfYhQp6sZ2EUXrCNCFBQhnGW9C8RGp2h0P3Ar6J x9PmpgQsemSIwNdsMvIS2h5MoY5iRtq8D3yWiilAKvP8cEmKBhHTvduyjYDlUtgR mylsOy1q2muwVX1+3bIM6d7TWtNhB2ewHjIYMaU5LEmJzBN5waVM0ucBKc5g4DVt BBLhlc0goIGTtjStHrfDAjjZuIwgzre1Ir9QkLDJ2/Tpi2vx3SJpl+9Lp642HmIQ LLbul3RzhfHn4w+CCRl6 =4+hf -----END PGP SIGNATURE-----