From: Alexey Kardashevskiy <aik@ozlabs.ru>
To: Alexander Graf <agraf@suse.de>, Paul Mackerras <paulus@samba.org>
Cc: "Ce'dric Le Goater" <clg@fr.ibm.com>,
"kvm-ppc@vger.kernel.org" <kvm-ppc@vger.kernel.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: [PATCH] KVM: PPC: Book3S HV: return htab entries in big endian
Date: Sat, 04 Oct 2014 03:42:25 +0000 [thread overview]
Message-ID: <542F6CA1.9000200@ozlabs.ru> (raw)
In-Reply-To: <0A654AAC-070B-4B20-BD26-50A055863E64@suse.de>
-----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@samba.org>:
>>
>>> 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-----
WARNING: multiple messages have this Message-ID (diff)
From: Alexey Kardashevskiy <aik@ozlabs.ru>
To: Alexander Graf <agraf@suse.de>, Paul Mackerras <paulus@samba.org>
Cc: "Ce'dric Le Goater" <clg@fr.ibm.com>,
"kvm-ppc@vger.kernel.org" <kvm-ppc@vger.kernel.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: [PATCH] KVM: PPC: Book3S HV: return htab entries in big endian
Date: Sat, 04 Oct 2014 13:42:25 +1000 [thread overview]
Message-ID: <542F6CA1.9000200@ozlabs.ru> (raw)
In-Reply-To: <0A654AAC-070B-4B20-BD26-50A055863E64@suse.de>
-----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@samba.org>:
>>
>>> 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-----
next prev parent reply other threads:[~2014-10-04 3:42 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-02 16:58 [PATCH] KVM: PPC: Book3S HV: return htab entries in big endian Cédric Le Goater
2014-10-02 16:58 ` Cédric Le Goater
2014-10-02 17:06 ` Alexander Graf
2014-10-02 17:06 ` Alexander Graf
2014-10-03 12:05 ` Paul Mackerras
2014-10-03 12:05 ` Paul Mackerras
2014-10-03 21:05 ` Alexander Graf
2014-10-03 21:05 ` Alexander Graf
2014-10-04 3:42 ` Alexey Kardashevskiy [this message]
2014-10-04 3:42 ` Alexey Kardashevskiy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=542F6CA1.9000200@ozlabs.ru \
--to=aik@ozlabs.ru \
--cc=agraf@suse.de \
--cc=clg@fr.ibm.com \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=paulus@samba.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.