Re: [Xen-devel] Graphics in domU's

[Mogens Valentin <mogensv@xxxxxxxxxxxxxxxx>]

M.A. Williamson wrote:
> > What's the status about domU graphics these days?
>
> Anthony Liguori has written a virtual framebuffer driver that can be 
> used to access the guest VTs, etc. This is not in-tree yet but looks 
> promising. It should export to dom0's X server or directly to VNC with 
> decent efficiency, and offer the possibility of running a 2D X server on 
> top. Fully virtualised guests also get a virtual video card device, 
> which provides a similar effect. The idea is that eventually 
> fully-virtualised and paravirtualised guests will be accessible in a 
> similar manner.
> Jacob Gorm Hansen is working on actually passing 3D operations 
> efficiently from a guest to dom0, allowing good 3D performance from a 
> guest virtual display. There is working code for this, although it's not 
> complete and I'm not sure if a patch is available.
> It should also be possible to dedicate an entire card / display to a 
> domU using the PCI passthrough feature. There are usually some 
> configuration hiccups when trying to get this to work, but in principle 
> it's quite possible to have a graphics card for each graphics-capable 
> domain. This should give full-speed graphics to the guest.
Yes, I've seen those interesting ideas discussed in devel/users. 
Especially interesting since PCI-passthru is back in 3.x .
In terms of HW, a bit expensive perhaps, but with todays PCIe systems 
quite goos performance should be obtainable. I could live well with good 
performance in two domUs/systems, each with their own (~$100) cards, and 
so-so perfomance for the rest, based on virtual framebuffer or whatever 
- given that such a scenario /will/ work.
> For most users, the solution is "just use network-based graphics". You 
> should be able to do most things you need using X-protocol, VNC, or NX.
> > I'm aware that hypervisor-aware drivers are needed, and none has been 
> > written so far, mainly because proprietary vendors hasn't deemed it 
> > worth the while as yet (nVidia has opened an RFE, but AFAIK not opened 
> > it as a workload),
>
> IIRC, this is just a "make the driver work properly in dom0" request, 
> rather than anything more sophisticated.
It was my understanding it would be a far more elaborate process.
If not, I fail to understand why nVidia hasn't revealed any work in 
progress, preprietary or not. It's been half a year or so since Lonni (I 
think) answered on nvnews that he would be happy to open the RFE.
> > perhaps because they don't see Xen as interesting on the desktop, or 
> > feels that HW accelerated virtualization, permitting unmodified 
> > clients, isn't there yet.
> > I know work is in progress WRT  GLX, any word on that?
> >
> > Considering traditional drivers, the opensource opencrome.org driver 
> > should support 3D acceleration for VIA/S3 Unichrome cards.
> > Wouldn't that one be a good candidate for an Xen-adapted driver?
>
> The trouble is that you don't want to emulate a complete hardware 
> graphics device to the guest, because graphics cards are complicated. 
I'm aware of that.. I was thinking that VIA/S3 cards are less complex 
than nVidia/ATI, and already having a fully working OSS driver...
> Jacob's and Anthony's drivers skip emulating the device completely: 
> graphics subsystem talks pretty much directly to dom0, which then 
> displays stuff using the hardware it controls.
> I've heard rumours that there's work going on to build graphics cards 
> that can be directly accessed by multiple virtual machines. For 
> instance, IIRC, MS and NVidia have admitted to talking about it. If this 
> hardware ever comes to light, things will be somewhat simpler: give 
> 3D-capable domains direct access to a virtualisation-aware graphics card 
> and tell the card which bits of the screen to let them render to.
Yes, I've read about that too. It'll go hand in hand with future effords 
to virtualize the whole platform; kind of a second step after the cpu.
--
Kind regards,
Mogens Valentin


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel