[Xen-devel] possible to give/switch direct graphics hw access to doms?

["Jean Blignaut" <jean@xxxxxxxxxxx>]

Why not use suspend resume?
You could simulate say a keyboard sleep button push or some thing to make the 
guest OS  go into sleep mode while switching the full power of you graphichs hw 
over to another OS
(As I recall there is a special mode that the x86 uses for powermanagement 
interrupts etc. why not use an existing system and just expand on it?)

I think that the problem with remote desktop and vnc has is that its all very 
well for run of the mill office apps and server stuff (I'm actually unix 
sysadmin at a small isp so excuse the "stuff" shorthand ;-) ) the real areas 
where what I'm asking would be use full is for powerfull graphics apps and 
games. I don't think you'll find any one happily  working in may/3d studio 
max/photoshop etc. via vnc or remotedesktop 

-----Original Message-----
From: Petersson, Mats [mailto:Mats.Petersson@xxxxxxx] 
Sent: Thursday, May 04, 2006 1:26 PM
To: Jean Blignaut; xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Xen-devel] possible to give/switch direct graphics hw access to 
doms?

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Jean Blignaut
> Sent: 04 May 2006 11:21
> To: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: [Xen-devel] possible to give/switch direct graphics 
> hw access to doms?
> 
> 
> I hope this is the right place to be posting this question.
> 
> I was wondering about the possibility of giving full access 
> to graphics hw to domU perhaps especially when intel VT or 
> AMD pacifica is available?

In short: no.

The problem here isn't so much the ownership of the graphics (that CAN
be dealt with), but the fact that in HVM (Intel VT/AMD SVM) we "lie" to
the DomU about where it's memory is, because most operating systems
assume that memory starts roundabout address zero, and goes up to
whatever number of megabytes - which of course is true for Dom0, but
DomU's won't have that setup, so we fake it to LOOK like it is by using
page-tables that are "adjusted" when the guest sets it's paging up. 

However, the graphics card will have direct memory accessing - which
means that the graphics card will need to be told about the ACTUAL
physical address (not the fake one we told the guest about). 

The solution is an IOMMU device, which is basicly a translation system
to translate a "fake physical" to "actual physical" address. There is a
GART in the AMD x86-64 processors that COULD be used for this purpose,
but currently there's no code to support this [although I believe it's
being worked on]. 

> 
> I have been reading every thing I can find on the subject as 
> it would be most use full for my personal desktop system (and 
> I'm sure I'm not alone ... )

No, this question comes up every few weeks or so, and I'm sure there are
MORE people who actually want it than those that ask about it... 
> 
> To be able to share or in some way switch which OS has access 
> to your graphics hardware (amongst other such as sound etc.)

Currently you can (sort of) share it, but if you want to run Windows on
a HVM system, the best solution is to use "Remote Desktop" and use the
Dom0 display for your display device. Similarly, VNC works well for
Linux, whether it's para-virtual or HVM... 
> 
> I realize that this is only realy use full in 
> desktop/workstation situations but I have been pondering the 
> subject for some years.
> 
> One problem I guess would be the state/mode of the graphics 
> hardware in different doms - whitch is probably why they 
> could not share it at the same time - but perhaps switching 
> is more feasible. I seem to remember that there was an INT 10 
> function in vga (pre svga) that could store the state of all 
> the registers etc. on the card. Combined with some sort of 
> frame buffer (that only gets used when graphics operation is 
> suspended ex. A nother dom has the graphhw at the moment) you 
> could perhaps store the mode, state and graphichs ram of each 
> dom and be able to restore each in turn?

The first criteria in this case would be that the DomU is aware of the
fact that it's on a virtual machine - otherwise, the DomU can't perform
the "save state" function - most drivers have that functionality,
because that's how power-saving the graphics card works, including
"Suspend to ram" and "Hibernate", etc. But it's a case of "How to tell
the driver to do this". 

There is of course the problem that if the OS isn't helping out when
you're saving state (as the OS does in Power-saving state-save), then
you may have to STORE ALL OF THE FRAME-BUFFER, which could easily be
128MB - which in turn means more memory for each domain. 

I think you really need to have specific drivers that are virtualization
aware (para-virtualized drivers) to solve this. In this case, you could
for example allow the card to not USE all of it's frame-buffer for one
particular guest, and have several sections of frame-buffer, one for
each guest. That way, there will be no need to store 128+MB of frame
buffer each time. 

Another solution is of course a "simple but efficient" para-virtualized
driver, which allows the guest to just pass the drawing information from
the primitives in the guest directly to the driver of the actual display
(the latter is either DIRECTLY to the driver with some sort of
switching, or to an application that draws within a window). In this
case, the driver in the guest doesn't actually draw anything, or even
have any real hardware (a faked entry in the PCI device config space
that we provide, so that the driver can be loaded with whatever
Plug&Play mechanism the OS uses). 

> 
> Forgive my ignorance but the last time I seriously spent time 
> with lowlevel hw programming was on 486 hardware :) 

That's probably some time ago then ;-) But I'd say you have the right
questions, give or take a bit... 

> 
> Regards
> Jean Blignaut
> 


-- 
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.392 / Virus Database: 268.5.3/331 - Release Date: 5/3/2006


-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.392 / Virus Database: 268.5.5/334 - Release Date: 5/8/2006
 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.392 / Virus Database: 268.5.5/334 - Release Date: 5/8/2006
 

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