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

[Gerd Hoffmann <kraxel@redhat.com>]

  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?

cheers,
  Gerd