>On Tue, Aug 7, 2012 at 11:07 AM, Gerd Hoffmann <kra...@redhat.com> wrote:
>
> On 08/07/12 15:05, Erlon Cruz wrote:
> > Em 07/08/2012 05:01, "Gerd Hoffmann" <kra...@redhat.com> 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
