[Top][All Lists]
[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: |
Avi Kivity |
Subject: |
Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out |
Date: |
Mon, 30 Jul 2012 16:55:58 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 |
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
- Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out, (continued)
- Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out, Alon Levy, 2012/07/30
- Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out, Anthony Liguori, 2012/07/30
- Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out, Benjamin Herrenschmidt, 2012/07/30
- Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out, Alon Levy, 2012/07/31
- Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out, Anthony Liguori, 2012/07/30
- Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out, Avi Kivity, 2012/07/30
- Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out, Anthony Liguori, 2012/07/30
- Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out,
Avi Kivity <=
- Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out, Anthony Liguori, 2012/07/30
- Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out, Avi Kivity, 2012/07/30
- Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out, Anthony Liguori, 2012/07/30
- Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out, Rusty Russell, 2012/07/30
- Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out, Benjamin Herrenschmidt, 2012/07/30
- Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out, Alon Levy, 2012/07/31
- Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out, Benjamin Herrenschmidt, 2012/07/30
- Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out, Anthony Liguori, 2012/07/30
- Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out, Benjamin Herrenschmidt, 2012/07/30
- Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out, Alon Levy, 2012/07/30