Hi Juergen,
On 08/05/17 11:17, Juergen Gross wrote:
On 08/05/17 12:07, Ian Jackson wrote:
Juergen Gross writes ("[PATCH 1/3] docs: specify endianess of xenstore protocol
header"):
The endianess of the xenstore protocol header should be specified.
...
-followed by xsd_sockmsg.len bytes of payload.
+followed by xsd_sockmsg.len bytes of payload. The header fields are
+all in little endian byte order.
Yes, but this is not correct. On a big-endian cpu, they would be in
big-endian.
We don't support big-endian cpus, right? Do we want to specify the
protocol for unsupported cpus?
On a bytesexual cpu, the endianness should be specified but it will be
the same endianness as shared ring fields, etc. So this doc probably
ought not to contain a list of endiannesses. Best just to say that
the fields are all in host native byte order.
Hmm, this is problematic. How does a guest started e.g. big-endian on a
cpu capable of both byte orders know which endianess the host has? I
think specifying one endianess in this case is the better approach.
BTW: I'm quite sure we don't support big-endian guests (or host) on ARM
either, do we?
At the moment, Xen is always little endian and all the structure between
Xen and the guests are little-endian.
We don't yet support big-end guests but there are nothing to prevent
that. The only change I am aware of is in the MMIO emulation (see [1]).
All the Xen hypercall argument will stay little-endian and the guest
would have to take care of passing the arguments with the correct
endianness.
I could reword the paragraph to:
"The header fields are in the default endianess of the processor, e.g.
little endian on x86 and ARM."
Whilst instruction fetches are always little-endian, the memory
endianness of data access does not have a particular default in the ARM
ARM. This is left up to the implementor.
Cheers,
[1]
https://xenbits.xen.org/gitweb/?p=people/julieng/xen-unstable.git;a=commit;h=e49cecef96d57622e9dcbc6199be1f018d405fc0
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
