On 04.06.2011, at 12:54, Ingo Molnar wrote: > > * Alexander Graf <agraf@xxxxxxx> wrote: > >> >> On 04.06.2011, at 12:42, Ingo Molnar wrote: >> >>> >>> * Alexander Graf <agraf@xxxxxxx> 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. Why would you need panning/scrolling for a fast FB? It's really an optimization that helps a lot with VNC, but on local machines or SDL you shouldn't see a major difference. Unless you use the FB as MMIO. Qemu just maps the FB as RAM and checks for dirty bitmap updates periodically. That way you don't constantly exit due to MMIO and are good on speed. The slowness you describe sounds a lot as if you don't do that trick. Also, I'm fairly sure vesafb implements scrolling almost unconditionally. Check for "ypan" in drivers/video/vesafb.c. > >> [...] 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. Well, VNC and SDL are pure front-end concepts. What you plug in on the backend is a different story, no? :) > 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. I don't think there is. CC'ing Gerd for that discussion. He's taking care of all the upstreaming work and community efforts around QXL. > The natural steps for us would be: > > - add primitive 2D acceleration support: scrolling This one could be done with VESA. Xorg won't use it though IIRC. > - 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? It is a PCI device. That's about where my knowledge ends. Gerd had a nice talk about some internals of the actual QXL protocol and PCI device on KVM Forum 2010: http://www.linux-kvm.org/wiki/images/a/aa/2010-forum-spice.pdf http://vimeo.com/15225069 However, it does not mention how the Xorg driver interacts with it, so I simply don't know :). And you're probably not worse on reading code than me to figure it out ;). Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
