Re: [PATCH] kvm tools, ui: Optimize SDL updates

[Ingo Molnar <mingo@elte.hu>]

* Alexander Graf <agraf@suse.de> wrote:

> 
> On 04.06.2011, at 12:42, Ingo Molnar wrote:
> 
> > 
> > * Alexander Graf <agraf@suse.de> 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