qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Gerd Hoffmann
Subject: Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out
Date: Tue, 07 Aug 2012 16:07:33 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.5) Gecko/20120601 Thunderbird/10.0.5

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.

> The only thing
> its missing is to fix the endianess for server/client handshaking.

What exactly do you mean here?

> We a
> patch for that. We can send that later on.

Patches welcome.  Please make sure spice-devel is included (additionally
to qemu-devel).

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

The QXLCommand passed on to spice-server (via get_command callback) is
supposed to be little endian.  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 ...

> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]