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

[Avi Kivity]

On 07/30/2012 04:45 PM, Anthony Liguori wrote:
> 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.

I agree.  Hopefully it won't be difficult to get the guest to unmap, or
maybe we can just unregister the direct RAM mapping in qemu.

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

Yes.

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

I'd assume so too, but we need to make sure the framebuffer is unmapped
when in accelerated mode, or at least the guest has no expectations of
using it.

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

s390 can outwierd anyone and anything.

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

The drm drivers for the current model are needed anyway; so moving to
virtio is extra effort, not an alternative.

Note virtio doesn't support mapping framebuffers yet, or the entire vga
compatibility stuff, so the pc-oriented card will have to be a mix of
virtio and stdvga multiplexed on one pci card (maybe two functions, but
I'd rather avoid that).

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