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

["Jean Blignaut" <jean@xxxxxxxxxxx>]

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

>Jean Blignaut wrote:
>> 
>> 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?)

>The problem with a SUSPEND/RESUME button is that it's controlled almost
>entirely by the BIOS - which means that the hypervisor will not have
>much say in what happens. Ok, so in SVM (AMD's solution) we could very
>well intercept the SMI (System Management Interrupt) that happens due to
>the button-press, but unfortunately, the hardware that we need to deal
>with, primarily the south-bridge, will need specific hardware support
>for each model (and perhaps also different depending on each hardware
>platform, i.e. some models of a machine will need one setup, another
>model will need another setup), and we'd have to replicate all the
>power-management code in the BIOS and make it play with the hypervisor.
>It could probably be done, but it's not going to be easy, and I think
>it's more sensible to actually use a para-virtualized driver for the
>Windows system, and then use a back-end/front-end model as per normal
>Xen to achieve decent performance using the native driver in Dom0. 

>> 
>> 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 

>Sure. Game-playing would be another place where graphics performance is
>critical. I don't think Xen will be ready for either of these types of
>apps for some time... 

Yeah I was going to add games to my list but forgot.
So given these factors it would be best (in theory) to implement some thing 
like this in BIOS?

--
Mats
> 
> -----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
> 
> 


-- 
No virus found in this incoming 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