Re: [Xen-devel] [PATCH 1/3] docs: specify endianess of xenstore protocol header

[Julien Grall <julien.grall@xxxxxxx>]

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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel