[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-users] Xen handling of graphics card


  • To: "Jean-Eric Cuendet" <jec@xxxxxxxx>, xen-users@xxxxxxxxxxxxxxxxxxx
  • From: "Petersson, Mats" <mats.petersson@xxxxxxx>
  • Date: Thu, 12 Jan 2006 11:21:07 +0100
  • Delivery-date: Thu, 12 Jan 2006 10:28:17 +0000
  • List-id: Xen user discussion <xen-users.lists.xensource.com>
  • Thread-index: AcYXYJZC2+xMkq3bRP2bGrBM8yrlhgAABW6w
  • Thread-topic: [Xen-users] Xen handling of graphics card

 

> -----Original Message-----
> From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Jean-Eric Cuendet
> Sent: 12 January 2006 10:10
> To: xen-users@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-users] Xen handling of graphics card
> 
> 
> > In any form of VT/SVM system, as of right now, the entire system's 
> > hardware accesses are routed to an emulator (qemu for most 
> operations, 
> > internal hypervisor emulator for a few select hardware 
> items, such as 
> > the interrupt controller & timer). So Windows, or any other 
> OS, will 
> > have a QEMU graphics window that displays it's output. So it's a 
> > "faked card bridged by Xen" in your words.
> > 
> > When Xen 3.x re-implements the Dom0 device hiding, you 
> could, at least 
> > in theory, have two graphics cards and use one directly in Windows.
> 
> But would it be possible to tell Xen to "give" the entire 
> card to Windows and then get it back to dom0 and then back to 
> Linux X11 domU and then to Windows domU, etc... ?
> What you explain is that the only way of "sharing" the card 
> between 2 domU OSes is through a QEmu windows so no *Real* 
> full screen neither full Windows acceleration. That means the 
> desktop Linux/Windows in Xen will be hard to do.

This is non-trivial:
1. Windows and Dom0 needs to run in parallel, or the device accesses
that are virtualized on behalf of the DomU would not be performed. So,
you'd be spending more time swapping graphics content than anything else
in the system - ever tried saving away 128 MB of graphics data to
replace it with another 128MB? [And no, you can't just get away with
saving a little bit of the frame buffer memory, unless the driver(s)
involved agree to not use all of the memory]. 

2. It would require a "neat" transition - what if the Windows driver has
sent a complex drawing request to the graphics card and is currently
sitting waiting for an interrupt from the completion of that request,
and at that very moment the Dom0 takes over the card? Who gets that
interrupt?

Obviously, with a Xen-aware graphics driver, it would be possible to
solve both of these problems. It is, however, not entirely trivial to
write such a driver for a decent modern graphics card. Trust me, I used
to work for 3DLabs as a driver developer, the source code for 2D side of
the driver is several megabytes, and the 3D parts of the driver are MUCH
larger than that. And I think an nVidia or ATI driver is even larger -
at least the binary is... 

Xen's primary target is for servers, so high performance graphics isn't
really high priority - this doesn't mean that noone will ever do
graphics drivers specifically to support this stuff, but at the moment
it's not the highest priority.

--
Mats

> -jec
> 
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users
> 
> 


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.