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

From: Julien Grall <julien.grall@arm.com>
To: Juergen Gross <jgross@suse.com>, Ian Jackson <ian.jackson@eu.citrix.com>
Cc: julien.grall@amd.com, sstabellini@kernel.org,
	wei.liu2@citrix.com, George.Dunlap@eu.citrix.com,
	andrew.cooper3@citrix.com, tim@xen.org, jbeulich@suse.com,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH 1/3] docs: specify endianess of xenstore protocol header
Date: Mon, 8 May 2017 11:59:58 +0100	[thread overview]
Message-ID: <a800c721-6c2a-ba44-7cf9-ecc398b58c4b@arm.com> (raw)
In-Reply-To: <2a155db6-0e3f-a66b-1b6a-14067e95f2af@suse.com>

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