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

[Anthony Liguori]

Avi Kivity <address@hidden> writes:

> On 07/30/2012 04:18 PM, Anthony Liguori wrote:
>> Avi Kivity <address@hidden> writes:
>> 
>>> On 07/30/2012 02:54 PM, Benjamin Herrenschmidt wrote:
>>>>> 
>>>>> > 
>>>>> > We can also make the fbdev/fbcon driver do the swapping in SW, but it's
>>>>> > a relatively unusual code path and I don't think it works properly with
>>>>> > X, I don't think it can be made to work properly with the generic X KMS
>>>>> > at this point.
>>>>> > 
>>>>> > Now, cirrusdrmfb is already specific to the qemu cirrus variant in
>>>>> > several ways, I wouldn't mind keeping it that way and if we "fix" the
>>>>> > endianness model, maybe having a "hidden" register to flip it back to
>>>>> > it's current mode of operation that cirrusdrmfb would use...
>>>>> 
>>>>> That's possible, but why not go all the way to qxl?
>>>>>
>>>>> That will give you better graphics performance with no need to hack.
>>>> 
>>>> Well, qxl is pretty awful from what I can see so far. I'm more tempted
>>>> to continue improving qemu-vga, adding a virtio transport, and maybe
>>>> adding a way to tunnel spice into it if that makes sense but so far,
>>>> that's stuff was designed for Windows as far as I can tell and is pretty
>>>> horrible whatever way you look at it...
>>>
>>> Let's balkanize some more then?
>> 
>> Minor improvements to stdvga actual help qxl (presumably).  qxl still
>> provides a vga interface which is used when guest drivers aren't
>> available.
>
> The premise is that guest drivers will be used, otherwise you may as
> well stay with stdvga.

The trouble is predicting which guests have drivers and which guests
don't.  Having a VGA model that could be enabled universally with good
VBE support for guests without drivers would be a very nice default
model.

We've never made the switch because WinXP doesn't have VESA support
natively.  But we're slowly getting to the point in time where it's
acceptable to require a special command line option for running WinXP
guests such that we could consider changing the default machine type.

>> It's not clear to me why it doesn't enable VBE but presumably if it did,
>> then accelerations could be mapped through VBE.
>
> I believe the idea is that you don't want to map the framebuffer into
> the guest, this allows one-directional communication so you can defer
> rendering to the client and not suffer from the latency.  But I may be
> mixing things up.

Hrm, that seems like an odd strategy for legacy VGA.  Spice isn't
remoting every pixel update, right?  I would assume it's using the same
logic as the rest of the VGA cards and doing bulk updates based on the
refresh timer.  In that case, exposing the framebuffer shouldn't matter
at all.

>>> No, qxl is our paravirt vga, we should improve it instead of spawning
>>> new ones (which will be horrible in the eyes of the next person to look
>>> at them).  You should also be getting the drm driver for free.
>> 
>> Actually, Gerd et al have expressed interest in moving to a virtio-based
>> device model for Spice in the past.
>> 
>> I think done correctly, it could help bring graphics to other platforms
>> like S390 where PCI doesn't exist and will never exist.
>
> I thought the plan was to render into a virtual card punch, then flip
> through the cards at 60 fps?

48.5 fps actually.  In 1960 when the system was designed, there were two
competing frame rates.  Everything else standardized on 60Hz but S390
still uses the old 48.5 refresh rate (and it's obviously superior).

>
> Virtio makes sense for qxl, but for now we have the original pci model
> which I don't see a reason why it can't work for ppc.

I'm sure it can work for PPC given enough effort.  But I think the
question becomes, why not invest that effort in moving qxl to the
standard transport that the rest of our PV devices use.

Regards,

Anthony Liguori

>
> -- 
> error compiling committee.c: too many arguments to function