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

[Erlon Cruz]

>On Tue, Aug 7, 2012 at 11:07 AM, Gerd Hoffmann <address@hidden> wrote:
>
> On 08/07/12 15:05, Erlon Cruz wrote:
> > Em 07/08/2012 05:01, "Gerd Hoffmann" <address@hidden> escreveu:
> >>
> >>   Hi,
> >>
> >>> Why not make libspice mandatory?
> >>
> >> spice needs to build and run on alot of platforms where it doesn't run
> >> today.  So it isn't an option right now.  Which doesn't imply it will
> >> never happen, but spice certainly needs some work before we can
> >> seriously discuss that.
> >>
> >> Make spice work on bigendian is probably the biggest part of it.
> >
> > Spice has a good support for endianess issues. The protocol handles
> > endianess for commands sent from spice server to the client.
>
> The spice wire protocol is little endian.  Functions for
> generating/parsing the wire protocol are generated, maybe the generator
> already supports byteswapping as needed, not sure.

Yes, it does. There are marshellers that are generated based on SPICE
command definitions.

> > 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.

> > We a
> > patch for that. We can send that later on.
>
> Patches welcome.  Please make sure spice-devel is included (additionally
> to qemu-devel).

I've sent then on spice-devel mailing list.

> > 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. The
device allocates the video memory on QEMU and memory on guest (the
same amount). A virtio kernel drivers makes the connection/mapping
between xf86-video-driver and the device. Guest memory then works
mirroring all commands to the device (the X driver tell the kernel
which areas changed and the kernel pushes the pages to the device. we
only need one VQ to to that) and the xf86-driver can work like if does
in the QXL PCI.
'
> 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.

> The qxl parser (server/red_parse_qxl.c in
> spice repo) doesn't support bigendian hosts yet.  Not that a big deal,
> basically just a bunch of le{16,32]_to_cpu() calls when copying
> (+checking) fields from struct QXL* (little endian) to struct Spice*
> (native endian).  But not done yet and likewise not tested yet ...
>
> So I'm wondering how this works for you on ppc ...

Well, I think that once QEMU and libspice are both BE or LE this code
will run. And we only  server/reds.c, server/red_channel.c, and
server/inputs_channel.c check the patches I send in spice-devel.

> > The device only have support for QXL (nor VGA) and works well in x86 and
> > i
> > PPC guest with a few issues we still working on. Another limitation is
> > that
> > in the design we used virtio transport, the device wont work with mixed
> > guest/host configurations (e.g. Guest ppc host x86)
>
> Which should be fixable.
>
> cheers,
>   Gerd

Cheers,
Erlon