Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out

[Erlon Cruz]

On Wed, Aug 8, 2012 at 3:18 AM, Gerd Hoffmann <address@hidden> 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