On Wed, Aug 8, 2012 at 3:18 AM, Gerd Hoffmann <kra...@redhat.com> wrote:
> Hi,
>
>>>> The only thing
>>>> its missing is to fix the endianess for server/client handshaking.
>>>
>>> What exactly do you mean here?
>>
>> Well that are negotiation messages configuring each channel, its
>> capabilities, encryption keys , etc. After this negotiation, the
>> server start to send SPICE data, which are already swapped by the
>> marshallers.
>
> Ah, so the initial handshake isn't covered by the generated marshallers.
>
>>>> We have tested it first running
>>>> spice sever tests in a PPC machine and then we run it in an experimental
>>>> virtio-qxl driver we are working on.
>>>
>>> Huh? How does this work?
>>
>> Well, our first though was to minimize changes on xf86-video-qxl.
>> [ ... ]
>
> Keep in mind that the linux world is moving to kms & drm. A virtual
> hardware design trying to minimize the changes to todays userland X
> driver may turn out to be not be the best pick long-term. We also must
> make sure it works for both linux and windows guests. I suggest to
> discuss the virtual hardware design @ qemu-devel and spice-devel.
>
>>> The QXLCommand passed on to spice-server (via get_command callback) is
>>> supposed to be little endian.
>>
>> Actually the command endianness doesn't matter at this point once
>> QXLCommand will be marshalled (and then swapped) before get to the
>> wire.
>
> Well, the flow of a command from the guest to the spice client looks
> like this:
>
> (1) guest places the command into memory (QXLCommand, little endian)
> and queues it up (qxl uses its own ring format, but using virtio
> rings doesn't make a difference).
> (2) qemu takes the QXLCommand and passes it as-is to the spice-server.
> (3) spice-server parses and sanity-checks the command, also
> translates QXLCommand into internal representation (struct
> {Red,Spice}*), see server/red_parse_qxl.c. It should also
> translate from little endian to native endian but doesn't yet.
> (4) spice-server can process the commands (in native byte order)
> locally in case the rendered screen is needed. Happens for
> example if you ask for a screenshot via qemu monitor.
> (5) The generated marshaller code translates the command into wire
> format (and swaps again from native to little endian if needed).
> (6) The generated demarshaller code (in the client) translates back
> from the wire format to the internal representation (in native
> endian).
> (7) spice client renders the result.
>
> /me wonders how this works for you with step #3 not byteswapping on
> bigendian hosts.
> Maybe the guest driver places the qxl commands in native endian instead
> of big endian into memory?
The guest drivers places the commands in the memory in its native
endianess. That why the device only works when guest/host has the same
endianess. That's sanit-checks doesn't fails.
Regards,
Erlon
>
> cheers,
> Gerd
