From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: [PATCH] kvm tools, ui: Optimize SDL updates Date: Sat, 4 Jun 2011 12:54:43 +0200 Message-ID: <20110604105443.GH16292@elte.hu> References: <1307136023-16693-1-git-send-email-penberg@kernel.org> <20110604095451.GA15349@elte.hu> <11EB6DEC-41E9-4C0A-A057-7E88EBA2A008@suse.de> <20110604104245.GF16292@elte.hu> <34B8A15A-AEF2-4E2D-99F5-0EDB41447C31@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Pekka Enberg , kvm@vger.kernel.org, Cyrill Gorcunov , John Floren , Sasha Levin To: Alexander Graf Return-path: Received: from mx2.mail.elte.hu ([157.181.151.9]:34741 "EHLO mx2.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755402Ab1FDKyx (ORCPT ); Sat, 4 Jun 2011 06:54:53 -0400 Content-Disposition: inline In-Reply-To: <34B8A15A-AEF2-4E2D-99F5-0EDB41447C31@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: * Alexander Graf wrote: > > On 04.06.2011, at 12:42, Ingo Molnar wrote: > > > > > * Alexander Graf wrote: > > > >> I wrote up 2 virtio-fb implementations a while back and I still > >> believe it's a bad idea. Better implement QXL in kvm-tool, so work > >> doesn't get needlessly duplicated. If you really have to use virtio > >> for whatever reason (no PCI available), just write a small QXL over > >> virtio transport that allows you to reuse the protocol. > >> > >> I really don't want to see people waste time on reinventing the > >> wheel over and over again. > > > > Oh, we are just ignorantly blundering around trying to find a good > > solution! :-) > > > > We are not trying to reimplement the wheel (at all), if you check we > > started with VNC GUI support which is as far from NIH as it gets! :-) > > > > I didn't know about QXL but it looks interesting at first sight: a > > virtual GPU seen by the guest OS with Xorg support for it in the > > guest Xorg. But i do not see guest kernel framebuffer support for it > > - how does that aspect work, if one boots without Xorg, etc.? > > IIUC it implements VESA and just goes through the respective fb. > [...] So, if you look at the context of this dicussion our motivation is slow scrolling and our desire to support smooth scrolling on 64-bit too. It was unclear whether VESA would proper panning/scrolling on 64-bit as well - Pekka thinks that it is not supported there. > [...] I would love to see a QXL fb implementation though. I'd also > love to see QXL working on !PCI, so we can potentially use it on > s390x and ppc-hv which can't easily do MMIO. > > So instead of putting effort into writing virtio-fb host and guest > sides, why not implement QXL-fb against a working target (qemu) and > then implement the QXL host side against a working target (working > guest support)? That probably makes the development process a lot > easier. Have a look at the 'kvm' tool: git pull git://github.com/penberg/linux-kvm master We'd like to implement better graphics support there, in a gradual fashion if possible. Right now we have VNC and SDL support - two rather primitive 2D framebuffer concepts with no acceleration at all. If you think qxl-fb can be done gradually in that context then that's probably the right solution. Is there *any* QXL code in the kernel that would allow us to get started? I really know nothing about QXL. The natural steps for us would be: - add primitive 2D acceleration support: scrolling - check what it would require to get good guest Xorg support. QXL has a full driver on the guest side Xorg server - but how does this get channeled over to the virtualizer - is it a magic PCI device that the host has to provide to the guest and which the guest Xorg server uses as a PCI device? Or does the guest side DRM code know about this GPU and uses it in KMS? Thanks, Ingo