Re: [Qemu-devel] [RFC] qemu VGA endian swap low level drawing changes

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Tue, 2014-06-17 at 13:57 +0200, Gerd Hoffmann wrote:

> Ok, it is supposed to work this way:
> 
> The virtual graphics card creates a DisplaySurface, which is a pixman
> image under the hood.  There are basically two ways to do that:
> 
>   (1) Use qemu_create_displaysurface().  Allocates host memory.
>       Returns 32bpp framebuffer in host byte order.  virtual graphics
>       card is supposed to convert the guests framebuffer into that
>       format.
>   (2) Use qemu_create_displaysurface_from().  DisplaySurface (and pixman
>       image) is backed by guest display memory then.  pixman format
>       obviously must match the guests framebuffer format.
> 
> The ui (gtk / sdl / vnc / screendump via monitor) is supposed to deal
> with whatever it gets.  Typically the ui checks whenever it can use the
> format directly, and if not it converts using pixman (see gd_switch in
> ui/gtk.c for example).  vnc and screendump use pixman too.  sdl feeds
> SDL_CreateRGBSurfaceFrom with the shifts of the pixelformat instead.

Allright, I'll play with this, it makes sense to get rid of most of
the conversion functions if we know the surface will always be 32-bit
indeed.

I think we can work step by step:

 - Remove all the non-32bpp targets from vga_template

 - Add the 32-bit target only version of my byteswap

This gives us something that works quickly. We also need to focus on how
to trigger the endian mode etc...

Then we can

 - Look into doing at least some of the conversions in pixman

Which would be a subsequent optimization.

Any objection ? I'll spend some time in the next few days getting myself
a bit more familiar with that pixman stuff (I need to fix the ppc vector
stuff for LE in there anyway) and come up with patches.

Another step I hinted to earlier is how we do the actual endian
transition. My idea is to add a new register to the BOCHS DISPI VBE
list and bump the PCI revision ID to advertise its existence.

Additionally, I wouldn't mind of we did a quick "trick" equivalent (but
cleaner) to what I did in my patch which is when the pseries guest calls
the hypervisor call to change the interrupt endian mode, we notify VGA
and switch its endian mode, so we work "by default" with kernels not
updated to know about that register. But this is open for debate. It's
somewhat "acceptable" in the context of our hypercall being a
"paravirtualized" interface, so it can be argued that the hypercall
poking at the VGA chip is equivalent to some FW doing so :-)

Cheers,
Ben.