From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45424) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SvqSD-0006tB-2i for qemu-devel@nongnu.org; Mon, 30 Jul 2012 09:56:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SvqS4-0005GU-9B for qemu-devel@nongnu.org; Mon, 30 Jul 2012 09:56:13 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49801) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SvqS4-0005GH-1Y for qemu-devel@nongnu.org; Mon, 30 Jul 2012 09:56:04 -0400 Message-ID: <5016926E.3090109@redhat.com> Date: Mon, 30 Jul 2012 16:55:58 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1343629462.21647.32.camel@pasglop> <50165D0A.6060608@redhat.com> <1343647217.21647.40.camel@pasglop> <50166F2A.1040507@redhat.com> <1343649267.21647.44.camel@pasglop> <501676D7.3010504@redhat.com> <878ve11j70.fsf@codemonkey.ws> <50168C68.9010103@redhat.com> <874nopicrc.fsf@codemonkey.ws> In-Reply-To: <874nopicrc.fsf@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org On 07/30/2012 04:45 PM, Anthony Liguori wrote: > Avi Kivity writes: > >> On 07/30/2012 04:18 PM, Anthony Liguori wrote: >>> Avi Kivity 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