On 07/30/2012 04:45 PM, Anthony Liguori wrote: > Avi Kivity <a...@redhat.com> writes: > >> On 07/30/2012 04:18 PM, Anthony Liguori wrote: >>> Avi Kivity <a...@redhat.com> 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