-----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 <paulus@xxxxxxxxx>: >> >>> 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----- -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
